|
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.
Other Possible Causes of Connection Failure
The Error Isn't Always Where You Think
If you've been unable to resolve your permissions problem so far, then perhaps your error may not be occurring where IIS says it is. This is especially true when dealing with ASP environments that use the <!-- #include --!> command.
For example, suppose that you were getting an access denied error on the DEFAULT.ASP file. There's a possibility that you may very well have permissions to access DEFAULT.ASP, but not one of the other ASP files that is included with it. For example, if DEFAULT.ASP had instructions to include TOOLS.ASP, and TOOLS.ASP had some sort of ACL block on it, then you could very well get an access denied message when accessing DEFAULT.ASP. DEFAULT.ASP is fine, but one of the required subcomponents isn't. Because IIS isn't calling that subcomponent directly, it reports the error when accessing the page that called it, in this case DEFAULT.ASP.
Fortunately, it's relatively easy to tell if a subcomponent is causing your access woes. Just comment out any Include statements. If your problem goes away, then you know that one of the Include commands was causing the problem. Next, re-enable one Include command at a time, testing the Web site between each one. By doing so, you can quickly narrow down which command is causing your problems.
Check Your Account
Another troubleshooting technique would be to look at the entries in the Security Log and see which account is being used to access the site. For some reason, maybe an unintended account is in use. If this is the case, then it explains right away why access is being denied. Even if the account that's listed in the Security Log is the intended account, the log still gives you solid evidence of which account is in use. This means that you can check the account's ACL with confidence, knowing that you are on track.
When checking an account's permissions, there are some specific things to look for. For example, the account must have NTFS-level access to the directory that contains the Web site and all of the directories beneath it. Likewise, you should also check to see if the account has Log On Locally or Network Logon permissions.
Unexpected Errors
Occasionally, there may be a situation where users are expected to need only read access to a Web site, but you receive error messages indicating that a user doesn't have the necessary write or delete permissions. Typically, if these types of unexpected errors occur on a new Web site, it doesn't mean that you have an attempted security breach. Instead, it often means that some subcomponent of the Web page requires write or delete access. An example of such a subcomponent might be a hit counter.
Anonymous Authentication
The vast majority of Web sites use anonymous authentication. This means that the user isn't required to enter a user name and password. However, for the sake of security, authentication is still occurring; it's just hidden from the user. Anonymous authentication works by using a designated user account's permissions to access the Web site. Any time that you use anonymous authentication, the designated user account must exist, have a valid password, and must not have expired or have been deleted. All of the other standard security mechanisms also apply, such as the account's ACL or designated logon hours.
You can see which account is being used for anonymous authentication by right clicking on the virtual server in the Computer Management console and selecting the Properties command from the resulting context menu.. When the site's properties sheet appears, select the Directory Security tab and click the Edit button found in the tab's Anonymous Access and Authentication Control section. When you do, the Authentication Methods dialog box will appear. Make sure that the Anonymous Access check box is selected, and then click the Edit button to verify which account is being used.
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.
About the Author
Brien Posey is the executive vice president of research at Relevant Technologies, Inc. Brien is an MCSE and a renowned technology journalist. He was recently voted the most popular server author on CNET's TechProGuild portal. Brien can be reached at brien@brienposey.com. Due to the high volume of messages that he receives, it's impossible for him to respond to all of them, although Brien does read them all.
|
