The Wayback Machine - https://web.archive.org/web/20121128123232/http://msdn.microsoft.com:80/en-us/library/aa292114(VS.71).aspx
HomeLibraryLearnDownloadsSupportCommunity
Sign in |United States - English ||
40 out of 56 rated this helpful - Rate this topic

IIS Authentication

Visual Studio .NET 2003

An important part of many distributed applications is the ability to identify someone, known as a principal or client, and to control the client's access to resources. Authentication is the act of validating a client's identity. Generally, clients must present some form of evidence, known as credentials, proving who they are for authentication. Typically, credentials include a username/password pair. Both Internet Information Services (IIS) and ASP.NET provide several authentication schemes. For more information, see ASP.NET Architecture.

IIS provides a variety of authentication schemes:

  • Anonymous (enabled by default)
  • Basic
  • Digest
  • Integrated Windows authentication (enabled by default)
  • Client Certificate Mapping

Regardless of which method you choose, after IIS authenticates the client it will pass a security token to ASP.NET. If you configure ASP.NET authentication to use Windows authentication and you enable impersonation, ASP.NET will impersonate the user represented by this security token. For more information, see ASP.NET Impersonation.

Anonymous

Anonymous authentication gives users access to the public areas of your Web site without prompting them for a user name or password. Although listed as an authentication scheme, it is not technically performing any client authentication because the client is not required to supply any credentials. Instead, IIS provides stored credentials to Windows using a special user account, IUSR_machinename. By default, IIS controls the password for this account. Whether or not IIS controls the password affects the permissions the anonymous user has. When IIS controls the password, a subauthentication DLL (iissuba.dll) authenticates the user using a network logon. The function of this DLL is to validate the password supplied by IIS and to inform Windows that the password is valid, thereby authenticating the client. However, it does not actually provide a password to Windows. When IIS does not control the password, IIS calls the LogonUser() API in Windows and provides the account name, password and domain name to log on the user using a local logon. After the logon, IIS caches the security token and impersonates the account. A local logon makes it possible for the anonymous user to access network resources, whereas a network logon does not. For more information, see About Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiabasc.htm).

When you enable Anonymous authentication, IIS does not use any other authentication schemes unless NTFS permissions deny access to a resource.

Pros

  • Offers the best performance because Anonymous authentication imposes no appreciable overhead.
  • Does not require management of individual user accounts.
  • If IIS does not control the password, can access network resources.

Cons

  • Does not authenticate clients on an individual basis.
  • If IIS does not control the password, account must have local logon ability.

Implementation

By default, IIS enables anonymous authentication and uses the IUSR_machinename user account with the password controlled by IIS. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76).

Configure ASP.NET using the Web.config file to specify no authentication, or Windows authentication. For more information, see ASP.NET Authentication.

Copy
 <!-- Web.config file --> <system.web> <authentication mode="Windows" /> </system.web>

Basic

IIS implements Basic authentication, which is part of the HTTP 1.0 specification, using Windows user accounts. When using Basic authentication, the browser prompts the user for a user name and password. This information is then transmitted across HTTP where it is encoded using Base64 encoding. Although most Web servers, proxy servers, and Web browsers support Basic authentication, it is inherently insecure. Because it is easy to decode Base64 encoded data, Basic authentication is essentially sending the password as plain text. For more information, see About Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiabasc.htm).

The IIS metabase contains a LogonMethod property to specify the logon method for clear-text logons such as Basic authentication. By default, Basic authentication requires the Windows user account to have local logon rights at the Web server. If you use the default setting, IIS caches credentials during logon, which slows the logon process. By specifying either network logon or network with cleartext logon, IIS does not cache credentials at logon, which expedites the logon process. A local logon makes it possible for the user to access network resources, whereas a network logon does not. However, a network with cleartext logon makes it possible for the user to access network resources. For more information, see LogonMethod in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/asp/apro1zms.htm).

To improve the security of this authentication scheme, you can use it in combination with Secure Sockets Layer/Transport Layer Security (SSL/TLS) support to encrypt the HTTP session. However, SSL/TLS impacts performance because it encrypts and decrypts all data on each exchange. TLS is the Internet Engineering Task Force (IETF) version of Netscape's SSL, sometimes referred to as SSL 3.1. For more information, see the specification (RFC 2246) on the Internet Engineering Task Force (IETF) Web site (http://www.ietf.org/rfc/rfc2246.txt).

When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 and later that are trusted for delegation. Delegation enables remote access of resources on behalf of the delegated user.

Pros

  • Because it is part of the HTTP 1.0 specification, Basic is the most widely supported user authentication scheme.
  • Can authenticate through a proxy server.
  • Makes it possible to track individual users.
  • Can access network resources, if user account has local logon rights on the Web server.
  • Can be used in conjunction with Kerberos, enabling delegation of security credentials.

