Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've recently moved one of our servers from Server 2003 and IIS6 to Server 2008 R2 and IIS7 (technically IIS7.5 I suppose). In doing so I am transitioning a small account management tool written in classic ASP and have run into a problem with user impersonation. Extensive searching hasn't been much help so far.

Under IIS6, the site was configured to impersonate the logged-in user. Thus, if a domain admin logged in, he was able to run commands to create user directories, adjust permissions, etc. Using Procmon you can see the processes executing as that user. This worked fine.

However, with the same code under IIS7, I am unable to get this behavior. I have enabled Basic Authentication, disabled Anonymous Auth, enabled impersonation and have changed the app pool to classic instead of integrated pipelining. Everything seems to be configured correctly, however, all the processes launched by the classic ASP site continue to run as the default AppPool identity and not the logged-in user.

If it matters, programs are being launched with code such as:

set Wsh = Server.CreateObject("WScript.Shell")
Wsh.Run("cmd.exe /C mkdir D:\users\foo")

Monitoring via Procmon shows cmd.exe being run as either "Classic .NET AppPool" or "DefaultAppPool" depending on the pipeline mode.

Any suggestions on how to get the classic ASP site to impersonate and execute as the authenticated user would be great. Thanks!

share|improve this question

3 Answers 3

Why have not you enabled also "Integrated Windows Authentication" in IIS?
Had it logged in locally?
under local Administrator?

Make sure that:

  • NTLM2 is enabled
  • you changed web.config from default

     <authentication mode="None" />   
    

    to

     <authentication mode="Windows" />  
    
share|improve this answer
    
Thanks for your reply. I'm not sure why you ask about integrated authentication. I've turned if off because we prefer to have the user explicitly prompted for credentials. However, enabling it does not make impersonation work. I'm not sure what you mean by "NTLM2 is enabled". The web.config is very sparse and contains only a single directive, <identity impersonate="true" />. Adding <authentication mode="Windows" /> doesn't do anything different. In all cases, I still see processes being created using the AppPool identity and not that of the authenticated user. –  user52663 Aug 28 '10 at 22:26

Is your IIS application configured for pass-through authentication as the application user? To check on this, highlight your application (virtual directory) in the IIS Manager and bring up the Basic Settings window. Then click on the Connect As button. What is it set to?

If you set up the "Connect As" option to run under a specific account and then check ProcMon, does your process run under the specified account, or does it still run under DefaultAppPool?

I'm struggling with a VERY similar issue. I have one 2008 R2 server where our object runs properly under the user's context and another R2 server where it runs under NetworkService instead.

share|improve this answer

There's a little-known setting called LogonMethod, which varies the capabilities of a user account which logs on with an anonymous or plain-text logon.

I (think I) remember this changing for IIS 5 or 6, so it's possible it's changed again for 7. The effect would be exactly what you describe - a failure to do things an interactive user would have no trouble doing.

It's a bad idea to change it wholesale to achieve delegation - after all, that's what Kerberos constrained delegation and protocol transition are for - but it might help resolve this issue.

LogonMethod - IIS 6 and earlier property - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/fa99f59f-d11f-41f7-b220-ad9d433f80b0.mspx?mfr=true

LogonType - a similar-looking property for an App Pool that accepts fewer options (but Service might work for you) - http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/processModel

Oh, and it's possible (though how-you-say bloody?) unlikely that your WScript object is running in a COM container with a different identity to the worker process.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.