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.  

HTTP/1.1 200 OK

Comments

• Anonymous
  December 17, 2006
  I ran into an interesting issue the other day while helping one of our Support Engineers from Exchange.

• Anonymous
  January 10, 2007
  Thanks. We ran into this issue and your information was very helpful in resolving our problem.

• Anonymous
  March 30, 2007
  I have this exact problem with OWA.  I tried to follow your steps, but when I run the cscript to set the password I get: Error Trying To GET the Schema of the property: IIS://localhost/Schema/anonymou euserpass Any ideas? Thanks in advance

• Anonymous
  March 30, 2007
  OK.  I figured out the first issue.  Now I get: ErrNumber: -2147463162 (0x80005006) Error Trying To SET the Property: anonymoususerpass Any ideas would be greatly appreciated.

• Anonymous
  March 30, 2007
  The comment has been removed

• Anonymous
  April 13, 2007
  Interesting find nparsona.  Inspection of my version of ADSUTIL.VBS would suggest that either slash should technically work since we have a "SanitizePath" function that replaces backslashes with forward slashed.  Perhaps the version you are using is older.  I would agree that forward slashes are the appropriate syntax and I have updated the article to reflect this.  Thanks for the information! Jimmie

• Anonymous
  June 29, 2007
  Thanks for the path to get the IUSR password. It helped to clean the inconsistencies. A remark: The proposed command "adsutil.vbs delete anonymoususerpass W3SVC/1/root" returns an error: "expecting 2 arguments". Thus, typing: "adsutil.vbs delete W3SVC/1/root/anonymoususerpass", it returns OK, but does not delete it. Maybe due to another version of adsutil.vbs? (I have 3 versions; the 'best' seems to be from 2006-04-14, 85.813 byte). Any idea on this? Freddy

• Anonymous
  July 03, 2007
  Hi Freddy.  Couple of things here:  First, both of my commands had the incorrect syntax (so much for copy and paste reducing errors huh?).  I have updated the article to the correct syntax for the command lines.  Second, if command doesn't find the property at the path you have given you should see an error similar to the following: The path requested could not be found. ErrNumber: -2147024893 (0x80070003) Error deleting the object: w3svc/root/1/anonymoususerpass If the command is successful you should see: Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. deleted property "anonymoususerpass" Please make sure you run the following command first to find all the locations that the password is set in the metabase: cscript adsutil.vbs find anonymoususerpass Then delete it from all locations except for the W3SVC, MSFTPSVC and SMTPSVC. Thanks for the feedback and catching another showstopping error in my post! Jimmie

• Anonymous
  July 03, 2007
  Hi Jimmie, thank you for checking back. I already followed the seq of commands you suggest, and I got a "successfully deleted", but checking back with metabase explorer 1.6, it was still there ... maybe it was too late in the night. But I was able to sort it out. BTW: It's still a difficulty in the UI of IIS6 (since v4?): whereas the data design seems to be proper, I miss a concept allowing me to distinguish inherited object values from instantiated ones. The script is more useful in this case. Freddy Regards, Freddy

• Anonymous
  February 26, 2008
  The comment has been removed

• Anonymous
  February 26, 2008
  SAB0900, The IUSR account is a local machine account on member servers and should be changed on the machine where IIS is running.  I did not instruct to set the password on the domain controller.  I did, however, say that if the web server is also a domain controller then you would use Active Directory Users and Computers to make the change as opposed to Computer Management. If you have synchronized the password in the metabase and the SAM database then you likely have some other issue with your IUSR account being denied access.  I would start by enabling failure audits for Logon and Logon Account events in the local security policy and then check the security event logs for failures.  Good luck! Jimmie