Cons

  • Is inherently insecure unless using SSL/TLS, which impacts performance.
  • Requires the creation of individual Windows accounts for each user.

Implementation

To implement Basic authentication, configure it within IIS and make sure that your users have "log on locally" permissions on the Web server. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76).

If you implement Basic authentication, you should also use SSL/TLS. For more information, see Setting up SSL on Your Server in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iisslsc.htm) and Knowledge Base article Q298805, HOW TO: Enable SSL for All Customers Who Interact with Your Web Site (http://support.microsoft.com/support/kb/articles/Q298/8/05.asp).

If your ASP.NET application needs to run as the user authenticated by Basic authentication, use the following Web.config file configuration. For more information, see Using IIS Authentication With ASP.NET Impersonation.

Copy
 <!-- Web.config file --> <system.web> <authentication mode="Windows" /> </system.web>

Digest

Digest authentication addresses the primary weaknesses of basic authentication: sending passwords in plain text. Digest authentication is a challenge/response mechanism, which sends a digest (also known as a hash) instead of a password over the network. A digest is a fixed-size result obtained by applying a mathematical function (called a hash function or digest algorithm) to an arbitrary amount of data. The fixed-size depends upon the level of encryption. For example, if a 128-bit digest consisted of 32 ASCII characters, a 40-bit digest would consist of 10 ASCII characters. When a client attempts to access a resource requiring Digest authentication, IIS send a challenge to the client to create a digest and send it to the server. The client concatenates the password with data known to both the server and the client. The client then applies a digest algorithm (specified by the server) to the combined data. The client sends the resulting digest to the server as the response to the challenge. The server uses the same process as the client to create a digest using a copy of the client's password it obtains from Active Directory, where the password is stored using reversible encryption. If the digest created by the server matches the digest created by the client, IIS authenticates the client. IIS uses a subauthentication DLL (iissuba.dll) to authenticate the user, resulting in a network logon. By itself, Digest authentication is only a slight improvement over Basic authentication. In the absence of SSL/TLS, an attacker could record communication between the client and server. Using this information, the attacker can then use that information to replay the transaction. For more information, see About Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiabasc.htm).

Pros

  • Sends a digest over the network instead of a password.
  • Works with proxy servers and firewalls.
  • Does not require SSL/TLS for the sake of password protection.

Cons

  • Cannot delegate security credentials.
  • Is only supported by Internet Explorer 5.0 and later.
  • Is subject to replay attacks unless you use SSL/TLS.
  • Requires storing of passwords in cleartext using reversible encryption.
  • Requires the creation of domain accounts for each user in Active Directory.

Implementation

To use Digest authentication in Windows 2000, the server must have access to an Active Directory server that is set up for Digest authentication. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76) and Knowledge Base article Q222028, Setting Up Digest Authentication for Use with Internet Information Services 5.0 (http://support.microsoft.com/support/kb/articles/Q222/0/28.asp).

Note   After configuring Active Directory to store passwords using reversible encryption, all users must change their passwords for Active Directory to store each password in this manner.

If you implement Digest authentication, you should also use SSL/TLS to defend against replay attacks. For more information, see Setting up SSL on Your Server in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iisslsc.htm) and Knowledge Base article Q298805, HOW TO: Enable SSL for All Customers Who Interact with Your Web Site (http://support.microsoft.com/support/kb/articles/Q298/8/05.asp).

If your ASP.NET application needs to run as the user authenticated by IIS Digest authentication, use the following Web.config configuration. For more information, see ASP.NET Authentication.

Copy
 <!-- Web.config file --> <system.web> <authentication mode="Windows" /> </system.web>

For more information about digest authentication, see the specification (RFC 2069) on the Internet Engineering Task Force (IETF) Web site (http://www.ietf.org/rfc/rfc2069.txt).

Integrated Windows Authentication

Integrated Windows authentication (formerly known as NTLM authentication and Windows NT Challenge/Response authentication) can use either NTLM or Kerberos V5 authentication and only works with Internet Explorer 2.0 and later.

When Internet Explorer attempts to access a protected resource, IIS sends two WWW-Authenticate headers, Negotiate and NTLM.

  • If Internet Explorer recognizes the Negotiate header, it will choose it because it is listed first. When using Negotiate, the browser will return information for both NTLM and Kerberos. At the server, IIS will use Kerberos if both the client (Internet Explorer 5.0 and later) and server (IIS 5.0 and later) are running Windows 2000 and later, and both are members of the same domain or trusted domains. Otherwise, the server will default to using NTLM.
  • If Internet Explorer does not understand Negotiate, it will use NTLM.

So, which mechanism is used depends upon a negotiation between Internet Explorer and IIS.

When used in conjunction with Kerberos v5 authentication, IIS can delegate security credentials among computers running Windows 2000 and later that are trusted and configured for delegation. Delegation enables remote access of resources on behalf of the delegated user.

Integrated Windows authentication is the best authentication scheme in an intranet environment where users have Windows domain accounts, especially when using Kerberos. Integrated Windows authentication, like digest authentication, does not pass the user's password across the network. Instead, a hashed value is exchanged. For more information, see the IIS documentation (http://www.microsoft.com/windows2000/en/server/iis/).

Pros

  • Can be used in conjunction with Kerberos, enabling delegation of security credentials.
  • The best scheme for intranet environments using Windows.

Cons

  • Cannot authenticate through a firewall via a proxy, unless used over a PPTP connection.
  • Does not support delegation to other servers, if NTLM is chosen.
  • Is only supported by Internet Explorer 2.0 and later.
  • Kerberos is only supported by IIS 5.0 and later.

Implementation

To implement Kerberos or NTLM, configure IIS to use Integrated Windows authentication. If you need to support clients other than those running Internet Explorer, you may want to enable Basic authentication in conjunction with NTLM or Kerberos. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76).

To use Kerberos, you need to consider these specific details:

  • You must run the client and server computers on Windows 2000 or later, and they must be in a Windows 2000 or later domain.
  • You must enable the client's user account for delegation.
  • You must enable the service's account for delegation.
  • You must enable participating computers for delegation.

If your ASP.NET application needs to run as the user authenticated by IIS using integrated Windows authentication, use the following Web.config configuration. For more information, see ASP.NET Authentication.

Copy
 <!-- Web.config file --> <system.web> <authentication mode="Windows" /> </system.web>

Client Certificate Mapping

A certificate is a digitally signed statement that contains information about an entity and the entity's public key, thus binding these two pieces of information together. A trusted organization (or entity) called a Certification Authority (CA) issues a certificate after the CA verifies that the entity is who it says it is. Certificates can contain different types of data. For example, an X.509 certificate includes the format of the certificate, the serial number of the certificate, the algorithm used to sign the certificate, the name of the CA that issued the certificate, the name and public key of the entity requesting the certificate, and the CA's signature. X.509 client certificates simplify authentication for larger user bases because they do not rely on a centralized account database. You can verify a certificate simply by examining the certificate. For more information, see Microsoft Windows 2000 Public Key Infrastructure.

Operating systems such as Windows still require the notion of a user account. Certificate mapping makes it possible for administrators to associate a single certificate (one-to-one mapping), or multiple certificates (many-to-one), to a user account. Many-to-one mapping uses rules to define certificate criteria for mapping. For more information, see Mapping Client Certificates to User Accounts in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iimapsc.htm).

