About authentication methods

  • Article

Updated: February 1, 2011

Applies To: Forefront Threat Management Gateway (TMG)

This topic provides an overview of the authentication methods used by Forefront TMG. They include:

  • HTTP authentication

  • Forms-based authentication

  • Client certificate authentication

For a summary of scenarios in which each method is used, see Overview of authentication in Forefront TMG.

HTTP authentication

Forefront TMG supports the following types of HTTP authentication:

  • Basic authentication

  • Digest and WDigest authentication

  • Integrated Windows authentication

Basic authentication

Basic authentication is a widely-used method of collecting user name and password information. Basic authentication sends and receives user information as text characters that can be read. Although passwords and user names are encoded, no encryption is used with Basic authentication.

The following steps outline how a client is authenticated by using Basic authentication:

  1. The user is prompted to enter a Windows account user name and password.

  2. Forefront TMG receives the HTTP request with the credentials and validates the credentials against the specified authentication server (RADIUS or Active Directory Domain Services (AD DS), LDAP server for incoming requests only).

  3. For outbound Web proxy requests, Forefront TMG validates credentials and then evaluates access rules. For incoming requests, Forefront TMG uses the credentials to authenticate to the published Web server, according to the configured delegation method. The Web server must be configured to use the authentication scheme that matches the delegation method used by Forefront TMG. The plaintext password is Base64-encoded before it is sent over the network; however, this is not encryption, and if the password is intercepted over the network by a network sniffer, unauthorized users can decode and reuse the password.

The advantage of Basic authentication is that it is supported by almost all HTTP clients. The disadvantage is that Web browsers using Basic authentication transmit passwords in an unencrypted form. By monitoring communications on your network, an attacker or malicious user can intercept and decode these passwords by using publicly available tools. Therefore, Basic authentication is not recommended unless you are confident that the connection is secure, such as with a dedicated line or an SSL connection.

Digest and WDigest authentication

Digest authentication offers the same features as Basic authentication, but provides a more secure way of transmitting the authentication credentials.

Digest authentication relies on the HTTP 1.1 protocol as defined in RFC 2617 (https://go.microsoft.com/fwlink/?LinkId=160622). This is not supported by all browsers. If a non-HTTP 1.1 compliant browser requests a file when Digest authentication is enabled, the request is rejected. Digest authentication can be used only in Windows domains.

Digest authentication is successful only if the domain controller has a reversibly encrypted (plaintext) copy of the requesting user's password stored in AD DS. To allow passwords to be stored in plaintext, you must activate the Store password using the reversible encryption setting on the Account tab of the user in AD DS. Alternatively, you can set group policy to enable this capability. After configuring this setting, you must set a new password to activate this feature because the old password cannot be determined.

WDigest, a new form of Digest authentication, is used when Forefront TMG is installed in a Windows Server 2008 domain. WDigest does not require a reversibly encrypted copy of the user password to be stored in AD DS.

Digest and WDigest authentication work as follows:

  1. The client makes a request.

  2. Forefront TMG denies the request and prompts the client to enter a Windows account user name and password. Note that when you use WDigest, the user name and domain name are case-sensitive and must be written exactly as they appear in AD DS. In addition, WDigest requires a value in the resource part of the URL path. For example, the user request https://host.domain.tld fails because the URL resource is missing.

  3. Authentication credentials pass through a one-way process known as hashing. The result is an encrypted hash or message digest. Values are added to identify the user, the user's computer and domain. A time stamp is added to prevent a user from using a password after it has been revoked. This provides a clear advantage over Basic authentication, because it makes it more difficult for an unauthorized person to intercept or use the password.

Integrated Windows authentication

Integrated Windows authentication uses the NTLM, Kerberos, and Negotiate authentication mechanisms. These are more secure forms of authentication because the user name and password are hashed before being sent across the network. When you enable NTLM, Kerberos, or Negotiate authentication, the user's browser proves its knowledge of the password through a cryptographic exchange with your Forefront TMG server, involving hashing.

The following steps outline how a client is authenticated by Integrated Windows authentication:

  1. Depending on browser configuration, authentication may not initially prompt for a user name and password. If the authentication exchange initially fails to identify the user, the browser prompts the user for a Windows account user name and password, which it processes by using Integrated Windows authentication. The Web browser continues to prompt the user until the user either enters a valid user name and password, or closes the prompt dialog box. The user name must be entered in the following format: domain\username

  2. If the authentication exchange initially fails to identify the user, the browser prompts the user for a Windows account user name and password, which it processes by using Integrated Windows authentication.

  3. Forefront TMG continues to prompt the user until the user either enters a valid user name and password, or closes the prompt dialog box.

Note

  • Forefront TMG communicates with the AD DS server whenever NTLM authentication is required. For this reason, it is recommended that you create a protected network for AD DS and Forefront TMG to prevent users (both external and internal) from accessing the communication.

  • Because authentication for an external connection uses NTLM authentication, it is recommended that you use SSL encryption for the traffic between Forefront TMG and the client. NTLM authentication is per connection, and encryption prevents improper reuse of connections by legacy proxy devices on the Internet.

Forms-based authentication

Forms-based authentication in Forefront TMG can be used to authenticate incoming requests for published Web servers.

Three types of forms-based authentication are available:

  • Password form—The user enters a user name and password on the form. These are the type of credentials needed for AD DS, LDAP, and RADIUS credential validation.

  • Passcode form—The user enters a user name and passcode on the form. These are the type of credentials needed for SecurID and RADIUS one-time password validation.

  • Passcode/Password form—The user enters a user name and passcode and a user name and password. The user name and passcode are used for authentication to Forefront TMG by using SecurID or RADIUS one-time password authentication methods, and the user name and password are used for delegation.

Client certificate authentication

Client certificate authentication is not supported for authenticating outbound Web requests.

For incoming requests for published resources, requiring a client certificate can help increase the security of your published server. Users can obtain client certificates from a commercial certification authority (CA) or from an internal CA in your organization. A certificate may also be one that is embedded in a smart card, or a certificate that is used by a mobile device so that it can connect to Microsoft ActiveSync.

The certificate must be matched to a user account. When users make a request for published resources, the client certificate sent to Forefront TMG is passed to a domain controller, which determines the mapping between certificates and accounts. Forefront TMG must be a domain member. The information is passed back to Forefront TMG for application of relevant firewall policy rules. Note that Forefront TMG cannot pass client certificates to an internal Web server.

Concepts

Overview of authentication in Forefront TMG