How to Troubleshoot Permissions in Internet Information Server 4.0

ID: Q185874


The information in this article applies to:
  • Microsoft Internet Information Server version 4.0


SUMMARY

Access to resources can be a complex issue when you are securing your Web server. This article discusses some best practices and rules of thumb for troubleshooting the issues.


MORE INFORMATION

Often site administrators work blind when trying to troubleshoot access problems. Monitoring how the server is being used is a good place to start.

Monitoring Server Use

The following procedure outlines how to set up auditing and logging:
  • Auditing User Logons

    1. Open User Manager for Domains.


    2. On the Policies menu, select Audit.


    3. Select Audit These Events.


    4. Choose both Success and Failure for Logon and Logoff.


    5. Click OK.




  • Auditing File and Object Access (in two parts)

    1. Enabling Auditing on Objects

      1. Open User Manager for Domains.


      2. On the Policies menu, select Audit.


      3. Select Audit These Events.


      4. Choose both Success and Failure for File and Object Access.


      5. Click OK.




    2. Selecting Objects to Audit

      1. Start Windows NT Explorer.


      2. Select the file or folder that you want to audit.


      3. Right-click the file or folder and select Properties.


      4. Select the Security tab.


      5. Click the Auditing button.


      6. Click the Add button.


      7. Select Everyone, click Add, and then click OK.


      8. Select Success and Failure for all of the following:

        • Read


        • Write


        • Execute




      9. Click OK.






  • W3C Extended Logging

    1. Start the Internet Service Manager (ISM).


    2. Select the server in question.


    3. Right-click on the Web site and select Properties.


    4. Select Enable Logging.


    5. Click the Properties button.


    6. Click the Extended Properties tab.


    7. Select (at least) the following:

      • Date


      • Time


      • Client IP Address


      • User Name


      • Method


      • HTTP Status


      • Win32 Status




    8. Click OK to exit the logging properties.


    9. Click OK to exit the Web site properties.




Now basic auditing is in place. Perform the following steps:

  1. Clear any cached logon information by stopping and then restarting the Web Service:\


  2. From a CMD.EXE prompt, type the following:
    NET STOP IISADMIN


  3. Answer "y" to shut down all dependent services.


  4. Restart each dependent service stopped in the previous step with:
    NET START W3SVC (starts World Wide Web Publishing Service).
    NET START MSFTPSVC (starts FTP Publishing Service).
    NET START SMTPSVC (starts Microsoft SMTP Service).
    NET START NNTPSVC (starts Microsoft NNTP Service).


  5. On Control Panel, double-click Services.


  6. Select the IIS Admin Service and click Stop.


  7. Click OK to shut down all dependent services.


  8. Manually start each dependent service stopped in the previous step.


  9. Clear the Security Log.


  10. Open the Event Viewer.


  11. On the Log menu, select Security.


  12. On the Log menu, select Clear All Events.


  13. It is recommended you save the existing security log by selecting "Yes" and choosing a folder or file to save to.


  14. Select "Yes" to clear the security log.


Troubleshooting the Web Server

After all the above steps have been performed, try to access the resource in question from a browser. If you refresh the security log in the event viewer, a series of audited events should be listed. Examine the security log entries and ask these questions:
  1. Are there any access-denied errors in the audit log? (You may see some errors related to Object Access and Protected Storage; these are benign.)


  2. What account is being logged on? Is it what you expected?


  3. Does this account have access to the file in question? You can check this by looking at the file access entries in the audit log.


  4. What about the W3C log? Are there any 401s or 403s? Why are they there?


The following are some golden rules and tips regarding permissions and IIS 4.0:
  • If Anonymous Authentication is turned on, this will always be used over Basic or Windows NT Challenge/Response Authentication.


  • Accessing data in an ASP file requires the account that is logging on to have access to the ADO and ODBC directories.


  • If you are using a page count component, the account logging on must have write and possible delete access to the file or registry entry it uses to persist its count.


  • Any account used for Anonymous or Basic Authentication must have the Logon Locally privilege. This is configured in User Manager for Domains, under Policies, User Rights.


  • You can change the privilege type in the preceding item to Batch or Network. Look up the LogonMethod in the IIS documentation.


  • Accessing a remote computer from an IIS computer may fail. This is because Windows NT cannot pass the user's security information to the other computer. To verify this, perform the auditing steps listed above on the remote computer in question as well as the IIS computer.


  • Internet Explorer 4.0 or later can be configured to only support certain authentication protocols. You can set these protocols by going to the Edit menu and selecting Internet Properties, Security, Custom, Settings, Authentication. If you select Anonymous Logon, the browser will not support any authentication schemes other than Anonymous.


  • Check the IP and Domain Restrictions. Right-click the virtual server in question, and select Properties, Directory Security, IP Address and Domain Name Restrictions, and then Edit.


  • If you are using Anonymous Authentication, check whether the anonymous account is valid (correct password and logon times) and enabled. Right- click the virtual server in question, and select Properties, Directory Security, Anonymous Access and Authentication Control, Edit, and Edit. Also check in User Manager for Domains.


  • If you are using <!-- #include --!> statements, errors may be caused because access is denied on the included file, not the main file. For example, if Default.asp #includes Tools.asp, but Tools.asp has a restrictive ACL, then an error may be reported on Default.asp, even though the logged-on account has access to it. To check for this you may wish to temporarily comment out #include statements until you have successfully resolved the situation.


Troubleshooting Resources

The following are recommended resources to aid you in troubleshooting complex issues:

Keywords :
Version : WINNT:4.0
Platform : winnt
Issue type : kbhowto


Last Reviewed: May 14, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.