IIS uses SSL/TLS to authenticate a server and provide an encrypted HTTP session. IIS can also use SSL/TLS to authenticate the client by requiring the client to provide a certificate. When requesting a client certificate, the server provides the client with a list of CAs that the server trusts. This list is derived from the server's Certificate Trust List (CTL). If the client possesses a certificate issued by a CA from the CTL, it sends a copy of that certificate to the server for verification. If the certificate is valid, IIS authenticates the user that maps to the provided certificate. As such, you should limit the CTL on IIS to those CAs you determine to be truly trustworthy. For more information, see the IIS documentation (http://www.microsoft.com/windows2000/en/server/iis/).

Pros

  • Includes strong authentication scheme.
  • Provides two-way authentication of server and client.
  • Can access network resources.

Cons

  • Cannot delegate security credentials.
  • Does not work with all browsers.
  • Requires SSL/TLS.
  • Is cumbersome to configure; however, many-to-one can be easier than one-to-one.

Implementation

You must configure IIS for certificate authentication. For more information, see Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76).

You will need Active Directory to set up one-to-one mappings for the certificates it issues. For more information, see the "Step-by-Step Guide to Mapping Certificates to User Accounts" on the Windows 2000 Web site (http://www.microsoft.com/windows2000/techinfo/planning/security/mappingcerts.asp).

If your ASP.NET application needs to run as the user authenticated by IIS using certificate authentication, use the following Web.config configuration. For more information, see ASP.NET Authentication.

Copy
 <!-- Web.config file --> <system.web> <authentication mode="Windows" /> </system.web>

See Also

Security Model | Using IIS Authentication With ASP.NET Impersonation | Enabling and Configuring Authentication in the IIS Documentation (http://www.microsoft.com/windows2000/en/server/iis/htm/core/iiauths.htm?id=76)

close