Copyright Notice

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Authentication and Access Control Diagnostics Version 1.0

Overview Main Notes Syntax Examples Related Tools

Overview

Authentication and Access Control Diagnostics (Authdiag) Version 1.0 allows you to review, test, and correct problems with Internet Information Services (IIS) authentication and authorization. You can use Authdiag to check settings on Web sites, FTP sites, virtual directories, Web directories, and files. Authdiag can help you troubleshoot the following types of issues:

Authdiag provides both user interface (UI) and command-line modes of operation. Both modes are used for troubleshooting authentication and authorization problems on a local server. Both the UI and command-line modes allow you to troubleshoot a single failure or multiple failures. Each time you run Authdiag, the tool stores all transactions in a History folder, so you have a record of the results of your queries.

System Requirements

Authdiag is compatible with the following operating systems and IIS versions:

For the latest information about Authdiag, see Authentication and Access Control Diagnostics Version 1.0.

Back to Top.

© 2004 Microsoft Corporation. All rights reserved.

Main

This section explains how to use Authdiag to troubleshoot IIS authentication and authorization issues. This section contains the following topics:

Getting Started with Authdiag

This section explains how to perform basic Authdiag tasks.

To install Authdiag

  1. Download the Authdiag.msi file.
  2. Click Open to install Authdiag on your computer.
  3. Click Next to begin the Authdiag 1.0 Setup Wizard.
  4. Read the License Agreement, click I accept the terms in the License Agreement, and then click Next.
  5. Follow the instructions to complete the rest of the setup wizard.

    The setup wizard installs Authdiag in the C:\Program Files\Microsoft\Authdiag folder by default.

Back to Top

To open AuthDiag from the Programs menu

  1. Click Start and then click All Programs.
  2. Click IIS Diagnostics and then click Auth Diagnostics 1.0.

Back to Top

To open Authdiag from the command line

  1. Open a command prompt window and navigate to the directory where Authdiag is installed. By default, this directory is C:\Program Files\Microsoft\Authdiag.
  2. At the command prompt, type:

    Authdiag

    to open Authdiag, or type:

    Authdiag -l

    to open Authdiag with a default .log file format, or type:

    Authdiag -l xml

    to open Authdiag with an XML log file format.

For more information about running Authdiag from the command line, see Syntax.

Back to Top

To configure Authdiag display properties

  1. Click File, and then point to Options.
  2. Toggle Toolbar to enable or disable the toolbar display.
  3. Toggle Status Bar to enable or disable the status bar display.
  4. Toggle Disable AuthMon Warning to enable or disable the warning text for the Authentication Monitor (Authmon) feature.

Back to Top

To copy Authdiag results

  1. Click Select All on the Edit menu, or select the content you want to copy.
  2. Click Copy on the Edit menu, or click Copy in the Actions list.
  3. Paste the content into a file, and then save the file.

Back to Top

To print the data displayed in the Authdiag window

  1. Click File and then click Print.
  2. Select a printer on the General tab of the Print dialog box.
  3. (Optional) Click Preferences to specify layout and paper properties, and then click OK.
  4. Click Print.

Back to Top

To go back to the Authdiag main page

  • Click Home in the Diagnostics Tools list.

Back to Top

To close Authdiag

  • Click File and then click Exit.

Back to Top

To uninstall Authdiag

  1. Click Start, click All Programs, click Control Panel, and then click Add or Remove Programs.
  2. Select Auth Diagnostics 1.0 from the list of currently installed programs, click Remove, and then click Yes.

Back to Top

Checking Authentication Failures

This section explains how to use Authdiag to check authentication failures on the computer where Authdiag is installed. Authdiag uses credentials provided by IIS to check anonymous authentication. You can provide credentials through the UI for testing other authentication methods. Authdiag uses a predefined set of criteria to test the following authentication methods:

Note

  • Authdiag does not test .NET Passport authentication.

To check Web or FTP site authentication

  1. Select Check Authentication from the Tasks list.
  2. Type a Web or FTP site name, a metabase path such as w3svc/1, or a Web site number in the Site field, and then click Start Diagnostics.

    If the URL you want to check is a virtual directory, Web directory, or file, you should include the full path, for example, http://localhost/myvdir/dir/page.htm.

  3. If an entry in the results list contains a Probe link, you can click the link to test authentication for a specific user.
  4. (Optional) View the site's configuration by clicking to expand the View Site Configuration section at the bottom of the Authdiag output display.

