Welcome to MSDN Blogs Sign in | Join | Help

HTTP/1.1 200 OK - Jimmie's IIS/ASP.NET Chatter

Solutions to common issues seen by the IIS/ASP.NET support teams at Microsoft & general discussion of topics related to IIS and ASP.NET technologies.
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
http://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:
The first step we need to take is to make a simple modification to the adsutil.vbs script so that we can see the clear text version of the password.  Open a comand prompt and navigate to <drive>:\inetpub\adminscripts.  Type notepad adsutil.vbs at the command prompt and hit enter.  This will open the adsutil.vbs script in notepad.  Now go to the Edit - Find menu and enter "IsSecureProperty = True" and hit enter.  Change the "True" to "False" and save the file.  You can close notepad now and return to the command window. 

Now 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

Posted: Wednesday, May 24, 2006 12:22 PM by jiruss
Filed under:

Comments

HTTP/1.1 200 OK - Jimmie's IIS/ASP.NET Chatter said:

I ran into an interesting issue the other day while helping one of our Support Engineers from Exchange.

# December 17, 2006 3:30 PM

Simple Blogger said:

Thanks. We ran into this issue and your information was very helpful in resolving our problem.

# January 10, 2007 2:00 PM

nparsona said:

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

# March 30, 2007 3:47 PM

nparsona said:

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.

# March 30, 2007 3:56 PM

nparsona said:

OK.  The issue is you have to use forward slashes not backslashes the line should read:

cscript adsutil.vbs SET W3SVC/AnonymousUserPass NewPassad

Thanks.  Your article helped me a lot.

# March 30, 2007 4:05 PM

jiruss said:

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

# April 13, 2007 2:37 PM

Freddy2 said:

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

# June 29, 2007 11:07 PM

jiruss said:

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

# July 3, 2007 4:15 PM

Freddy2 said:

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

# July 3, 2007 7:02 PM

sab0900 said:

Hi Jimmy,

your instuctions are very easy to follow and they worked just like you said they would.  The only problem I have is that I still don't have anonymous access. One inconsistancy that I have is that you instructed to set the password of the IUSR account on a domain contoller. I set the IUSR account on the actual server that is hosting IIS. I couldn't think of a possible reason how your instruction could work, but since what would make sense didn't work I decided to humor your suggestion. Well it didn't work. This leads me to believe that your solution only works when your domain controller is the computer that is hosting the website. I could be wrong and maybe I am missing something, but when I followed your instructions I didn't get any of the errors that others got. It just worked (the commands that is).

# February 26, 2008 10:09 AM

jiruss said:

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

# February 26, 2008 3:21 PM
Anonymous comments are disabled
Page view tracker