Authentication

Authentication is the process of verifying that a user has the right to access a system with the claimed user identity, by confirming that the user possesses a secret assigned only to that identity. The most common authentication methods involve comparing the user name and password supplied by the user with those stored for that user in some centralized location. Certificate-based authentication relies on computations that involve a private key stored on the user’s computer. The identity contained in the certificate may be further mapped to an identity maintained in the security database for the site. In either case, once the user proves to have possession of the secret, authentication succeeds and the site accepts the user’s identity claim when making all subsequent access control decisions during that session.

Credentials for all users of a given application server (such as a Web site) must be stored in a single location. Two location options are supported:

Membership Directory

Windows NT Server directory database

When credentials are stored in the Membership Directory, the configuration is referred to as Membership Authentication mode. When credentials are stored in the Windows NT Server directory database, the configuration is referred to as Windows NT Authentication mode. In either case, user profile data is stored in the Membership Directory.

Your choice of authentication mode is a very important one, as it will affect many aspects of configuration and site development.

Windows NT Authentication is recommended for intranet sites, for a number of reasons:

You can leverage the infrastructure of security accounts, security groups, and access permissions that may already exist in your Windows NT Server directory database.

User communities up to approximately 50 thousand users can be supported under Windows NT Server version 4.0.

Membership Authentication has certain advantages for Internet sites, particularly those with very large user communities:

Communities numbering into the millions can be supported with high performance, without requiring an investment in large numbers of domain controllers.

The Authentication Service, working with the information stored in the Membership Directory, can immediately retrieve all of a user’s personalization attributes at the same time it retrieves credentials to validate the logon.

Online user registration and data maintenance are supported with the customizable sample pages and Design-time controls (DTCs) included with P&M.

Membership Authentication offers certain authentication methods that are not available with Windows NT Authentication.

Important

When you create a Membership Directory, you specify either Membership Authentication or Windows NT Authentication for that Membership Directory. Once a Membership Directory is created, the authentication mode for that Membership Directory cannot be changed.

Using Mixed Authentication Modes

A Web site can only be mapped to one Membership Server, and a Membership Server can only be associated with one Membership Directory. Thus, a given Web site can only be operated in Windows NT Authentication mode or in Membership Authentication mode. If security accounts for your personnel (such as system administrators, Web authors, and editors) already exist in a Windows NT Server directory database, you may find it desirable to manage them under Windows NT Authentication, while using Membership Authentication to manage security accounts for the external users of your Web site.

To accomplish this, you must set up two separate Membership Directories, one for internal users and one for external users. Each Membership Directory is associated with its own Web site and Membership Server, but they can both have access to the same Web pages and reside on the same computer. Microsoft® Internet Information Server (IIS) virtual directories for the two Web sites can be mapped to the same physical location in your file system. Under this arrangement, the different Web sites will have different URLs for the same Web pages. The internal and external users can have different access permissions to the files, and can be required to authenticate with different methods, using the accounts in their respective credential stores. Internal users would authenticate using accounts in the Windows NT Server directory database, and external users would authenticate using accounts in the Membership Directory that was created for external users.

Identification and Authentication Methods

The two authentication modes support a variety of identification and authentication methods which can be used alone, in combination, or in combination with IIS Anonymous access. Your choice of methods depends on the sensitivity and value of the data you want to protect, the client software you want to support, and the threats expected. There is a trade-off between security and performance, with the less secure methods generally being faster or easier to administer.

You can set different methods on different virtual directories or on individual files. Subdirectories inherit the method or methods of their parent directory unless this is overridden by a setting on the subdirectory. Files inherit the method of the directory unless this is overridden by file-level settings.

In Windows NT Authentication mode, you can apply any of the following identification and authentication methods (which are provided by Windows NT Server) to your application content. In this mode, you can also protect the Membership Directory itself using either Clear Text/Basic Authentication or Windows NT Challenge/Response Authentication.

Identification and Authentication Methods Available in Windows NT Authentication Mode	Description
Anonymous	An IIS method that allows public access to content without any authentication or authorization.


