Troubleshooting IIS Access Problems - IIS Tutorials

Introduction:Spending countless hours developing a Web site only to discover that no one can access it is frustrating. This article guides you through the process of troubleshooting Web-site access problems.

Possible Causes of Failed Access
Some of the more common causes of access troubles include broken network links, incorrect firewall settings, and IIS permission problems. The general networking-type problems tend to be easy to figure out. For example, if no traffic is able to flow in or out of your network, then there's a good chance that there's a broken network link somewhere. Likewise, if inbound traffic is flowing, but no one can access your Web site, some simple port sniffing can tell you if TCP port 80 is blocked on your firewall.
Depending on the responses that I receive to this article, I may write a full-fledged article on connection troubleshooting in the future. For now though, I'll focus this article on IIS access problems that are related to permission problems.

Setting Up the Security Log:
The first step in troubleshooting IIS connection problems is to have a clear understanding of what's really going on. A big part of doing so involves reading your event logs. However, without some tweaking on your part, the event logs may not display information that is helpful to you.

Since we're talking about IIS access problems that are related to permissions, we'll be working predominantly with the Security Log. Reconfiguring the Security Log involves telling IIS which information to log, stopping the IIS services, clearing any existing Security Log entries, and finally, restarting the IIS services. In case you're wondering, the reason for stopping the IIS services is because sometimes IIS caches security log information. Unless you stop and restart the services, it's possible for cached security information to show up in the Security Log even after you've cleared the existing log contents. Obviously this cached information can be misleading since it appears to be current. Therefore, I strongly recommend stopping and restarting the IIS services as a part of the Security Log configuration process.

Begin the configuration process by selecting the Computer Management command from the Programs Administrative Tools menu. Next, navigate through the Computer Management console tree to Services and Applications Internet Information Services. Expand the Internet Information Services container to reveal the Web sites beneath it. Right click on the Web site that you're having trouble with and select the Properties command from the resulting context menu. When you do, you'll see the Web site's properties sheet.Now, select the properties sheet's Web Site tab and select the Enable Logging check box. When you do, you'll have a choice of various log file formats. I recommend using the W3C Extended Log File Format. Click the Properties button to reveal the Extended Logging Properties sheet.

By default, the properties sheet's General Properties tab will be selected. This tab allows you to control how often a new log file will be created. How often you build a new log file is really a matter of personal preference, so whatever you want to choose is fine. More important is the Extended Properties tab. This tab allows you to select which pieces of information will be included in your log file entries. You may select whichever elements you want, but at a minimum the log entries should include the following elements:

Date, Time, Client IP Address, User Name, Method, HTTP Status, and Win32 Status.

When you've made your selections, click OK twice to return to the main Computer Management console screen.

Now that you've configured the Web site's logging options, it's time to clear the cache and clear any existing log entries. The first step in doing so is to stop the various IIS services. To do so, open a Command Prompt window by selecting the Command Prompt command from the Programs Accessories menu. Next, enter the following command:

NET STOP IISADMIN /Y

This single command will stop all of the IIS services. Once the services have stopped, leave the Command Prompt window open and open the Event Viewer by selecting the Event Viewer command from the Programs Administrative tools menu. When the Event Viewer opens, right click on the Security Log and select the Clear All Events command from the resulting context menu. Now, that you've cleared the cache and the Security Log, it's time to restart IIS. Return to the Command Prompt window and enter the following commands:

NET START W3SVC
NET START MSFTPSVC
NET START NNTPSVC
NET START SMTPSVC

Keep in mind that not all of these commands will apply to all servers. For example, if you aren't running the FTP service, then you can ignore the command that deals with FTP.

Checking the Security Log
Now that you've configured the Security Log, it's time to begin creating some log entries. To do so, try to access the Web site that's having problems. I recommend attempting to access the Web site from both inside and outside of the organization, and from a variety of computers, if possible. Doing so should give you some very useful log entries that you can compare against each other to determine the true nature of the problem. For example, you may discover that the Web site works correctly when accessed from inside the organization, but not when accessed from the outside. Another possibility is that the site may work fine for authenticated users, but not for anonymous users.

As you compile Security Log entries, the first thing that I recommend doing is scanning the log entries for 401 and 403 errors. There are a variety of 401 and 403 error codes, but knowing the exact error codes that are being generated can provide you with some excellent clues about the cause of the problem. Below I've listed the various 401 and 403 error codes and what these codes mean:

401;1 Unauthorized access because the logon has failed
401;2 Unauthorized access because the logon has failed due to the server
configuration
401;3 Unauthorized access because of an Access Control List (ACL) entry
401;4 Unauthorized access because an IIS filter is blocking access
401;5 Unauthorized access because of an ISAPI or CGI application
403;1 Forbidden because execute access isn't allowed
403;2 Forbidden because read access isn't allowed
403;3 Forbidden because write access isn't allowed
403;4 Forbidden because SSL use is required
403;5 Forbidden because 128-bit SSL use is required
403;6 Forbidden because the IP address was rejected
403;7 Forbidden because a client certificate is required
403;8 Forbidden because access to the site is denied
403;9 Forbidden because too many users are presently attached to the site
403;10 Forbidden because of an invalid configuration
403;11 Forbidden because of an invalid password
403;12 Forbidden because the Web site requires a valid client certificate
403;13 Forbidden because the client certificate was revoked
403;14 Forbidden because the directory listing is denied
403;15 Forbidden because the client access license count was exceeded
403;16 Forbidden because the client access certificate is invalid or untrusted
403;17 Forbidden because the client access certificate is expired or is not yet valid

With luck, checking your Security Log for 401 and 403 errors and comparing any errors that you might find against my list of error codes has helped you to narrow down the cause of your problems. If you still need some help, however, check out the sections below. They deal with specific types of permissions issues and how to fix them.

Conclusion

As you can see, IIS permissions-related problems can be a bit tricky. However, by taking a logical approach to these problems, you can easily solve them.