IIS Authentication Issues

Because the authentication process starts with IIS, make sure IIS is configured correctly.

• Make sure a user is being authenticated. Consider enabling just Basic authentication and manually log in to ensure you know what principal is being authenticated. Log in with a user name of the form “domain\username”.

• Restart IIS to ensure log on sessions aren’t being cached. (Run IISReset.exe to restart IIS).

• Close your browser between successive tests to ensure the browser isn’t caching credentials.

• If you are using Integrated Windows authentication, check browser settings as described below.

  • Click Tools from the Internet Options menu and then click the Advanced tab. Select Enable Integrated Windows Authentication (requires restart). Then restart the browser.

  • Click Tools from the Internet Options menu, and then click the Security tab. Select the appropriate Web content zone and click Custom Level. Within User Authentication ensure the Logon setting is set correctly for your application. You may want to select Prompt for user name and password to ensure that for each test you are providing explicit credentials and that nothing is being cached.

  • If the browser prompts you for credentials this could mean you are currently logged into a domain that the server doesn’t recognize (for example, you may be logged in as administrator on the local machine).

  • When you browse to an application on your local computer, your interactive logon token is used, as you are interactively logged onto the Web server.

• Test with a simple Web page that displays security context information. A sample page is provided later in this chapter.

  If this fails, enable auditing on the requested file and check the Security event log. You must also enable auditing using Group Policy (through either the Local Security Policy tool, or the Domain Security Policy tool). Examine the log for invalid usernames or invalid object access attempts.

  • If your Web application is having problems accessing a remote resource, enable auditing on the remote resource.

  • An invalid username and/or password usually means that the account used to run ASP.NET on your Web server is failing to be correctly authenticated at the remote computer. If you are attempting to access remote resources with the default ASPNET local account, check that you have duplicated the account (and password) on the remote computer.

  • If you see an error message that indicates that the login has failed for NT AUTHORITY\ANONYMOUS this indicates that the identity on Web server does not have any network credentials and is attempting to access the remote computer.

    Identify which account is being used by the Web application for remote resource access and confirm that it has network credentials. If the Web application is impersonating, this requires either Kerberos delegation (with suitably configured accounts) or Basic authentication at the Web server.

Using Windows Authentication

If the <authentication> element in your application’s web.config is configured for Windows authentication, use the following code in your Web application to check whether anonymous access is being used (and the authenticated user is the anonymous Internet user account [IUSR_MACHINE]).

WindowsIdentity winId = HttpContext.Current.User.Identity as WindowsIdentity;
if (null != winId)
{
  Response.Write(winId.IsAnonymous.ToString());
}

Using Forms Authentication

Make sure that the cookie name specified in the <forms> element is being retrieved in the global.asax event handler correctly (Application_AuthenticateRequest). Also, make sure the cookie is being created. If the client is continuously sent back to the login page (specified by the loginUrl attribute on the <forms> element) this indicates that the cookie is not being created for some reason or an authenticated identity is not being placed into the context (HttpContext.User)

Kerberos Troubleshooting

Use the following tools to help troubleshoot Kerberos related authentication and delegation issues.

• Kerbtray.exe. This utility can be used to view the Kerberos tickets in the cache on the current computer. It is part of the Windows 2000 Resource Kit and can be downloaded from http://www.microsoft.com/downloads/search.asp. Search for “Kerbtray.exe”.

• Klist.exe. This is a command line tool similar to Kerbtray, but it also allows you to view and delete Kerberos tickets. Once again, it is part of the Windows 2000 Resource Kit and can be downloaded from http://www.microsoft.com/downloads/search.asp . Search for “Klist.exe”

• Setspn.exe. This is a command-line tool that allows you to manage the Service Principal Names (SPN) directory property for an Active Directory service account. SPNs are used to locate a target principal name for running a service.

  It is part of the Windows 2000 Resource Kit and can be downloaded from http://www.microsoft.com/downloads/search.asp. Search for “setspn.exe”.