Clear Text/Basic Authentication	A registered user’s identity is validated by password.
User Experience	A separate logon is required for each application.
User Interface	Browser presents a logon dialog box that is not customizable. An authentication failure takes the user to a page that points to the Troubleshooting Pages.
Level of Security	Low if used without SSL; medium with SSL using 40-bit encryption; high with SSL using 128-bit encryption. Password is sent in clear text; under HTTP, this occurs with each HTTP request. Session can be encrypted with SSL on all pages to protect the password, although at a cost in reduced performance. Evaluate the speed/security tradeoff according to your needs and priorities.
Client Support	Widely supported by browsers and other types of client software such as Mail, News, and Chat from many vendors.
Recommended Uses	Use with SSL for sites requiring medium to high security and the broadest client support.


Windows NT Challenge/Response Authentication (also known as NTLM Authentication)	A registered user’s identity is validated by password. Credentials are protected in transmission by hashing and challenge/response protocol. Standard method used by Windows NT networking. This is the default authentication method in Windows NT Authentication mode.
User Experience	Single logon is typical for multiple Microsoft applications in an intranet environment, where the applications are generally in a single domain or set of trusted domains; separate logon is typically required for each application in an Internet environment, where applications at different sites are generally in different Windows NT domains.
User Interface	Windows NT Challenge/Response Authentication presents a Windows-based logon dialog box that cannot be branded.
Level of Security	High.
Client Support	Microsoft applications such as Microsoft® Internet Explorer, Mail, News, Chat, and Windows Address Book.
Recommended Uses	Good for intranets. Not designed to be used across HTTP proxies. Use for sites requiring medium security and single logon across multiple Microsoft applications.


Client Certificate Authentication	Works with certificates provided by Microsoft® Certificate Server or third-party sources. Requires an SSL channel. A registered user’s identity is validated by computations involving a public key stored in the user’s digital certificate and a private key stored on the user’s computer. The private key can be further protected by storage in a SmartCard. In Windows NT Authentication mode, the user identity from the certificate can be automatically mapped (by manually creating a table in IIS) to one of a group of native Windows NT user accounts that you create for the purpose. Because each mapping is created manually, it is generally not practical to map individual certificates to individual accounts. Rather, certificates can be mapped on the basis of common attribute information contained in the certificate, such as the name of the certificate issuer (for example, all users with certificates from a particular issuer could be mapped to a generic account that would represent that set of users). This process supports a limited form of personalization and allows the use of Windows NT permissions to protect content with respect to sets of users. Personalization and access control under this arrangement cannot be set to differ by specific user, but only at the level of the generic sets of users. When mapping is in effect, attributes of the mapped generic account are available through the AUO, just as for other authentication methods in Windows NT Authentication mode. If account mapping is not in effect, you can use Cookie Identification for personalization.
User Experience	Single logon for all enabled applications on the client computer. Same certificate can be used for multiple sites.
User Interface	Once the user has obtained a certificate, no user interaction is required at logon time. The browser, however, may present a dialog box in the case of various errors or exceptions such as encountering an expired server certificate, or to allow the user to choose which certificate to use for a particular logon.
Level of Security	Very high. No shared secret information. Currently the most robust form of client authentication as long as physical access to the private key (and the computer where it is stored) is restricted to the user who owns the key. However, there is currently no industry-wide accepted methodology for publishing and updating certificate revocation lists.
Client Support	Microsoft® Internet Explorer versions 3.02 and later. Netscape Navigator versions 3.0 and 4.0. Other compatible Web browser software.
Recommended Uses	Use for sites requiring maximum security and broad client support.


Cookie Identification	User is identified by a globally unique identifier (GUID) stored in a cookie associated with the browser. Cookie Identification is not an authentication method. It is a Membership feature for identifying and tracking users. Cookie Identification can be used to support personalization in conjunction with any of the authentication methods previously described. For information on configuring the AUO to use cookies, see Active User Object. The GUID can be used to track the user with Site Server Analysis. However, a user who connects to the same site with different computers will receive separate cookies with different GUIDs, and thus different accounts. In addition, because the cookie is associated with the browser, this method does not distinguish between different users of the same computer.
User Experience	None, unless the browser rejects cookies.
User Interface	None.
Level of Security	No effect on security; no authentication is performed by Cookie Identification. Security is controlled by the authentication method in force for the requested content or data.
Client Support	All Web browsers (HTTP and HTTPS only) that have not disabled cookies.
Recommended Uses	Web areas requiring personalization.

