NTLM as SSO, and Performing Certain Actions as an Impersonated Administrator

Question

I can't seem to stumble upon the correct combination of IIS / ASP.NET settings to accomplish the following:

1. All users on an internal domain should be able to access IIS site (w/ NTLM authentication), and the ASP.NET application should be able to get the username of the current user (aka the user is authenticated as themselves).
2. The running ASP.NET application should be able to execute certain actions under an Administrator account. For example, an Active Directory change, or writing files to restricted locations.

You could probably guess, but the point of the application is to be able to let "normal" users make specific "Administrative" changes via the web application. At the same time, the change should be logged with the "normal" user's account, so I don't want to lose the authenticated user's credentials.

Looking for the specific settings in IIS6 to accomplish #1 (any users on the domain to get to the site and be authenticated as themselves), along with the code for #2.

Answer 1

There are atleast two options:

Common for both:

• Your IIS setting should be set to windows authentication.
• The Identity of the user can be read from the httpcontext.

Option 1:

• Set impersonation = false
• Set the identity of the application pool to a user that has the right to make AD Changes
• Add the above user to the IIS_WPG group

Option 2:

• When making the AD changes set the identity of the thread to that of a user that is allowed to make the AD changes

For option 2, here is a code example that uses impersonate user:

http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx

Answer 2

From a security point of view, the best approach would be to separate all the Administrative operations into its own Web service that does authenticate, but does not impersonate. Your Normalpart of the site would perform the administrative operations by calling the web service, just like any other client, even if is a localhost call.

This way you achieve isolation between the normal app pool (that impersonates) and the priviledged app pool (the administrative).

Finally, this is perhaps splitting hairs, but it should be Kerberos authentication, not NTLM, because NTLM does not allow for constrained delegation and your 'normal' application will need to be enabled for delegation if it accesses anything outside the local IIS host.