Back to Top

To test authentication for a specific user

  1. Type a Web or FTP site name, a metabase path such as w3svc/1, or a Web site number in the Site field, and then click Start Diagnostics.

    If the URL you want to check is a virtual directory, Web directory, or file, you should include the full path, for example, http://localhost/myvdir/dir/page.htm.

  2. On the Authdiag results page, click the Probe link.
  3. In the Enter User Credentials dialog box, type the domain name in Domain, type the user name in UserName, and type the user's password in Password.
  4. (Optional) Check Verify Password to verify the user's password.
  5. (Optional) Check Do not prompt again to perform the authentication without prompting for the user name and password for the duration of the current Authdiag session.
  6. Click OK. Authdiag returns either a "200 OK" message or a 401 error. You can continue to troubleshoot authentication errors by using the Authentication Monitor (Authmon) feature.

Back to Top

To check Kerberos authentication

  1. Select Check Authentication from the Tasks list.
  2. Type a Web or FTP site name, a metabase path such as w3svc/1, or a Web site number in the Site field, and then click Start Diagnostics.

    If the URL you want to check is a virtual directory, Web directory, or file, you should include the full path, for example, http://localhost/myvdir/dir/page.htm.

  3. Verify that Integrated Windows authentication is enabled on the site.
  4. Click Kerberos Configuration in the Diagnostics Tools list to view the server's Kerberos configuration.
  5. (Optional) View the site's configuration by clicking to expand the View Site Configuration section at the bottom of the Authdiag output display.

Back to Top

Checking Access Failures

This section explains how to use Authdiag to check directory or file access failures. Authdiag checks NTFS effective permissions, which are the sum of the NTFS permissions assigned to the user account and to all of the groups to which the user belongs. However, Authdiag does not detect share permissions that override NTFS effective permissions.

To check Web or FTP site permissions for a specific user

  1. Select Check Permissions from the Tasks list.
  2. Type the path to the Web or FTP site on the local computer in the Path field, and optionally click the Browse button to specify a subfolder whose permissions you want to check. To check permissions for a directory and all of its subdirectories and their files, append "\*" at the end of the directory name, for example, c:\inetpub\wwwroot\mysite\mydir\*.
  3. Type a user name in the Username field.
  4. Select the access types you want to check: Read, Write, or Full, and then click Start Diagnostics.
  5. (Optional) View the site's configuration by clicking to expand the View Site Configuration section at the bottom of the Authdiag output display.

Back to Top

To view file system permissions for a Web or FTP site's directory structure

  1. Select View Permissions from the Tasks list.
  2. Type the path to the Web or FTP site on the local computer in the Path field, click the Browse button to specify a subfolder whose permissions you want to check, and then click Start Diagnostics.

    Authdiag displays the directory structure permissions in the same format used by Cacls.exe, which displays or modifies discretionary access control lists (DACLs) on specified files.

  3. (Optional) View the site's configuration by clicking to expand the View Site Configuration section at the bottom of the Authdiag output display.

Back to Top

To view or change site properties

  • Click Open IIS Manager in the Quick Links list.

Back to Top

To view or change file system permissions

  • Click Open Windows Explorer in the Quick Links list.

Back to Top

To view or change user rights

  • Click Open Local Security Settings in the Quick Links list.

Back to Top

To view or change user and group accounts

  • Click Users and Groups Manager in the Quick Links list.

Back to Top

Monitoring URL Failures

If Authdiag does not detect any failures or warnings when it checks site configuration settings, you can use the Authmon feature to monitor failures on a single URL. Authmon retrieves the following information from a process that is currently running:

Authmon monitors critical calls for authentication and authorization and sends them to a log file called Authmon.log. This file is stored in the directory where Authdiag is installed. For more information on Authmon, see Authmon Reference.

This section explains how to use the Authmon feature of Authdiag to troubleshoot URL failures.

