Hi,
Unless you are running a Windows 2003 network, neither Digest nor NTLM are
delegatable. Only Kerberos auth is delegatable. Windows 2003 introduces
protocol transition, which allows the original user to use any
authentication mechanism, and IIS 6.0 can get a Kerberos token to access a
remote resource.
SE_TCB_NAME is a significant user right as I understand it. Certainly more
than trusting a computer for delegation IMHO.
Cheers
Ken
"bruce barker" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
: you are on the right track. ntlm will not delegate even if your security
: team allowed delegation, only digest allows delegation.
:
: on win2k you have no choice but to set SE_TCB_NAME (this is removed in
xp).
: its a fairly safe priviledge. its original intent was to control Trojan
: horses (programs that pretended to be the login program).
:
: -- bruce (sqlwork.com)
:
:
:
: "Magdelin" <(E-Mail Removed)> wrote in message
: news:9C2BA3A9-A627-46B0-9215-(E-Mail Removed)...
: > Hi all,
: >
: > I am trying to implement ASP.NET impersonation/delegation in an intranet
: application in C#. The presentation layer developed in ASP.NET accesses
the
: business logic via .net remoting. The business logic in-turn accesses the
: other network resources such as the SQL Server and the Active Directory.
: > Both the business logic and the web application are deployed in IIS
: installed on two separate Win2k servers. Since, the application requires
: "Windows Authentication" in order to implement the declarative Role-based
: security, both business and presentation layers are configured for
: impersonation, by including the <identity impersonate="true"/> tag in
their
: respective web.config files. The directory security of business and web
: applications hosted in IIS is configured for "Integrated Windows
: Authentication". The anonymous, digest and basic authentication options
are
: not selected.
: >
: > With the above mentioned configuration, if the business logic tries to
: access the active directory, a COMexception occurs with the error message
: "An operation error has occurred". I believe this error has occurred
because
: the impersonated account and the computer on which the business logic runs
: are not trusted for delegation by the Domain controller. The following
links
: explains the reason for such an error.
: >
: >
http://support.microsoft.com/default...b;en-us;810572
: >
http://support.microsoft.com/default.aspx?kbid=325894
: >
http://support.microsoft.com/default.aspx?kbid=264921
: >
: > Link to the newsgroup search
: >
:
http://msdn.microsoft.com/newsgroups...y=double+hop&d
: g=&cat=en-us-msdnman&lang=en&cr=US&pt=&catlist=&dglist=&ptlist=
: >
: > Since our security team considers trusting win2k server for delegation
to
: be a major security risk, I haven't had the opportunity, to test the
: business logic with the trusted configuration myself. From the trace log
it
: is clear that the authentication type is NTLM and the account used to test
: the business logic has sufficient privileges to query the Active Directory
: (AD). The application is successful in querying the AD when account
: properties (userName and password) are included in the <Identity> tag.
: >
: > Fortunately, I found few delegation alternatives in MSDN at
:
http://msdn.microsoft.com/library/de...us/vsent7/html
: /vxconaspnetdelegation.asp
: >
: > The WindowsImpersonationContext.Impersonate() is now considered as the
: best alternative for impersonating an account that is specially created
for
: this purpose. The role based security will be implemented as before but
for
: accessing resources such as AD and SQL Server the new helper account will
be
: used. The account that currently runs the process will be impersonated
with
: a special helper account which will have sufficient privileges to
: impersonate as well as query the AD. Once the task with the AD is
completed,
: the windows identity will revert back to its original credentials. The
: following link details how to make such impersonation, possible.
:
http://msdn.microsoft.com/library/de...us/cpguide/htm
: l/cpconImpersonatingReverting.asp
: >
: > When the impersonation and reversion is tried on the win2k server, I
: receive the error message "1314: The required privilege is not held by
: client". I know that the LogonUser API requires "Act as part of the
: operating system (SE_TCB_NAME)" privilege. But, I would like to grant the
: helper account with least possible privilege.
: >
: > Is there a privilege other than the "SE_TCB_NAME" that has fewer
: privileges but can still make the LogonUser API work? Is there a better
: alternative for ASP.NET impersonation/delegation?
: >
: > Any ideas or pointers to articles would be greatly appreciated.
: >
: > Thanks in advance.
: > Magdelin
:
:
Similar Threads
