HTTP Error 401.5 – Unauthorized: a very plausible scenario
Recently, my customer started complaining that an externally-facing web site was not working properly. Apparently no changes had been made to the web site… This is very common in the field: nothing happens and software starts decaying in what seems to be a Half-Life phenomena. However, the site had been put offline for database maintenance purposes. How? Well, the external customers had to know what was going on, so they decided to do the following:
· Copy the index.asp file to the desktop as a backup;
· Change the published version of index.asp in-place, stating the application was unavailable;
· After the maintenance had finished, the index.asp file on the desktop was moved back to its original location, overwriting the maintenance-mode version.
Nothing weird, so far, right?
Well, let me tell you the 3 steps above resulted in the following:
So, what went wrong? Well, there’s a small detail which may help understand the problem… In fact, as this is an externally-facing web site, it has been configured for anonymous access, which means the IUSR_<computername> will be used as the security principal for every site access.
As a troubleshooter, I keep a flash drive with the tools of the trade. I even keep a 10+ folder for the most used tools, as you can see below.
Well, back to the issue… I started the Process Monitor and quickly found out an ACCESS DENIED while accessing the index.asp file. Here are the details of that error:
Ok, so the anonymous account is not able to access the file. How so?? It did access it successfully in the past. The fact is that the file ACL is not considering the anonymous logon as it should:
So the problem has been found. What led to it? Well, let us replay the bulleted list above in slow-motion:
· Copy the index.asp file to the desktop as a backup;
As the file is being copied, a new file is created on the desktop with a brand-new ACL (by now, I’m guessing you don’t need to read any further). This ACL will have a set of permission entries which are inherited from the desktop folder.
· Change the published version of index.asp in-place, stating the application was unavailable;
This step is OK and it has no impact whatsoever on ACLs…
· After the maintenance had finished, the index.asp file on the desktop was moved back to its original location, overwriting the maintenance-mode version.
It was this final move that broke things up. By moving the file back into its original location, the permission entries would have lost their inheritance. In these circumstances, the Operating System replaces the inherited permissions by entries with no inheritance. The purpose of this step is to ensure that the security settings are not lost during the file move. However, it induces the nasty effect of not matching the original entries and keeping the site unavailable in an ugly way.
In my humble opinion, this could happen to anyone, but Windows cannot be blamed for this situation. File operations such as copying or moving have their own semantics and they have been in place long enough for us to start doubting of the wise decisions made while making them available to users, right? What else can I tell you? Well, avoid backing up your web files on servers desktops…
Till next time,