To monitor URL failures

  1. Select Monitor URL Failures from the Task list.
  2. Type a Web or FTP site name, a metabase path such as w3svc/1, or a Web site number in the Url field.
  3. Check Open the Url in a browser window to automate URL requests. You can leave this option unchecked to use a browser other than Internet Explorer. If you leave this option unchecked, you must manually open a browser window to type and submit the URL request.
  4. Read the warning message about Authmon behavior, click Continue, and then click Start Diagnostics. This message does not appear if you selected Disable AuthMon Warning from the Options list on the File menu.

    If you use Authmon over a terminal server session on Windows Server 2003, you must specify the /console option when you initiate the session, as shown in the following example:

    mstsc /v:server name /console

    Authmon cannot run over a terminal server session on Windows 2000 Server; you must run the tool from the console session of the local computer.

  5. Click Stop Monitoring to stop monitoring after Authmon has gathered information, and then click Analyze Results to view the collected data. See Authmon Log File Example for an example of the log file format.
  6. (Optional) Click Restart Monitoring to resume monitoring the URL.

Back to Top

Logging Authdiag Results

This section explains how to save Authdiag results to a log file. Authdiag logs can be saved as .log files, .xml files, or .txt files. For an example of log file formats, see Authdiag Output Formats.

Note

  • A log file is different from a history file, which is created every time Authdiag is run. For an example of a history file, see Authdiag History File Example.

To save information to a log file

  1. On the Authdiag results page, click File, and then click Save As.
  2. Select the directory where you want to save the file, type the name of the file in the File name box, choose a file type from the Save as type list, and then click Save.

Back to Top

To open a log file for analysis

  1. Click File, and then click Open.
  2. Navigate to the directory where the log file is located, select the file, and then click Open.

Back to Top

© 2004 Microsoft Corporation. All rights reserved.

Notes

This topic contains the following information:

Resolving Authentication and Authorization Issues

The following table describes authentication and authorization issues Authdiag can help you resolve.

Issue Example
"Access Denied" errors caused by NTFS authorization failures. Access failures based on a user token; for example, 401.3 errors.
"Access Denied" errors caused when an authenticated user does not have the correct user rights. One of the following user rights might be missing:
  • Log on as a Batch Job (SeBatchLogonRight)
  • Allow Log on Locally — IIS 6, Log on Locally — IIS 5 (SeInteractiveLogonRight)
  • Access this computer from the network (SeNetworkLogonRight)
  • Logon as a Service (SeServiceLogonRight)
  • Adjust Memory Quotas for a Process (SeIncreaseQuotaPrivilege)
  • Replace a process level token (SeAssignPrimaryTokenPrivilege)
  • Impersonate a client after authentication (SeImpersonatePrivilege)
"Access Denied" errors caused by incorrect permissions for registry keys. IIS 5.0 and 5.1:
  • InetStp
  • W3svc (if installed)
  • MsFtpSvc (if installed)
  • ASP
  • IISAdmin
IIS 6.0: all of the above, plus HTTP
"Access Denied" errors based on incorrect configuration of IIS metabase. No Read or Write access to metabase property, resulting in a 403.2 error.
Authentication failure based on invalid configuration.

The following authentication types can fail for the following reasons:

  • Kerberos: Service Principal Names (SPN) registered incorrectly (See Kerberos Failure When Worker Processes Use Custom Identities for an example of this scenario).
  • Integrated: HTTP Keep-Alives not enabled, user does not have the Access this computer from the network user right.
  • Anonymous or Basic: LogonMethod specified but user lacks appropriate rights, such as Log on locally or Log on as a batch job.
  • (IIS 5.0 and 5.1) Digest: The subauthentication component, IISSuba.dll, is not registered, and Active Directory is not reachable.
  • (IIS 6.0)
    • Digest: The subauthentication component, IISSuba.dll, is not registered, and the worker process identity is not set to run as Local System.
    • Advanced Digest: UseDigestSSP is not set correctly in metabase.
Configuration issues related to IIS communication with a remote UNC server, as well as configuration issues with the UNCUserName or UNCUserPass metabase properties.
  • Lacking configured UNC passthrough authentication enabled on IIS 5.0 and 5.1.
  • Invalid user name specified in the Connect as dialog box.
  • Invalid UNC path specified (for example, \\server\share not reachable).
  • Invalid password specified in the Connect As dialog box.
