Security-Related Changes in Authentication (IIS 6.0)
IIS 6.0 introduces a number of changes to user authentication. These changes include new default settings and requirements for different authentication methods.
Anonymous Password Synchronization is Disabled by Default
Advanced Digest Authentication Requires Windows Server 2003
To use Advanced Digest authentication, the domain infrastructure and the server running IIS must both be running Windows Server 2003. If you upgraded to IIS 6.0, the default digest authentication is Digest authentication. If you performed a clean installation of IIS 6.0, the default digest authentication is Advanced Digest authentication. For more information about Advanced Digest authentication, see Advanced Digest Authentication.
Intermediate Certificates Are Not Downloaded to Complete a Certificate Chain
When IIS receives an incoming SSL request from a client, IIS attempts to build its certificate chain before sending its certificate information back to the client. In IIS 6.0, missing intermediate certificates are not automatically downloaded by default, which was the behavior for previous versions of IIS. To ensure that client requests for SSL-enabled content can be served, you must manually add the intermediate certificate to the Intermediate Certification Authorities folder on the local computer. In addition, every time a certificate in the external chain is renewed or modified, you must manually update the certificate store. For information about manually updating the certificate store, see Client receives 403.16 error when IIS cannot process a complete certificate chain.
This change affects the following scenarios:
.NET Passport Authentication Requires LocalSystem User Account Rights
Microsoft .NET Passport authentication works only when the account that is used for the IIS worker process has trusted computing base(TCB) rights, which means that the account acts as part of the operating system. Only the LocalSystem user account has TCB rights by default. You can add TCB rights to an account by using the Local Security Settings snap-in. However, because a worker process running with TCB rights acts as part of the operating system, this account has a very high level of access, which presents a security risk.
Kerberos Authentication Requires SPNs for Multiple Worker Processes
You can isolate Web sites that are in different worker processes and running under different identities; however, unexpected IIS behavior might occur if you use Integrated Windows authentication. Integrated Windows authentication attempts to use Kerberos authentication, which might not work, depending upon the identity of the worker process. To use Kerberos authentication, a service must register its Service Principal Name (SPN) in the account in the Microsoft Active Directory® directory service under which the service is running. By default, Active Directory registers the NetBIOS name or computer name and allows the Network Service or LocalSystem user accounts to use Kerberos. However, for Kerberos to work with the following configurations, you must first register an SPN:
You can use the Setspn.exe command-line tool to register an SPN on the account under which the worker process is running. You must be a domain administrator to set an SPN. The Setspn.exe tool is included in Resource Kit Tools for Windows Server 2003, available on the Windows Server 2003 Deployment Kit companion CD, or on the Web at http://www.microsoft.com/reskit.
When you isolate Web sites on a virtual directory level by configuring worker process identities as different domain accounts, Kerberos fails. If you are using Integrated Windows authentication, are not using a WINS or DNS name for the server running IIS, and you want to use a local user account or the Local Service user account as a worker process identity, Kerberos authentication fails because Active Directory does not trust the accounts.
To work around these issues, you can force IIS to use NTLM authentication by setting the NTAuthenticationProviders Metabase Property to NTLM.