«

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" <> wrote in message
news:9C2BA3A9-A627-46B0-9215-...
> 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

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" <> wrote in message
news:...
: 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" <> wrote in message
: news:9C2BA3A9-A627-46B0-9215-...
: > 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
:
:

If your security guys will not even allow delegation, then I don't think
they will grant "Act as Part of the Operating System". I do not agree with
Bruce - I think this is a major right to grant to the ASPNet account.

Have you considered using a trusted-subsystem approach?

Cheers
Ken


"Magdelin" <> wrote in message
news:057133D3-5C37-43C7-8DC8-...
: Thanks Bruce for your inputs.
:
: I have included a description on SE_TCB_NAME privilege from one of the MS
help documents.
:
:
************************************************** **************************
*************
: Act as part of the operating system
: Computer Configuration\Windows Settings\Security Settings\Local
Policies\User Rights Assignment
:
: Description
: This policy allows a process to authenticate as any user, and therefore
gain access to the same resources as any user. Only low-level authentication
services should require this privilege.
:
: The potential access is not limited to what is associated with the user by
default, because the calling process may request that arbitrary additional
accesses be put in the access token. Of even more concern is that the
calling process can build an anonymous token that can provide any and all
accesses. Additionally, the anonymous token does not provide a primary
identity for tracking events in the audit log.
:
: Processes that require this privilege should use the LocalSystem account,
which already includes this privilege, rather than using a separate user
account with this privilege specially assigned.
:
: By default, only the LocalSystem account has the privilege to act as part
of the operating system.
:
:
************************************************** **************************
*************
:
: So, I am not sure if my security team will consider SE_TCB_NAME as a safe
privilege. How about passing the credentials of the helper account directly
to the System.DirectoryServices.DirectoryEntry constructor? Would that help
me query as well as manage set of users and groups in AD?
:
: Regards,
: Magdelin
:
: ----- bruce barker wrote: -----
:
: 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" <> wrote in message
: news:9C2BA3A9-A627-46B0-9215-...
: > 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
:
:
:

Hi Magdelin,

According to my understanding, you need to implement the following function:

User logon one ASP.NET web application. In the web application, we will
access the business logic. The business logic will access other resources
that request authentication.

If I have misunderstood, please don't hesitate to let me know.

Magdelin, as you know, under this scenario, we can perform the following
steps to transfer the user authentication:

1. Enable "Basic Authentication" on the web application and the business
logic, which will pass the user authentication information to the third
resources.

2. If the authentication on the web application is "Windows Integrated
Authentication", enable "delegate", which will also pass the authentication
with Kerberos authentication.

3. Directly Impersonate in the code.

However, on Windows 2000, if we want to directly Impersonate with
LogonUser, we need to grant ASPNET with the SE_TCB_NAME user right. This is
by design. For more information, please check the following article:

810204 PRB: Per Request Impersonation Does Not Work on Windows 2000 with
ASP.NET
http://support.microsoft.com/?id=810204

Suggestion:
===========

Magdelin, according to above analysis, I suggest that we perform the
following methods:

Method 1:
----------

Enable "Basic" authentication for the web application and the business
logic. This will pass the user authentication to the SQL server or AD.

Method 2:
----------

Add SE_TCB_NAME user right to the ASPNET account or replace "machine" in
<processmodel> with another user account, who has the "SE_TCB_NAME" user
right.


Method 3:
Another suggestion: perform access check at middle-tier/COM+, and then use
a fixed identity to access the backend resources. Something like the
trusted subsystem as ken mentioned.

COM+ and Windows 2000: Ten Tips and Tricks for Maximizing COM+ Performance
http://msdn.microsoft.com/msdnmag/is...s/default.aspx


If there is any unclear, feel free to let me know. Thanks!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

Thanks Ken. I totally agree with you regd. the SE_TCB_NAME privilege. Even though, I know it is impossible for me to implement trusted delegation, for knowledge purpose I need to clarify this with you. The following link details how delegation can be configured on Win 2000 n/w. http://support.microsoft.com/default...b;en-us;810572 . Is it true or am I missing something

Regards
Magdeli

----- Ken Schaefer wrote: ----

If your security guys will not even allow delegation, then I don't thin
they will grant "Act as Part of the Operating System". I do not agree wit
Bruce - I think this is a major right to grant to the ASPNet account

Have you considered using a trusted-subsystem approach

Cheer
Ke


"Magdelin" <> wrote in messag
news:057133D3-5C37-43C7-8DC8-..
: Thanks Bruce for your inputs

: I have included a description on SE_TCB_NAME privilege from one of the M
help documents


************************************************** *************************
************
: Act as part of the operating syste
: Computer Configuration\Windows Settings\Security Settings\Loca
Policies\User Rights Assignmen

: Descriptio
: This policy allows a process to authenticate as any user, and therefor
gain access to the same resources as any user. Only low-level authenticatio
services should require this privilege

: The potential access is not limited to what is associated with the user b
default, because the calling process may request that arbitrary additiona
accesses be put in the access token. Of even more concern is that th
calling process can build an anonymous token that can provide any and al
accesses. Additionally, the anonymous token does not provide a primar
identity for tracking events in the audit log