Problems with system default permissions for IIS. These failures would be based on any incorrect permissions to directories such as those listed here.
  • See article 271071 "HOW TO: Set Basic NTFS Permissions for IIS 5.0."
  • See article 812614 "INFO: Default Permissions and User Rights for IIS 6.0."
Failure within an Active Server Page (ASP) file based on failed permissions. Calls to CoCreateInstance in Inetinfo.exe or W3WP.exe. See the Examples section for scenarios.
Failure to access home directory or FTProot because the accessing role, for example, Anonymous User or Authenticated User, does not have the appropriate permissions.
  • IIS 5.0 and 5.1: For more information about permissions failure based on invalid NTFS configuration, see article 201771, "How to Set Up an FTP Site So That Users Log On To Their Folders," in the Microsoft Knowledge Base.
  • IIS 6.0:
    • Invalid file system permissions based on FTP User Isolation setting.
    • Invalid server set for FTP property in Active Directory.
    • Invalid share set for FTP property in Active Directory.

Back to Top

Status Messages

The following table shows the status messages Authdiag returns while running and upon completion.

Status Message Description
Success: Log Created Defines the end of execution and allows you to open the log file.
Status…Executing <command> Provides status while the tool is running. <command> contains the command you entered on the command line, for example: Authdiag - L:xml -url:http://localhost
Failure: Error Displays the error message and reason why the log file was not created.

Back to Top

Error Messages

Authdiag displays one of the following error messages in response to the appropriate error:

Error Message Description
%InvalidSyntax% The command syntax is not valid. For valid syntax, type the following command at the command prompt: 
Authdiag /?
%UserPass% (Invalid User or Password) The user specified on the -p parameter does not exist on the system, or the password for that user is not valid.
%InvalidDir% (Invalid Directory) The - d parameter points to a directory that is not valid or not specified. An example of the valid format for a directory path is C:\Inetpub\wwwroot.

Back to Top

Authdiag Output Formats

Authdiag allows you to save the results of authentication or authorization checks as log files. Log files can be saved as .log, .xml, or .txt files. You can use any text editor to read a log file.

The following example shows Authdiag results that have been saved as a .log file:


System time=Wed, 21 Jul 2004 01:55:34 GMT
Host name=iisue02
Dns suffix=sales.contoso.com
Domain name=CONTOSO
ModuleFileName=C:\Program Files\Microsoft\AuthDiag\i386\authdiag.exe version: 1.0:34.0
OS=Windows 2003
NT AUTHORITY\LOCAL SERVICE  Found privileges:Log on as a batch job; Adjust memory quotas for a process; Replace a process level token; 
NT AUTHORITY\NETWORK SERVICE  Found privileges:Log on as a service; Adjust memory quotas for a process; Replace a process level token; 
BUILTIN\Administrators  Found privileges:Allow log on locally; Access this computer from the network; Adjust memory quotas for a process; Impersonate a client after authentication; 
BUILTIN\Users  Found privileges:Access this computer from the network; 
COMPUTER1\IUSR_COMPUTER1  Found privileges:Log on as a batch job; Allow log on locally; Access this computer from the network; 
COMPUTER1\IWAM_COMPUTER1  Found privileges:Log on as a batch job; Access this computer from the network; Adjust memory quotas for a process; Replace a process level token; 
COMPUTER1\IIS_WPG  Found privileges:Log on as a batch job; Impersonate a client after authentication; Log on as a batch job; 
Error:		COMPUTER1\ASPNET  Found privileges:Deny log on locally; Access this computer from the network; Log on as a batch job; Log on as a service; 
Error:		COMPUTER1\ASPNET  not found Impersonate a client after authentication
Everyone  Found privileges:Bypass traverse checking; 
NT AUTHORITY\SERVICE  Found privileges:Impersonate a client after authentication; 
Done

Finished, system time: Wed, 21 Jul 2004 01:55:34 GMT

The following example shows the schema for Authdiag XML output (.xml files):

<AuthDiag>
<SystemInformation>
      <Host Name=""/>
      <DNSSuffix Name=""/>
      <Domain Name=""/>
      <Module Name=""/>
      <OSVersion Name=""/>
      <IIS IsInstalled="True/False"/>
      <!--The child nodes will be present only if IIS is installed on the machine-->
                  <Version Number=""/>
                  <WebService IsInstalled="True/False">
                  <FtpService IsInstalled="True/False">
      </IIS>