In Membership Authentication mode, you can apply any of the following methods to your application content. In this mode, you can also protect the Membership Directory itself using either Clear Text/Basic Authentication or Distributed Password Authentication (DPA).

Identification and Authentication Methods Available in Membership Authentication Mode	Description
Anonymous	An IIS method that allows public access to content without any authentication or authorization.


Clear Text/Basic Authentication	Registered user’s identity is validated by password. This is the default authentication method in Membership Authentication mode. Behavior of this method is identical to that of Clear Text/Basic Authentication in Windows NT Authentication mode, except that the user is authenticated against accounts in the Membership Directory rather than in the Windows NT Server directory database.
User Experience	A separate logon is required for each application.
User Interface	Browser presents a logon dialog box that is not customizable. An authentication failure takes the user to a page that points to the Troubleshooting Pages.
Level of Security	Low if used without SSL; medium with SSL using 40-bit encryption; high with SSL using 128-bit encryption. Password is sent in clear text; under HTTP, this occurs with each HTTP request. Session can be encrypted with SSL on all pages to protect the password, although at a cost in reduced performance. Evaluate the speed/security tradeoff according to your needs and priorities. (SSL is not enabled by default.)
Client Support	Widely supported by browsers and other types of client software from many vendors.
Recommended Uses	Use with SSL for sites requiring medium to high security and the broadest client support.


HTML Forms Authentication	Registered user’s identity is validated by password. Password is requested on initial connection; validation for each subsequent request in the session is based on a session cookie containing hashed credentials. The cookie expires after a configurable period of inactivity, after which the user is asked to log on again.
User Experience	User is prompted to enter user name and password upon access to the first protected page. Subsequent access requests are automatically and transparently authenticated by means of the cookie. The cookie can be issued at the domain level to support transparent multi-application logon across Web subdomains. For example, if a user logs on at application x.DomainName.com, and the cookie is issued for the DomainName.com domain, the user will be able to use application y.DomainName.com without logging-in a second time. Access controls are still enforced for each subdomain.
User Interface	The user name and password are requested by a logon page, FormsLogin.asp, which can be branded and completely customized. An authentication failure returns the user to the logon page. Different logon pages can be provided for different content subdirectories.
Level of Security	Medium if used without SSL; medium+ with SSL using 40-bit cryptography; high with SSL using 128-bit cryptography. Initial password is submitted in clear text by default, but can be protected with SSL on logon page. The performance penalty in doing this for password protection is less than with Clear Text/Basic Authentication, because with HTML Forms Authentication only the logon page would use SSL. HTML Forms Authentication uses a cookie that contains a hash of the password, and is therefore vulnerable to replay attack unless all pages use SSL.
Client Support	All Web browsers (HTTP and HTTPS only) that have not disabled cookies.
Recommended Uses	Use for Web sites requiring medium to high security and the broadest client support.


Distributed Password Authentication (DPA)	Registered user’s identity is validated by password. Credentials are protected in transmission by hashing and challenge/response protocol. Derived from Windows NT Challenge/Response Authentication, but optimized for distributed application systems sharing a common security data store.
User Experience	The DPA client provides for short-term and long-term caching of credentials to provide multi-application single logon across Application servers and domains within a realm. The cached credentials are used first, and the user is prompted to enter new credentials only if they fail. Multiple communities are supported by caching credentials per realm. A realm represents the members in a Membership Directory, and is identified with the o=DirectoryName value from the Membership Directory root.
User Interface	DPA presents a Windows-based logon dialog box that can be branded using the Site Server SDK.
Level of Security	High. Passwords are never transmitted during authentication. A session cookie allows operation across HTTP proxies; this introduces a vulnerability to replay attack, and can be disabled.
Client Support	Microsoft® Internet Explorer versions 3.02 and later for the PC and versions 3.0 and later for the Macintosh.
Recommended Uses	Because of limited client support, DPA is recommended for backward compatibility with MCIS 1.0. Use for sites requiring high security and single logon across multiple applications (such as Mail, News, and Web) per realm.


