IUSR_ account password out of sync. (Help OWA is not working!)
After seeing this same issue 4 times in the last 2 days, I thought it would be a good idea to post it along with the very simple and quick solution.
First, I would like to clear up what seems to be a common misconception among IIS administrators out there. The password field for the anonymous access account under authentication methods does not change the password for the anonymous user account in the machine’s SAM database. The field is there so you can enter the password for the anonymous user account should you decide to use an account other than the IUSR account. The password field is stored in the IIS metabase in encrypted form and must match the password for the account in the SAM database. Second, IIS6 does not enable Subauthentication used in earlier versions of IIS by default because of the inherent security risks. Basically, the subauthentication component in IIS5, allowed IIS to manage the passwords for the anonymous user accounts and keep them in sync with the SAM database. Because the Iissuba.dll could be used maliciously to change passwords on other accounts, IIS6 does not enable it. For more information on
Subauthentication see
https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/bda0c6e5-ae71-463f-be27-f85dafa776b2.mspx?mfr=true.
Now for the issue:
When the password for the IUSR account stored in the metabase doesn’t match the password for the account on the machine, we have PROBLEMS! When we have this condition and a user tries to browse the site anonymously, they will be presented with a lovely 401.1 status code. Users of OWA (Outlook Web Access) will also be affected and will see a screen similar to the one in Figure A. The reason this happens is because the images and other resources that OWA uses are located in the ExchWeb virtual directory, which by default is set for anonymous access. Since our anonymous user (IUSR_machinename) cannot be authenticated, none of the images are accessible and downloaded and you end up with a “broken” OWA application. If you were to check your IIS log files you would see numerous 401.1 status codes for GET requests on items in the ExchWeb virtual directory.
Figure A.
Now for the fix:
First, we need to make sure that we are only setting the password for the IUSR account in a single location in the Metabase. Open a command prompt and navigate to the C:\inetpub\adminscripts directory.
Enter the following command:
cscript adsutil.vbs find anonymoususerpass and press enter .
This will return a listing of all the nodes where the anonymoususerpass appears in the metabase. Ideally you should see this in only the W3SVC node (it may also appear in the MSFTPSVC node if you are running FTP). If you see any locations “under” W3SVC (i.e. W3SVC/1/root) then we should delete these entries.
To delete an entry use the following syntax:
cscript adsutil.vbs delete W3SVC/1/root/anonymoususerpass
Once we have made sure that we only have the password set at a single location, we need to “sync” the password with the one in the SAM database. The easiest way to do this is to simply open Computer Management if you are on a member server or Active Directory Users and Computers on a domain server and do a change password on the IUSR account. Then back at our command prompt, we simply set the password to match the one we just set by using the following command:
cscript adsutil.vbs set W3SVC/anonymoususerpass "passwordgoeshere"
Viola! The passwords should now be in sync and the site should now be accessible.
If you would prefer to attack this from the other direction and set the password in the SAM for the IUSR account to match the one assigned in the Metabase, you need to edit the adsutil.vbs file. Open adsutil.vbs in notepad and find the function called “IsSecureProperty”. Find the line IsSecureProperty = True and change it to IsSecureProperty = False. Then run the following command:
cscript adsutil.vbs get W3SVC/anonymoususerpass
This will return the password for the anonymous user that we currently have stored in the database. Simply copy this value and then do a change password on the IUSR account in ADUC (Active Directory Users and Computers) or Computer Management and paste in this value. Again the passwords are now in sync and everything should be working properly.