RE: SE_TCB_NAME (Act as part of the operating system) privilege

[Steven Cheng[MSFT]]

Hi Magdelin,

As for the questions you listed , here are my understanding on them:
1. Is it sufficient if the domain\hpac is granted SE_TCB_NAME privilege on
the application server Server2?
==========================
It's enough for impersonate and have better add it into admin group.

2. Should the domain\hpac account have SE_TCB_NAME privilege on the domain
controller so that it allows us to get the account authenticated from
Server2?
===============================
No, I don't think it necessary.

3. Is it sufficient if domain\hpac has SE_TCB_NAME privilege to impersonate
or does it also need SE_IMPERSONATE_PRIVILEGE?
===============================
Yes, it's enough. SE_IMPERSONATE_PRIVILEGE is unnecessary

4. Does domain\hpac get SE_IMPERSONATE_PRIVILEGE automatically when
SE_TCB_NAME privilege is granted? If no, how do we grant
SE_IMPERSONATE_PRIVILEGE explicitly to a user using the tool Local Security
Policies?
=========================================
Will consult to confirm.

5. Is SE_TCB_NAME privilege required on both Win 2K and Win 2003 servers
for authenticating a user with LogonUser API and impersonating a user using
WindowsImpersonateContext.Impersonate()?
==================================================
Yes, we have to grant this privilege.

Also, I'll consult some further experts on this and will let you know if
I've got any further infos. 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

 

[Steven Cheng[MSFT]]

Hi Magdelin,

After some futher consulting, some other experts seem have some different
opinions, here are the original suggestions from them:
====================================

- Querying the Active Directory to get users credentials / roles /
privileges should be split from adding new credentials / roles / privileges,

- Querying the Active Directory should be granted to all domain users
accounts (actually, it seems to me this is what happens in any cases...)

- Updating the Active Directory should be granted to a specific domain
group,

- Then only users belonging to that group would be allowed to update the
Active Directory,

- and impersonating to a highly privileged domain user account
(domain\hpac) should not be required, nor performed, as it may become a
security issue by itself (or at least, it would be a point that require
special attention).

- Additional security barriers could be added by declaring that classes or
methods that perform update to the Active Directory are only allowed to
that group who si allowed to update the Active Directory.

=================================================

Please consider them, if there're anything else we can help, please feel
free to post here.
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

 

[Guest]

Hi Steven,

I really appreciate you taking the additional effort to get me the expert opinions. Though I totally agree with all your suggestions, I see few constraints in implementing them.

I would like you to look at my initial post in this thread to recall my server configurations. The reason why I require a special account for accessing active directory with SE_TCB_NAME privilege is to overcome the double-hop issue at the application server. With NTLM authentication, it is not possible to get the individual users authenticate with the active directory from the application server.

I am not using the basic authentication, to programmatically flow the original caller's identity or Kerberos delegation to implement your suggestions. Please forget about updating active directory, the remote components hosted on application server fails to even query the active directory with NTLM authentication.

I strongly believe that this is a result of NTLM not being able to support double-hop. And the special account is created just to overcome this problem and to fill the gaps caused by NTLM authentication, when I try to flow the original caller's identity to the remote resources such as active directory.

I am trying to use LogonUser API at the application server to impersonate a specific windows identity in order to be able to query the active directory. I know this approach is not recommended by Microsoft but I have no choice.

Are there any alternatives to LogonUser API other than basic and Kerberos authentication?

I would really appreciate if you could suggest me a secure alternative with NTLM authentication.

NOTE: I found the LogonUser API option in the “Building Secure ASP.NET applications†document at the Microsoft’s Patterns & Practices site.

Thanks once again.

Regards,
Magdelin


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

Hi Magdelin,

After some futher consulting, some other experts seem have some different
opinions, here are the original suggestions from them:
====================================

- Querying the Active Directory to get users credentials / roles /
privileges should be split from adding new credentials / roles / privileges,

- Querying the Active Directory should be granted to all domain users
accounts (actually, it seems to me this is what happens in any cases...)

- Updating the Active Directory should be granted to a specific domain
group,

- Then only users belonging to that group would be allowed to update the
Active Directory,

- and impersonating to a highly privileged domain user account
(domain\hpac) should not be required, nor performed, as it may become a
security issue by itself (or at least, it would be a point that require
special attention).

- Additional security barriers could be added by declaring that classes or
methods that perform update to the Active Directory are only allowed to
that group who si allowed to update the Active Directory.

=================================================

Please consider them, if there're anything else we can help, please feel
free to post here.
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

 

[Steven Cheng[MSFT]]

Hi Magdelin,

Thank you for the response. Regarding on the issue, I am still
finding proper resource to assist you and we will update as soon as posible.

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.)

 

[Steven Cheng[MSFT]]

Hi Magdelin,

After some further consulting, it seems that the LogonUser api is the only
means to manually impersonate a certain account if we can't use basic and
Kerberos authentication to pass the identity from the front level. 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