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 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:

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 http://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 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.