Client Certificate Authentication	Works with certificates provided by Microsoft Certificate Server or third-party sources. Requires an SSL channel. A registered user’s identity is validated by computations involving a public key stored in the user’s digital certificate and a private key stored on the user’s computer. The private key can be further protected by storage in a SmartCard. The user identity from the certificate can be automatically mapped to an account in the Membership Directory. This is done in almost all cases, to support personalization and to allow the use of Membership group permissions to protect content. When mapping is in effect, user attributes are available through the Authentication Service, just as for other authentication methods in Membership Authentication mode.
User Experience	Single logon for all enabled applications on the client computer. Same certificate can be used for multiple sites, eliminating the need for users to remember a user name and password specific to your site.
User Interface	Once the user has obtained a certificate, no user interaction is required at logon time. The browser, however, may present a dialog box in the case of various errors or exceptions such as encountering an expired server certificate, or to allow the user to choose which certificate to use for a particular logon.
Level of Security	Very high. No shared secret information. Currently the most robust form of client authentication as long as physical access to the private key (and the computer where it is stored) is restricted to the user who owns the key. However, there is currently no industry-wide accepted methodology for publishing and updating certificate revocation lists.
Client Support	Microsoft® Internet Explorer versions 3.02 and later. Netscape Navigator versions 3.0 and 4.0. Other compatible Web browser software.
Recommended Uses	Use for sites requiring maximum security and broad client support.


Automatic Cookie Authentication	User is transparently logged on based on the GUID stored in the Site Server cookie associated with the browser. The real identity of users under Automatic Cookie Authentication remains anonymous; they are tracked with accounts in the ou=Anonymous container of the Membership Directory in accounts identified by GUID. The user account in the Membership Directory for an unregistered user is identified with a GUID, and the user account for a registered user is identified with a user name. AUOs under Membership Authentication always get the user ID from the REMOTE_USER variable, and the attribute information collected under both types of authentication is coordinated and stored in a single user record. When a user with an unregistered account registers, the account identifier changes from a GUID to a user name, and any attribute information is preserved. The GUID can be used to track the user with Site Server Analysis. However, a user who connects to the same site with different computers will receive separate cookies with different GUIDs, and thus different accounts.
User Experience	No explicit logon is required.
User Interface	None, unless the browser rejects cookies.
Level of Security	No security; authentication is performed based solely on presentation of the cookie containing the GUID, which identifies the user account. An automatic logon occurs regardless of the setting of IIS Anonymous access, even if there are no permission restrictions in effect for the requested file. Automatic Cookie Authentication creates a full security context with all of a user’s permissions. If a user registers and gets an account with full logon credentials, the GUID remains associated with the account. In any future logons by Automatic Cookie Authentication, the same security context is created as if the user had logged on with a password.
Client Support	All Web browsers (HTTP and HTTPS only) that have not disabled cookies.
Recommended Uses	A lightweight, automatic method suitable for public or restricted Web areas supporting personalization that do not contain sensitive information. Good for personalized home pages. Can require users to register or fill out questionnaire to access restricted areas. GUID accounts can be given group membership by questionnaires and other scripts. Caution Do not use this method to protect sensitive content or scripts that access sensitive user data, because a cookie-authenticated user can be impersonated simply by obtaining his or her cookie. An area configured with Automatic Cookie Authentication looks like a public area, but behaves like a fully authenticated area if the current user has a password account with privileges.

Combining Authentication Methods

Some authentication methods can be used in combination with each other. Clear Text/Basic Authentication can be configured with DPA or Windows NT Challenge/Response Authentication on the same virtual directory or file, which allows support for both Internet Explorer and Netscape Navigator browsers. In this situation, the system tries the more secure authentication method (DPA or Windows NT Challenge/Response) first. In most cases, if the client software does not support that method, the system will use Clear Text/Basic. If the more secure method is supported by the client and the logon fails, Clear Text/Basic will not be invoked. Automatic Cookie Authentication and HTML Forms Authentication cannot be used with each other or with any other authentication method for the same virtual directory or file.