: Processes that require this privilege should use the LocalSystem account
which already includes this privilege, rather than using a separate use
account with this privilege specially assigned

: By default, only the LocalSystem account has the privilege to act as par
of the operating system


************************************************** *************************
************

: So, I am not sure if my security team will consider SE_TCB_NAME as a saf
privilege. How about passing the credentials of the helper account directl
to the System.DirectoryServices.DirectoryEntry constructor? Would that hel
me query as well as manage set of users and groups in AD

: Regards
: Magdeli

: ----- bruce barker wrote: ----

: you are on the right track. ntlm will not delegate even if you
securit
: team allowed delegation, only digest allows delegation

: on win2k you have no choice but to set SE_TCB_NAME (this is remove
in xp)
: its a fairly safe priviledge. its original intent was to contro
Troja
: horses (programs that pretended to be the login program)

: -- bruce (sqlwork.com



: "Magdelin" <> wrote in messag
: news:9C2BA3A9-A627-46B0-9215-..
: > Hi all
: >> I am trying to implement ASP.NET impersonation/delegation in a
intrane
: application in C#. The presentation layer developed in ASP.NE
accesses th
: business logic via .net remoting. The business logic in-turn accesse
th
: other network resources such as the SQL Server and the Activ
Directory
: > Both the business logic and the web application are deployed in II
: installed on two separate Win2k servers. Since, the applicatio
require
: "Windows Authentication" in order to implement the declarativ
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
:
:
:

Thanks Steven for your suggestions.

The chapter intranet security at
http://msdn.microsoft.com/library/de...cnetlpMSDN.asp
provides configuration steps excatly like yours for delegation in ASP.NET. I understand that I have to use Basic authentication over SSL in order to enable delegation with NTLM authentication. But, clients
want the logon to be transparent. Users will be unhappy to re-enter the domain login name and
password every time they access this intranet application. Using COM+ enterprise services introduces
additional maintenance efforts. So, I want to keep service components as the last option.
BTW, I am using SQL authentication to access the database. I am having trouble only while accessing AD. So, I
guess I am really left with only two options for accessing remote resources from application server

1. Enable trusted for delegation in order to use the original caller context with Kerberos
authenticatio
2. Use the LogonUser API and impersonate a specific windows identity (which obviously will require
SE_TCB_NAME privilege

I think I will have to convince my security group to approve one of the configurations listed above

I haven't implemented role-based security in the business logic yet. I just beleived that if I initiate impersonation on web server and application server, I will be able to implement declarative or imperative role-based security at all layers. But, I am not sure if it really depends on Kerberos/NTLM. Can I implement declarative/imperative role based security in the business logic, if I choose integrated windows authentication(NTLM) on both web and application server

Regards
Magdeli


----- Steven Cheng[MSFT] wrote: ----

Hi Magdelin,

According to my understanding, you need to implement the following function

User logon one ASP.NET web application. In the web application, we will
access the business logic. The business logic will access other resources
that request authentication.

If I have misunderstood, please don't hesitate to let me know.

Magdelin, as you know, under this scenario, we can perform the following
steps to transfer the user authentication:

1. Enable "Basic Authentication" on the web application and the business
logic, which will pass the user authentication information to the third
resources.

2. If the authentication on the web application is "Windows Integrated
Authentication", enable "delegate", which will also pass the authentication
with Kerberos authentication.

3. Directly Impersonate in the code.

However, on Windows 2000, if we want to directly Impersonate with
LogonUser, we need to grant ASPNET with the SE_TCB_NAME user right. This is
by design. For more information, please check the following article:

810204 PRB: Per Request Impersonation Does Not Work on Windows 2000 with
ASP.NE
http://support.microsoft.com/?id=81020

Suggestion
==========

Magdelin, according to above analysis, I suggest that we perform the
following methods:

Method 1
---------

Enable "Basic" authentication for the web application and the business
logic. This will pass the user authentication to the SQL server or AD.

Method 2
---------

Add SE_TCB_NAME user right to the ASPNET account or replace "machine" in
<processmodel> with another user account, who has the "SE_TCB_NAME" user
right.


Method 3
Another suggestion: perform access check at middle-tier/COM+, and then use
a fixed identity to access the backend resources. Something like the
trusted subsystem as ken mentioned

COM+ and Windows 2000: Ten Tips and Tricks for Maximizing COM+ Performanc
http://msdn.microsoft.com/msdnmag/is...ps/default.asp


If there is any unclear, feel free to let me know. Thanks!

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

Hi Magdelin,

As for the Role-based rules, this is a certain features of the .net
application. In fact the roles should be the customer business rules you
defined which has not buildin relation with the machine or domain's
account. For example, we have many different account and groups in a domain
or machine. Then in our application, we can define our own roles and bind
some certan roles with a certain account. When we got the current User's
Impersonate Account(machine or domain account), we should lookup our custom
tables and query out the certain account's roles. This is all defined by
ourself according to our actual business rules.
And the buildin things we should care about is just how to pass the user
account info(credentail) between the different layers (web presentation to
business or business to data persitence). And the impersonate /delegate is
just focus on this, rather than roles. Do you think so?

If there is still anything we can help, please feel free to post here.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx

Thanks Steven.