The sparkle of IISSuba...(oh, that is the IIS Sub Authenticator for those that don't know it)

IIS SubAuthentication - Magic? You bet it is...

For many years, IIS administrators didn't have the first clue what the IIS sub-authenticator was more less how it worked.  It wasn't until the security PM (http://iisgeek.no-ip.com/) sat down and really went over subauth did I understand how it works and why it existed.  More importantly, I certainly know why it isn't enabled by default today on IIS 6.0.

A couple of weeks ago I was demonstrating a demo of a new tool that Microsoft is working called Authentication and Access Control Diagnostics (AuthDiag) to a group of IIS program managers.  During this demonstration, I made the slight mistake of thinking I knew how to break IIS Subauthentication in respect to anonymous access.  Little did I know that I would quickly be wrong and corrected by the developer and learn about a slight code path I ceased to know existed...

Did you know...

There is this little checkbox in IIS 5.0 that says “Allow IIS to control Password.“  This isn't voodoo magic checkbox that makes everything just work, but close ;-).  This check box is designed to tell IIS to ignore logon attempts that fail because of bad password.  This feature was very doable because Inetinfo, where logon user is called, runs as Local System and hence we really didn't need to call logon user in the first place.  Local system has the ability to logon a user via impersonation without having the password for the account.  This is, by default, a privilege of running as Local System.

For those who didn't know this, slowly pick yourself back up off the floor and relax and know that this isn't enabled by default on IIS 6.0 and you can check for yourself.  If you check the metabase, you will find that AnonymousPasswordSync is set to false or doesn't exist (false by default).  Oh, and that little checkbox is not there either in the IIS Manager...;-)

This feature, albeit convienent in domain policy driven environments, did live for a reason.  Security just happen to not be one of them...since it effectively logs on the anonymous user even though the IIS metabase property AnonymousUserPass was set incorrectly.

Back to this demo, I was trying to show how AuthDiag would capture configuration failures such as these and warn the administrator that their anonymous user settings were invalid.  I set the appropriate metabase property (using a script I created), and then ran AuthDiag and it returned - Done! (that is another problem with AuthDiag 1.0 RC 1, but outside the scope here...I knew this meant it didn't find any errors!)

Then, at that moment, I wanted to hit my laptop, bury myself under the table, and say “must be a bug...“  I said just that - but was corrected by the developer of the tool who said - (insert Russian accent) - no, no, not a bug - password work.  With a blank stare, I said - if the password is correct, then IIS will call logonuser even if AnonymousPasswordSync is set to true????  He said, yes.  Repeat - If IIS has the correct credentials in the metabase (aka - AnonymousUserName and AnonymousUserPass) then it will use those EVEN if anonymouspasswordsync is enabled.

Funny, I thought after living and breathing this product for 4 years I knew a thing or two...turns out I was wrong! ;-)

~Chris