About authentication methods
This topic provides an overview of the client authentication methods used by Microsoft Forefront Threat Management Gateway.
Forefront TMG supports the following types of HTTP authentication:
- Basic authentication
- Digest and WDigest authentication
- Integrated Windows 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 password.
- Forefront TMG receives the HTTP request with the credentials and validates the credentials against the specified authentication server (RADIUS or Active Directory, 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, but 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 us 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 has a more secure way of transmitting the authentication credentials.
Digest authentication relies on the HTTP 1.1 protocol as defined in RFC 2617. 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 Active Directory. To allow passwords to be stored in plaintext, you need to activate the Store password using the reversible encryption setting on the Account tab of the user in Active Directory. Alternatively, you can set group policy to enable this capability. After making this setting, you need to set a new password in order 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 have the requirement that a reversibly encrypted copy of the user password is stored in Active Directory.
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 Active Directory. 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 is a clear advantage over Basic authentication because it makes it more difficult for an unauthorized person to intercept or use the password.
Integrated (NTLM) 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 authentication.
- Forefront TMG continues to prompt the user until the user either enters a valid user name and password or closes the prompt dialog box.
- Forefront TMG communicates with the Active Directory server whenever NTLM authentication is required. For this reason, we recommend that you create a protected network for Active Directory and Forefront TMG in order to prevent users (both external and internal) from accessing the communication.
- Because authentication for an external connection uses NTLM authentication, we recommend 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 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. This is the type of credentials needed for Active Directory, LDAP, and RADIUS credential validation.
- Passcode form—The user enters a user name and passcode on the form. This is 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. You can use a client certificate in order to authenticate Forefront TMG to an upstream proxy server. For more information, see About Web proxy chaining.
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.