One of my educational clients uses a web based Student Management Package for attendance, grades, and other school record keeping functions. The web server that powers these apps is a Windows 2003 server running IIS.
All of a sudden, the IIS server started getting “403 access is denied” errors when users were attempting to login to the application. According to the local network administrator nothing had changed on the server in the past few weeks, but it had been rebooted recently. Since school hadn’t been in session prior to today, nobody was using the application, so we had no idea how long it had been since the last time it operated properly.
The first thing I did was to review the Windows event logs and web server log, which showed no obvious errors. I ran dcdiag.exe and netdiag.exe on the domain controllers to verify the domain was healthy and operating as expected (it was).
Since everything looked okay on the web server with the exception of the Access is Denied messages, I suggested to the local admin that technical support for their student management package be contacted to assist in solving the problem.
To make a long story short, technical support said that the IUSR and IWAM accounts were corrupted, IIS would have to be uninstalled, reinstalled, then reconfigured. Of course technical support said this was going to be billable to the customer and was going to be a major ordeal with considerable downtime.
I decided that sounded like a ton of effort and expense, and if IIS was going to be redone anyway, I’d try to fix it myself. To help diagnose the cause of the problem, I downloaded the IIS Authentication and Access Control Diagnostics (aka AuthDiag) from Microsoft.com and installed it on the web server.
I ran AuthDiag, then selected the “User Rights or Privileges” link, and it created the following report:
User Rights and System Privileges Information
NT AUTHORITY\LOCAL SERVICE
Not found privileges: Log on as a batch job; Adjust memory quotas for a process; Replace a process level token
NT AUTHORITY\NETWORK SERVICE
Found privileges: Log on as a service
Not found privileges: Adjust memory quotas for a process; Replace a process level token
Found privileges: Allow log on locally; Access this computer from the network; Adjust memory quotas for a process; Impersonate a client after authentication
Not found privileges: Access this computer from the network
Found privileges: Log on as a batch job; Allow log on locally; Access this computer from the network
Found privileges: Log on as a batch job; Access this computer from the network; Adjust memory quotas for a process; Replace a process level token
Found privileges: Log on as a batch job; Impersonate a client after authentication; Log on as a batch job
Found privileges: Bypass traverse checking
Found privileges: Impersonate a client after authentication
To check privileges of custom Anonymous user (if it configured) run ‘Check Authentication’ for appropriate Site
Obviously, the “not found privileges” messages had something to do with my “403 access is denied” errors.
I edit the webserver’s Local Security Settings, and added the missing accounts to the policies that AuthDiag had flagged as being incorrect. I performed an IISreset, and the web application started working properly once again. Nothing was wrong with the IUSR and IWAM accounts, and IIS did not need to be reinstalled.
If you’re having IIS permission problems, I highly recommend AuthDiag. Other things this little program can check include Kerberos Configuration, User Rights and Privileges, Registry and Server Permissions. Make sure you get the version appropriate for your CPU. AuthDiag is also found in the IIS Diagnostics Toolkit.
IIS.net has a nice description of the various features and benefits of AuthDiag.