Authentication Methods in IIS

AUTHENTICATION METHODS IN IIS 6.0

Anonymous Authentication:

Anonymous authentication gives users access to the public areas of your Web or File Transfer Protocol (FTP) site without prompting the users for a user name or password. When a user attempts to connect to your public Web or FTP site, your Web server assigns the connection to the Windows user account that is specified for anonymous connections. By default, this account is named IUSR_ComputerName, where ComputerName is the name of the computer on which IIS is running, and it is included in the Windows user group, Guests. This group has security restrictions, imposed by NTFS file system permissions, which designate the level of access and the type of content that is available to public users.

When you use Anonymous authentication, the IUSR_ComputerName account is added to the Guests group on the computer running IIS during setup. When IIS receives a request, it impersonates the IUSR_ComputerName account before executing any code. IIS can impersonate the IUSR_ComputerName account because it recognizes the user name and password for this
account. Before returning a page to the client, IIS checks NTFS and directory permissions to see whether the IUSR_ComputerName account is allowed access to the file. If access is allowed, the access process, which is also called authorization, completes, and the resources are made available to the user. If access is not allowed, IIS returns a 401.3 error message to the browser.

You can change the account that is used for Anonymous authentication in IIS Manager, either at the Web server service level or for individual virtual directories and files. However, when you change the IUSR_ComputerName account, the changes affect every anonymous HTTP request that a Web server services, so use caution if you modify this account.

In IIS 6.0, NETWORK_CLEARTEXT is the default logon type for Anonymous authentication. As a result, Anonymous authentication no longer requires the Allow log on locally user right. More information about the NETWORK_CLEARTEXT logon type is provided in the next section.


Basic Authentication

The Basic authentication method is a widely used industry-standard method for collecting user name and password information. When you use Basic authentication, the browser displays a dialog box into which users are required to enter a previously assigned Windows account user name and password, which are also known as credentials. The browser then attempts to establisha connection to a server using the user’s credentials. The plaintext password is Base64-encoded before it is sent over the network.

Note that Base64 encoding is not encryption. If a Base64-encoded password is intercepted over the network by a network sniffer, unauthorized users can easily decode and reuse the password. Therefore, Basic authentication is not recommended unless you are confident that the connection
between the user and your Web server has been secured, such as with a dedicated line or an SSL connection. For more information about SSL, see “SSL and Certificates” later in this chapter.

If a user’s credentials do not correspond to a valid Windows user account, then Internet Explorer displays a dialog box into which the user re-enters his or her credentials. Internet Explorer — not IIS — allows the user three connection attempts before it terminates the connection and reports an error to the user. If a user’s credentials correspond to a valid Windows user account, then a
connection is established. Basic authentication does not automatically configure your Web server to authenticate users; to require authentication, you must also disable anonymous access. As a best security practice, you should create Windows user accounts with NTFS permissions properly set. For step-by-step instructions for configuring Basic authentication, see “Basic Authentication” in IIS 6.0 Help, which is accessible from IIS Manager.


Token Cache Security Considerations:

When you use Basic authentication, user tokens are cached in the token cache. By default, tokens remain in the cache for 15 minutes. If you want to change the amount of time that tokens remain in the cache, then complete either of the following steps:

• Disable user token caching by setting the global registry entry, UserTokenTTL, to zero (0).
• Change the UserTokenTTL metabase property to less than the default of 15 minutes. Note that time is expressed in seconds for this metabase property. For more information about the UserTokenTTL property, see “Global Registry Entries” in IIS 6.0 Help, which is accessible from IIS Manager.


Digest Authentication:

Digest authentication offers the same functionality as Basic authentication; however, Digest authentication provides a security improvement because a user’s credentials are not sent across the network in plaintext. Digest authentication sends credentials across the network as a Message
Digest 5 (MD5) hash, which is also known as the MD5 message digest, in which the credentials cannot be deciphered from the hash.

If you have an earlier version of IIS with Digest authentication enabled and you upgrade to IIS 6.0, Digest authentication remains the default authentication method. In all other instances, you must enable Digest authentication.

Requirements for Digest Authentication

You not need to install additional client software to use Digest authentication, but Digestauthentication relies on the HTTP 1.1 protocol, as defined in the RFC 2617 specification at the World Wide Web Consortium Web site, and not all browsers support that protocol. If a non–HTTP 1.1–compliant browser requests a file from a server that uses Digest authentication, the server requests that the client provide Digest authentication credentials. The non–HTTP 1.1– compliant browser rejects the request because the client cannot support Digest authentication.

You do need to meet the following minimum requirements before you enable Digest authentication on your IIS server:

• All of the clients that need access to a resource that is secured with Digest authentication are using Internet Explorer 5.x or Internet Explorer 6.
• The user and the server running IIS are members of, or are trusted by, the same domain.
• Users have a valid Windows user account that is stored in Active Directory on the domain controller, with reversible encryption enabled.
• The domain has a domain controller running the Microsoft Windows 2000 Server operating system or Windows Server 2003.
• The server running IIS is running Windows 2000 Server or Windows Server 2003.
• If the server operates in worker process isolation mode, the LocalSystem user account is used as the identity.
• The Iissuba.dll file is registered on the server running IIS.


