This topic provides an overview of the authentication methods used by Forefront TMG. They include:
For a summary of scenarios in which each method is used, see Overview of authentication in Forefront TMG.
Forefront TMG supports the following types of HTTP 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:
- The user is prompted to enter a Windows account user name and
- 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).
- 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 (http://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:
- The client makes a request.
- 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 http://host.domain.tld fails
because the URL resource is missing.
- 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:
- 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
- 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
- Forefront TMG continues to prompt the user until the user
either enters a valid user name and password, or closes the prompt
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
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.