Error 401.1 when when using integrated authentication and a custom service account

There's a great MSDN article, with step by step instructions on how to set up a service account for an ASP.NET 2.0 application should you not want to user the Network Service account.

Once a user account has been created, assign ASP.NET permissions to the new account by running the command below from the framework prompt.

aspnet_regiis -ga MachineName\AccountName

Where MachineName is the name of your server or the domain name if you are using a domain account, and AccountName is the name of your custom account. When you run aspnet_regiis.exe with the -ga switch, the command grants the following rights to the account:

• Access to the IIS Metabase Permission to write to the %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET Files folder
• The account is also a member of the local Users group; therefore, it has read access to the \Inetpub directory tree (these directories have an ACL that grants read access to the Users group).

Should you be using the XmlSerializer Class, the account must also have permission to write to the temporary directory (as defined by the TEMP environment variable) in order to deserialize an object.

The article also details one of the disadvantages of using a custom account -

When you change the identity of your application pool to use a domain account instead of a machine account, you lose the ability to perform Kerberos authentication until a domain administrator runs the Setspn utility to create a service principal name (SPN) for the domain account. If you have multiple applications on the same server that use separate domain identities and they need to use Kerberos authentication, then you need to use separate Domain Name System (DNS) names for each application.

If your account does not have a service principal name and for some time, your web site will require authentication and user's will be prompted for a user name and password but even valid credential will not be authenticated. Should you be unable to create a service principle name, another MSDN article, How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication, details how to enable/disable Kerberos authentication.

IIS passes the Negotiate security header when Integrated Windows authentication is used to authenticate client requests. The Negotiate security header lets clients select between Kerberos authentication and NTLM authentication.

1. the following command, usually located in C:\Inetpub\Adminscripts to retrieve the current values for the NTAuthenticationProviders metabase property:

cscript adsutil.vbs get w3svc/WebSite/root/NTAuthenticationProviders

In this command, WebSite is a placeholder for the Web site ID number. The Web site ID number of the default Web site is 1.

This command fails if the NTAuthenticationProviders metabase property is not defined. If the Negotiate process is enabled, this command returns the following information:

NTAuthenticationProviders : (STRING) "Negotiate,NTLM"

2. If the command in step 1 does not return the string "Negotiate,NTLM," use the following command to disable the Negotiate process:

cscript adsutil.vbs set w3svc/WebSite/root/NTAuthenticationProviders "NTLM"

Repeat step 1 to verify that the Negotiate process has been disabled.

Next week, I'm going to look into how the Microsoft Authentication and Access Control Diagnostics 1.0 Tool could have helped solve this problem.