Advanced Digest Authentication:

When Advanced Digest authentication is enabled, user credentials are stored on the domain controller as an MD5 hash. Advanced Digest authentication does not require that credentials are stored using reversible encryption. Instead, Advanced Digest authentication stores a few precalculated hashes in Active Directory, so user passwords cannot feasibly be discovered by
anyone with access to the domain controller, including the domain administrator.

When you perform a clean installation of IIS 6.0, Advanced Digest authentication is enabled as the default authentication method, and it is recommended over Digest authentication because passwords are not stored in plaintext on the domain controller.

Requirements for Advanced Digest Authentication
As with Digest authentication, you do not need to install additional client software to use Advanced Digest authentication. Because Advanced Digest authentication relies on the HTTP 1.1 protocol as defined in the RFC 2617 specification at the World Wide Web Consortium Website, your browsers should be HTTP 1.1 compliant.

Advanced Digest authentication, like Digest authentication, will not work unless the following minimum requirements are met:
• All of the clients that need access to a resource that is secured with Advanced Digest authentication are using Internet Explorer 5 or Internet Explorer 6.
• The user and the server running IIS are members of the same domain, or the user is a member of a trusted domain.
• Users have a valid Windows user account that is stored in Active Directory on the domain controller.
• The domain controller and the server running IIS are both running Windows Server 2003. If either your domain controller or the server running IIS is running Windows 2000 Server or earlier, IIS defaults to Digest authentication and does not notify you of this action.

Advanced Digest authentication uses the UseDigestSSP property to switch between Digest and Advanced Digest security support provider interface (SSPI) code. If this property is set to false, Digest authentication is used. In all other cases (true, empty, or not set), IIS uses Advanced Digest authentication.

Note
Only domain administrators can verify that the domain controller requirements are met. Check with your domain administrator if you are unsure about whether your domain controller meets these requirements.

Important

If you use Digest authentication and select worker process isolation mode, you must use the LocalSystem user account as the application pool identity.

Integrated Windows Authentication

With Integrated Windows authentication (formerly called NTLM, and also known as Windows NT Challenge/Response authentication), the user name and password (credentials) are hashed before they are sent across the network. When you enable Integrated Windows authentication, the client browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.

In Windows Server 2003, Integrated Windows authentication is the default authentication method.

Integrated Windows authentication uses Kerberos v5 authentication and NTLM authentication. Kerberos is an industry-standard authentication protocol that is used to verify user or host identity. If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.

Integrated Windows authentication includes the Negotiate wrapper, which supports Kerberos v5 and NTLM. Negotiate allows the client application to select the best security support provider for the situation. Kerberos v5 and NTLM have the following restrictions:

• NTLM can get past a firewall, but it is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.
• Kerberos v5 requires that the client has a direct connection to Active Directory, which is generally not the case in Internet scenarios.
• Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.
• Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names.

Integrated Windows authentication has the following limitations:

• Integrated Windows authentication is supported by only Internet Explorer 2 and later.
• Integrated Windows authentication does not work over HTTP proxy connections.

Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every user has Internet Explorer 2 or later.


.NET Passport Authentication

Microsoft .NET Passport is a user-authentication service and a component of the Microsoft .NET Framework. The .NET Passport single sign-in service and express purchase service enable organizations to deliver a fast and convenient way for consumers to sign in and make transactions on a Web site. With the .NET Passport single sign-in service, you can map sign-in names to information in your databases, which enables you to offer .NET Passport members a
personal Web experience through targeted content, advertisements, and promotions. The .NET Passport single sign-in service is similar to the forms-based authentication model that is commonly used on the Web today. The .NET Passport network extends this model to work across a distributed set of participating sites while helping to preserve the privacy and security of
its members. In addition, organizations can customize and brand the sign-in experience.

Microsoft .NET Passport uses standard Web technologies, such as SSL, HTTP redirects, cookies, Microsoft JScript development software, and strong symmetric key encryption to deliver the single sign-in service. In addition, .NET Passport is compatible with Internet Explorer 4 and later, Netscape Navigator version 4.0 and later, and some versions of UNIX.
.NET Passport–enabled sites rely on the .NET Passport central server to authenticate users. However, the .NET Passport central server does not authorize or deny the access of a user to individual .NET Passport–enabled sites. It is the responsibility of the Web site to control user access rights.

After .NET Passport authentication is verified, a Windows Server 2003 Passport user can be mapped to a user of Active Directory through the user’s Windows Server 2003 Passport identification, if such a mapping exists. A token is created by the Local Security Authority (LSA) for the user, and is set by IIS for the HTTP request. Application developers and Web site administrators can use this security model for authorization based on users of Active Directory.
You can also delegate these credentials through the constrained delegation feature supported by Windows Server 2003.

Users can register at a .NET Passport–enabled site, and their user information is then stored in encrypted profiles on .NET Passport servers. When .NET Passport users register at a participating site, their personal information can be shared with the site to speed up the registration process. When the .NET Passport users sign in to that site again, their .NET Passport profiles can enable access to personalized accounts or services on that site.

For more information about .NET Passport authorization, see the Microsoft .NET Passport link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.