Authentication Problems After Migration

I recently migrated Web sites from several IIS servers to one server to consolidate administration. Since then, I've had problems with authentication. For example, one site works fine if you log on as a user, but when you access the site anonymously, you receive error 401 Access denied. The Web site permits Read access and Anonymous access, and no IP address restrictions are in place. I reviewed NTFS permissions on the site, which allow Everyone Read or Everyone Change. How can I identify the problem?

Such authentication problems are common and can be confounding. If the IUSR_servername user account (or whatever account you use for Anonymous authentication) has the Log on Locally user right, the problem is with NTFS permissions. The frequency of such problems underscores the complexity of setting NTFS permissions on a Web server correctly.

First, check the content in the Web root (the Web site's home folder) and all subfolders. Apparently, you've done so. Although I don't recommend using the Everyone account often, this account clearly isn't causing your problem.

Second, inspect permissions for all virtual directories. This inspection often reveals permissions-related problems because content for a virtual directory can be anywhere on the server or even on another server.

Third, and this process can be trickier still, verify that all files any Web applications call, including executables and scripts, have sufficient permissions. Remember to include files called from scripts (e.g., Active Server Pages—ASP—files).

If this process sounds like a lot of work, it is. You're in luck, however, because an excellent tool can reduce this task to minutes. File Monitor (Filemon) is free from http://www.sysinternals.com. Filemon opens a window that displays not only each file access that the system performs but also the kind of access and its success or failure. Figure 1 shows a Filemon display. When I have a permissions error that looks challenging, I can often short-circuit the entire troubleshooting process by launching Filemon, starting event capturing, then attempting the access that has been denied from a remote system. I then stop the event log and review the displayed results, looking for information about failed access. You can quickly spot problems with nested Include files, databases, invoked executables, content in virtual directories, and other problems that can remain hidden if you simply browse the file listing. Filemon is, to put it mildly, indispensable.