</SystemInformation>
 
<Analyze>
   <Result>      DataType = "Error, Warning"
     <Source>  DataType = "NTFS, Metabase, Policy, Registry"
        <Path   DataType = "C:\, w3svc, Local, HKLM">
        <User   DataType = "IUSR, Chris">
        <Description  DataType = "String">
     </Source>
   </Result>
</Analyze>

<Authentication>
   <URL>    DataType = "String - HTTP://"
     <UserCredential  DataType=Str (IUSR)>
     <AuthType  DataType=Str (AuthNTLM)>
     <ResponseHeader  DataType=Str ()>
     <ResponseStatus  DataType=Str ()>
   </URL>
</Authentication>

<Permissions>
   <Path>
     <Dump>  <!-- Raw Data from CACLS-->
   </Path>
</Permissions>

<Monitor Data>
   <URL>
     <Verb   DataType=String (Get)>
     <AuthHeader    DataType=String (SDF#@@#$@#$)>
     <ProcIdentity  DataType= String (NT Authority\Network Service)>
     <ThreadIdentity    DataType= String (Machine\UserA)>
     <Resource   DataType= String (d:\test)>
     <Result   DataType=Int  (5 = Access Denied)>
   </URL>
  </Monitor Data>
</AuthDiag>

Back to Top

Authdiag History File Example

The following example shows the format of an Authdiag history file. The History folder is located in the directory where Authdiag is installed.


- <AuthDiag>
  <Begin Time="Mon, 19 Jul 2004 22:55:27 GMT" /> 
- <SystemInformation>
  <Host Name="computer1" /> 
  <DnsSuffix Name="sales.contoso.com" /> 
  <Domain Name="CONTOSO" /> 
  <Module Name="C:\Program Files\Microsoft\AuthDiag\i386\authdiag.exe version: 1.0:34.0" /> 
  <OSVersion Name="Windows 2003" /> 
  </SystemInformation>
- <Analyze Type="WebSite" Url="HTTP://LOCALHOST" />
  <Result Type="Error" Path="W3SVC" AuthType="Kerberos" Text="Service principal name (SPN) for machine 'computer1' not found in Active Directory" /> 
  <Result Type="Error" Path="W3SVC/1/ROOT" AuthType="Kerberos" Text="Service principal name (SPN) for machine 'computer1' not found in Active Directory" /> 
  <Result Type="Error" Path="W3SVC/1/ROOT/aspnet_client" AuthType="Kerberos" Text="Service principal name (SPN) for machine 'computer1' not found in Active Directory" /> 
  <Result Type="Info" Text="Done" /> 
  </Analyze>
  <End Time="Mon, 19 Jul 2004 22:56:51 GMT" /> 
  </AuthDiag>

Back to Top

IIS 5.0 and IIS 5.1 Default User Rights

Problems with authentication and authorization can be caused by changes to user rights or conflicts with Group Policy settings. With Authdiag, you can view the assigned user rights to ensure that your server is configured correctly.

The following table shows default user rights for IIS 5.0 and IIS 5.1.

User or Group Default User Rights
BUILTIN\Administrators
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
BUILTIN\Users
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
IUSR_ComputerName
  • SeBatchLogonRight
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
IWAM_ComputerName
  • SeBatchLogonRight
  • SeNetworkLogonRight
ASPNET
  • SeNetworkLogonRight
  • SeBatchLogonRight
  • SeServiceLogonRight
Everyone
  • SeChangeNotifyPrivilege
NTAuthority\Service
  • SeBatchLogonRight
NTAuthority\Network
  • SeBatchLogonRight
  • SeServiceLogonRight

Back to Top

IIS 6.0 Default User Rights

The following table shows the default user rights for IIS 6.0.

User or Group Default User Rights
BUILTIN\Administrators
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
  • SeIncreaseQuotaPrivilege
  • SeImpersonatePrivilege
BUILTIN\Users
  • SeNetworkLogonRight
IUSR_ComputerName
  • SeBatchLogonRight
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
IWAM_ComputerName
  • SeBatchLogonRight
  • SeNetworkLogonRight
  • SeIncreaseQuotaPrivilege
  • SeAssignPrimaryTokenPrivilege
ASPNET
  • SeDenyInteractiveLogonRight
  • SeNetworkLogonRight
  • SeBatchLogonRight
  • SeServiceLogonRight
  • SeImpersonatePrivilege
Everyone
  • SeChangeNotifyPrivilege
NTAuthority\Service
  • SeImpersonatePrivilege

Back to Top

Authmon Reference

Authmon checks real-time authentication or authorization requests for a URL you want to monitor. Because this check occurs within the Authdiag tool, Authmon must stop the process that is currently running, and then restart the process to begin monitoring. When you select Monitor URL Failures from the Tasks list, a warning message is displayed to explain how Authmon works. You can either choose to run Authmon by clicking Continue or choose another task to perform. You can disable the warning message by selecting Disable Authmon Warning from the Options list on the File menu.

The following table shows how Authmon works with each version of IIS.

Operating System and IIS Version Behavior
  • Windows 2000 and IIS 5.0
  • Windows XP and IIS 5.1
  • Windows Server 2003 and IIS 6.0 running in IIS 5.0 isolation mode
  • Stops the IIS process (Inetinfo.exe)
  • Loads the IIS process with Authmon components (Authmon.dll and Authmon.sys)
Windows Server 2003 with IIS 6.0 running in worker process isolation mode
  • Stops the IIS worker process by recycling W3wp.exe
  • Loads the worker process with Authmon components (Authmon.dll and Authmon.sys)

Authmon presents the following information for you to analyze:

Information Description
HTTP or FTP verb sent to the server Helps determine whether Internet Server APIs (ISAPIs) or WebDAV are involved in the request. Examples of verbs include Get, Post, Put, and Delete.
URL being monitored Specifies that only requests for this URL are monitored. Paths can include /, /vdir, or /vdir/file.
Current authorization header being sent (if applicable) Verifies that faulty headers are not being sent for authentication.
The impersonating user Shows the user who is running the IIS worker process.
Thread identity obtained from the authorization header Displays the user who is attempting to access the resource.
The call being monitored (for example, CreateFile) Displays the specific resource being called.

Tip: If you see calls to iisreset and you are running IIS 6.0, you are running in IIS 5.0 isolaiton mode.
Status of the URL request Displays Success or Failed (with associated error).

Back to Top

Authmon Log File Example

The following example shows an excerpt from an Authmon log file in XML format. In this example, Authmon has detected that an ASP file calls an include file, Header.asp. The Hheader.asp file does not have the appropriate ACLs for anonymous access, so the call to the file results in an "Access denied" error.


<AuthMonRow Number="9" tid="0xeec" Date="07/19/2004 21:45:05.181"
 ProcIdentity="NT AUTHORITY\NETWORK SERVICE" ThreadIdentity="WEBDEMO1\IUSR_WEBDEMO1"
 Name="CreateFileW" Type="ASP" File="\\?\E:\INETPUB\WWWROOT\INCLUDES\HEADER.ASP"
 Success="No" Error_Number="5" Error=" Access denied"
 time_taken="0 ms"
 />

Back to Top

© 2004 Microsoft Corporation. All rights reserved.

Syntax

In command-line mode, Authdiag uses the required parameters shown in the following table.

Required Command-Line Parameter Description Example
-l:<log|xml> Specifies that command-line mode is to be used. Optionally, you can specify xml to create a log in XML format. By default, if -l is specified by itself, the default .log format is used. authdiag -l -url:http://localhost

This command creates the Authdiag.log file in the current directory and displays permissions for w3svc/#, which is localhost, the default Web site on the current computer. A copy of the log file is also stored in the History folder under the directory where Authdiag is installed.
- url:http://<path> Specifies the URL to be checked. authdiag -l xml -url:http://localhost/newvdir

This command creates the Authdiag.xml file in the current directory and displays permissions for the newvdir folder under the default Web site. A copy of the log file is also stored in the History folder under the directory where Authdiag is installed.

The following table describes optional parameters you can use with Authdiag in command-line mode.

Optional Command-Line Parameter Description Example
-u:<User|Group> string Specifies the user name or group name whose authentication settings you want to check. authdiag -1 -url:http://localhost -u:User1

This command specifies that a log file in the default .log format should be created in the current directory and permissions for the specified user on the specified directory should be checked. A copy of the log file is also stored in the History folder under the directory where Authdiag is installed.
-p:<Password formatted as a string of asterisks (*)> Specifies the password for the user whose authentication settings you want to check. authdiag -l -url:http://localhost -u:User1 -p:********

This command specifies that a log file in the default .log format should be created in the current directory. Both authentication and permissions for the specified user on the specified directory will be checked. A copy of the log file is also stored in the History folder under the directory where Authdiag is installed.
-analyze Performs the same function as the Check Authentication task on the UI. You can also provide a user name and password so Authdiag can verify the user and attempt to log on to the site. authdiag -l -url:http://www.contoso.com/salesweb/newvdir -analyze

This command checks authentication for the Web site specified by the -url option.

authdiag -url:http://www.contoso.com/salesweb/newvdir -u:user name -p:password

This command checks authentication for the Web site specified by the -url option, and then verifies the user and attempts to log on to the Web site.
-authmon:<start|stop> Starts the Authmon feature of Authdiag. It does not, however, generate any requests; you must manually enter the requests you want to test against the specified URL. The Authmon feature remains running until you run the authdiag command with the -authmon:stop option. authdiag -l -url:http://www.contoso.com/salesweb -monitor:start authdiag -l -url:http://www.contoso.com/salesweb -monitor:stop
-d:<Path> Specifies that you want to check permissions for the directory name given in the path. If you specify this parameter without the -u parameter, Authdiag displays all permissions for the path. If you specify the -u parameter, Authdiag checks path permissions for that particular user. authdiag -l -d:"c:\inetpub\wwwroot"

This command specifies that a log file in the default .log format should be created in the current directory. All permissions for the given path will be displayed. A copy of the log file is also stored in the History folder under the directory where Authdiag is installed.

Back to Top

© 2004 Microsoft Corporation. All rights reserved.

Examples

This topic describes the following authentication and permission failure scenarios that Authdiag can help you troubleshoot:

401.1 Authentication Failure

Authentication failures are generally caused by the lack of a valid user name, password, or configuration in the IIS metabase. If administrators cannot manage the remote account database, such as Active Directory or Netware Directory Services, they cannot ensure that the credentials added to the IIS metabase are valid and accurate. For example, suppose the problem involves metabase properties such as AnonymousUserName or UNCUserName. The failure might be a result of one of the following error situations:

For these situations, IIS returns a generic 401.1 "Login Failed" error message.

Back to Top

401.3 Failed ACL on File or Directory

File access permissions cause most of the problems that confront IIS administrators. Often, permission failures occur because content, system files, or components are not secured with the appropriate access control list (ACL) permissions. A common example of this problem is the FTP client without NTFS Write permission. Access can also fail because share permissions are not correctly set.

Troubleshooting permission failures is challenging because it is difficult to determine where the permission failure occurred. It might occur during an attempt to open a handle to the file itself (for example, Default.asp), or to subsequent files such as Asp.dll or Vbscript.dll, or to a file on a remote share that the user does not have permission to access.

Back to Top

401 Failed Authentication Because of Incorrect Rights in Token

Windows user rights that are not configured correctly can lead to an IIS failure and a 401.3 error. If a policy is applied on the IIS server, and that policy does not allow users to log on locally to the server, this scenario could occur.

IIS versions prior to IIS 6.0 place more reliance on having certain user rights for built-in accounts such as IUSR_ComputerName or IWAM_ComputerName. There can be many root causes for this type of failure, but this scenario is often caused if the following user rights do not exist:

Back to Top

Failure to Access a Page Based on Metabase Configuration

Errors in Web page display can often be traced to file access permissions that are incorrectly configured in the IIS metabase. IIS verifies access permissions for directories that include static content, such as .htm, .html, .jpg, and .zip files. You must configure Read access in the metabase for these directories, for either the anonymous user account or a domain account for a specific user. However, for directories that contain dynamic content, such as scripts or .asp files, you do not need to configure Read access in the metabase. This is because requests for dynamic content are passed to a component other than IIS, and that component is responsible for verifying file access permissions.

Incorrect file access permissions can cause page-access errors because some dynamic content contains nested files, such as include (.inc) files, that might call static files. If the Read property for these static files is not enabled in the metabase, or is not inherited from a higher-level folder, not all components of a Web page will be displayed correctly.

Similarly, files that have Write permission configured in the metabase can create a security risk, unless the anonymous user account requires this access. Web Distributed Authoring and Versioning (WebDAV) is one example where the anonymous account requires Write access to specific directories and files.

Back to Top

Kerberos Delegation Failure When Worker Processes Use Custom Identities

Kerberos configuration presents complicated troubleshooting scenarios. If you run IIS 6.0 in worker process isolation mode, application pools can be configured to run under custom domain accounts instead of the default Network Service account. In this situation, Kerberos configuration breaks because the custom domain account is not registered as a Service Principal in Active Directory.

In this scenario, an administrator configures an application pool to run as domain user fabrikam\user1. The administrator assumes that to run the application pool the only membership required is in the IIS_WPG group, so the user is added to that group. The worker process then starts successfully.

Soon, however, the administrator begins to receive complaints of failure when users attempt to access .asp or .aspx pages. Troubleshooting reveals that users are not authenticating using Kerberos; instead, they are reverting to NTLM. However, because NTLM tokens cannot be delegated, the access fails. Kerberos troubleshooting determines that the Service Prinicipal Name (SPN) is not registered correctly, because the worker process identity was changed from the default Network Service to a custom domain account. To correct this problem, the Domain Administrator must use the Setspn.exe tool to register the custom domain account as the SPN. Setspn.exe is included in the Windows Server 2003 Support Tools. For more information about Kerberos, see Troubleshooting Kerberos Delegation.

Back to Top

FTP User Isolation—File System Configured Incorrectly

FTP user isolation, a new feature in IIS 6.0, allows complete isolation of authenticated users. Any configuration errors return the "Home Directory Inaccessible" error message, which might cause users or administrators to assume that they do not have the correct permissions to access the FTP resource.

The correct way to set up local user isolation (that is, outside of Active Directory) is to create the following hierarchy:

Path = FTP Root Directory (c:\inetpub\ftproot)
LocalPath = Top-Level for Local Users (C:\inetpub\ftproot\LocalUser)
DomainPath = Top-Level for Domain Users (C:\inetpub\ftproot\Fabrikam)
User Home Directory = Directory for the user (not a virtual directory) (c:\inetpub\ftproot\LocalUser\FabrikamUser)

Without this configuration, users cannot log on to an FTP resource, because for anonymous access, user isolation requires the presence of either home directories or a public directory.

Back to Top

Removal of System Permissions for Process Identities Causes "Access Denied" Error

To strengthen security, administrators apply security policies or ACLs to the following system directories:

Any directory that is a child directory of %windir% inherits permissions from %windir% by default. If you choose to override the ACLs on child directories, IIS may fail to correctly serve ISAPI filter or ISAPI extension requests, including requests made by ASP.

For more information about default installation permissions for new installations of IIS, see articles Q271071, "HOW TO: Set Basic NTFS Permissions for IIS 5.0" and Q812614, "INFO: Default Permissions and User Rights for IIS 6.0," in the Microsoft Knowledge Base.

Note

  • These articles define default permissions, which are not the same as minimum permissions. You may need to configure permissions to ensure that users and groups have the required minimum permissions to access a specific resource.

Back to Top

© 2004 Microsoft Corporation. All rights reserved.

Related Tools

Permissions Verifier version 1.0 allows you to define a group of tasks that check permissions and user rights, and to select which tasks will execute at run time. Permissions Verifier provides sample XML files that you can use to verify permissions on a server running Internet Information Services (IIS). You can extend these sample files to enable the tool to check ACLs and permissions for users and groups. This allows you to verify that permissions issues are not causing Web server problems.

You can further customize the sample XML configuration files to add tasks and to change the tasks that are performed. In addition, you can create new XML configuration files and define new tasks and XML tags.

Permissions Verifier can perform five predefined tasks, which are specified in the sample XML configuration files installed with the tool:

Back to Top