You can also use Client Certificate Authentication together with other authentication methods. In most cases, if the user does not present a valid certificate, or presents a certificate that is not mapped to a user account in the Membership Directory, the system will then use the secondary authentication method. This is useful in cases where you would like to offer the convenience of certificate-based authentication to users who have certificates, but would also like to support password-based authentication for other users.

Authentication Methods for the Membership Directory

The authentication method that applies to connections to a Membership Directory is set at the LDAP Service level. This means that you can use different authentication methods for the same Membership Directory when it is accessed by different LDAP Services.

In Membership Authentication mode, Clear Text/Basic Authentication is required by the P&M Authentication Service, MDM, Site Server Message Builder Service, and Membership DTCs. In Windows NT Authentication mode, these features require Windows NT Challenge/Response Authentication. You must configure the indicated authentication method for all LDAP Services that are used by any of these features. If you are using Clear Text/Basic Authentication, it is recommended that you add SSL encryption to protect passwords in transmission.

If you will be supporting Address Book or Internet Locator Service functionality, you will have an LDAP Service accessible to the public, often over the Internet. If you want to protect passwords transmitted during logons, but don’t want the overhead of SSL encryption, you can configure the LDAP Service to use Windows NT Challenge/Response Authentication (Windows NT Authentication mode, if operating on a LAN) or DPA (Membership Authentication mode, if operating over the Internet), provided that users have the client software to support it. Alternatively, you can use Clear Text/Basic Authentication with SSL for encryption, or without SSL for higher performance but less security.

If you configure Windows NT Challenge/Response Authentication or DPA, you can also configure Clear Text/Basic Authentication with or without SSL. In that case, browsers that do not support Windows NT Challenge/Response Authentication or DPA will be able to log on with Clear Text/Basic Authentication.

Anonymous Access

You can use the IIS Allow Anonymous setting to permit access to Web content without requiring a user to log on explicitly. Similarly, you can configure LDAP Services to permit access to information in the Membership Directory without requiring a user to log on explicitly. However, even if IIS Anonymous access is configured, an explicit logon may be triggered depending on the configuration of other authentication methods or access controls on the requested resource (see Authentication and Anonymous Logons).

With an anonymous logon, no user name or password is required. Anonymous logons use different standard user accounts depending on the situation, as discussed in Anonymous Accounts.

Any point of public access such as a registration page or questionnaire page must have Allow Anonymous set.

Handling Failed Logons

If a user is asked to provide credentials, and the credentials are rejected or the user cancels the logon, the subsequent system behavior varies depending on which authentication method is in use.

With DPA and Clear Text/Basic Authentication, the system sends an access-denied message to the client. The client browser may allow the user a limited number of additional chances to provide acceptable credentials.

With a Web server, at the final failure or when the user cancels the sign-in dialog, a page is displayed with a brief message and a link to the Troubleshooting Pages. The Troubleshooting Pages provide a series of yes and no questions, which help the user determine why the authentication failed. Sometimes logons fail due to expired accounts or forgotten passwords, or the user may need to register to access the requested content. The Troubleshooting Pages can contain a link to a Registration page or questionnaire. Sample Troubleshooting Pages are included with the customizable Membership Sample Pages.

With Application servers other than Web servers, the behavior will depend on the specific Application server and protocol, and on the particular client software.

Under HTML Forms Authentication, a customizable logon page, FormsLogin.asp, is displayed repeatedly with each failure. It typically contains links to the Troubleshooting Pages and the Registration Page. You can have different logon pages for different URLs by putting different FormsLogin.asp files in various locations. The FormsLogin.asp file found in the virtual directory with the requested content is used if one exists. If no file is found there, Membership looks in successively higher levels up to the root of the URL until it finds one. If no FormsLogin.asp file is found, the default file stored in /_Mem_bin is used. For this process to work properly, users must have script execute permissions to the FormsLogin.asp file in the directory of its intended use.

Under Client Certificate Authentication, the behavior upon failure depends on the specific client software.

P&M provides protection against users who try to access protected areas by means of password-guessing attacks (see Restricting Logons to LDAP Servers and Restricting Logons to Application Servers).