IWAM Account Is Not Granted the Impersonate Privilege for ASP.NET 1.1 on a Windows 2000 Domain Controller

Recently at work a someone was playing around with AD, and could not get impersonation working in ASP.NET – even hardcoding the userid/pwd did help, and all the time he got an Access is Denied error. After searching high, low, etc. he did find this issue. Interestingly I have never seen this, because well one, I have been working on Windows 2003 Server for the last few months, and two more importantly, my dev box, has not been a Domain Controller! (Why you would want one is another story).

So, it turns out there is a bug and you may experience the behavior when the user account that you use to run the program does not have the Impersonate a client after authentication user right (the SeImpersonatePrivilege function). When you upgrade Windows 2000 Server Domain Controller to SP4, the user account (IWAM) is not granted SeImpersonatePrivilege, and then programs that use impersonation may not work correctly. When you request an ASP.NET 1.1 page, you may receive the following error message: Server Error in ‘/iwamtest’ Application.

Access is denied.
Description An unhandled exception occurred during the execution of the current Web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details
System.ApplicationException: Access is denied.

Source Error
An unhandled exception was generated during the execution of the current Web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace
[ApplicationException: Access is denied. ]

System.Security.Principal.WindowsIdentity._ResolveIdentity(IntPtr userToken) +0 System.Security.Principal.WindowsIdentity.get_Name() +71 System.Web.Configuration.AuthorizationConfigRule.IsUserAllowed(IPrincipal user, String verb) +100 System.Web.Configuration.AuthorizationConfig.IsUserAllowed(IPrincipal user, String verb) +81 System.Web.Security.UrlAuthorizationModule.OnEnter(Object source, EventArgs eventArgs) +178 System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +60
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87

Workaround: To work around the problem, manually assign Impersonate a client after authentication to the IWAM account. To do so, follow these steps:

  1. Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.
  2. Click Security Settings.
  3. Click Local Policies, and then click User Rights Assignment.
  4. In the right pane, double-click Impersonate a client after authentication.
  5. In the Security Policy Setting window, click Define these policy settings.
  6. Click Add, and then click Browse.
  7. In the Select Users or Groups window, select the IWAM account name, click Add, and then click OK.
  8. Click OK, and then click OK again.
  9. To enforce an update of computer policy, type the following command: secedit /refreshpolicy machine_policy /enforce
  10. At a command prompt, type iisreset.

More Information: http://tinyurl.com/6yfx3

[Listening to: Vertigo – U2 – How to Dismantle an Atomic Bomb [Bonus Track] (03:15)]

Published by

Amit Bahree

This blog is my personal blog and while it does reflect my experiences in my professional life, this is just my thoughts. Most of the entries are technical though sometimes they can vary from the wacky to even political – however that is quite rare. Quite often, I have been asked what’s up with the “gibberish” and the funny title of the blog? Some people even going the extra step to say that, this is a virus that infected their system (ahem) well. [:D] It actually is quite simple, and if you have still not figured out then check out this link – whats in a name?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.