More IIS 6.0 Fun

Several months ago, I set up a new network environment that was not live at the time.  That environment, once up and running and ready, was then utilized by some outside consultants and developers as an ad-hoc testbed.  Ultimately, The work carried out was not entirely (I am starting to doubt this every happens) removed or cleared up, so the system was back in its original state.  Luckily (or smartly), a complete backup of the system state, the IIS metabase, and the IIS configuration and directoy structures were made before access was given.  This allowed me two options:

 

1) Figure out what got changed and how to undo those changes

2) Restore the system settings, configuration, metabase, and directory structure.

 

Time not being of the essence, I chose the former.

 

When websites utilize an anonymouse user, that user can either be the default (IWAM?) user, or any other user you choose to specify in either a domain or local machine.  When this happens, or if any other site on IIS, or Virtual site utilize a non-default anonymous user, this poses frustrating authentication problems.  There are two ways (maybe three, but I didn't have any luck with the adsutil.vbs approach of synchronizing the passwords) that I was able to resynch the ever-changing anonymous user password hash.  The first is to route out all descrpencies for each and every incarnation of the mismatch for the user in the metabase (Make sure you are able to edit the metabase directly if you want to try this dicey approach.

 

The more-straight-forward approach that is much much safer to use is to disable all authentication for each website and virtual website.  Once that is done, you can go back and start enabling the anonymous authentication.  What is happening underneath the hood, is you are allowing IIS to automagically handle all the password hashes on the metabase by removing them.  Then as you re-enable this for each website or Virtual website, IIS will automatically ensure the passwords are synchronized when you select the other sites in the Apply Changes Prompt.

 

What causes them to get out of synch!?

 

This, thus far in my experience is not terribly easy to explain.  From what I can gather in the limited testing I have done, lets say you have siteA and virtualSiteA.  If you disable the synchronization on siteA then later re-enable it, you need to select any and all virtual sites when prompted to apply the authentication changes to.  If this doesn't happen, then oldest password hash (now virtualSiteA) is going to have the only legitamite hash to authenticate against, and the rest of your sites will not operate the way you want/need them to.

 

So, before you go out and start messing with Application Pools, or deleting and recreating users, try the above (no warranties!  Use entirely at your own Risk!).