Udostępnij za pośrednictwem

Security-Related Changes in Authentication

  • Artykuł

Applies To: Windows Server 2003, Windows Server 2003 with SP1

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

  • Anonymous password synchronization requires the IIS subauthentication component, Iissuba.dll, which was installed by default in earlier versions of IIS. The subauthentication component allows IIS to authenticate an anonymous user even if the password in the IIS metabase does not match the password in the Windows local account database. Because this involves a security risk, the subauthentication component is not installed by default in IIS 6.0. However, some administrators need to use anonymous password synchronization, in, for example, large ISP settings where thousands of anonymous IIS accounts are used to isolate Web sites.

  • For more information about enabling subauthentication and anonymous password synchronization, see Configuring Subauthentication on a New Installation of IIS 6.0.

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:

  • IIS servers in workgroups, because no Group Policy is available to populate the cache.

  • Cross Certificates, because the certificates might not be published into the Directory Service so Group Policy can populate the cache.

  • IIS servers that are set to explicitly trust a foreign Certification Authority (CA).

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

  • If your site is referenced by a Windows Internet Name Service (WINS) or Domain Name System (DNS) name that is different from the computer name of the server running IIS (a Web farm, for example), authentication defaults to NTLM (which is also known as Microsoft Windows NT® Challenge/Response authentication).

  • If you configure the worker process for the Web site to run as a domain account, and you did not use a WINS or DNS name, authentication will fail. This is because the SPN can be found, but it is registered for the Network Service and LocalSystem user accounts, not for the domain account under which the worker process is running.

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 https://www.microsoft.com/reskit.

Forcing NTLM

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.