0 Troubleshooting Authentication Issues In ASP.NET

The first step when troubleshooting authentication issues is to distinguish between
IIS and ASP.NET authentication failure messages.

If you are receiving an IIS error message you will not see an ASP.NET error code.
Check the IIS authentication settings for your application’s virtual directory.
Create a simple HTML test page to remove ASP.NET from the solution.

If you are receiving an ASP.NET error message, review the ASP.NET authentication
settings within your application’s web.config file.

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 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 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 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”.