About authentication in Web publishing

Updated: February 1, 2011

Applies To: Forefront Threat Management Gateway (TMG)

When clients request access to published internal Web servers, there are three components of the authentication process in Forefront TMG:

• Receipt of client credentials.

• Validation of client credentials against an authentication provider such as Active Directory Domain Services (AD DS), RADIUS, or SecurID Authentication Manager.

• Delegation of authentication to Web servers that are behind Forefront TMG, such as servers running SharePoint Portal Server 2007.

  Note

  The first two components are configured on the Web listener that receives client requests. The third is configured on the publishing rule. This means that you can use the same listener for different rules and have different types of delegation.

The following figure demonstrates the authentication process for forms-based authentication. Note that this is a simplified description of the process, presented to describe the primary steps involved.

Step 1, receipt of client credentials—The client sends a request to connect to the corporate Outlook Web Access server in the Internal network. The client provides the credentials in HTML.

Steps 2 and 3, sending credentials—Forefront TMG sends the credentials to the authentication provider, such as a domain controller for AD DS authentication or a RADIUS server, and receives acknowledgment from the authentication provider that the user is authenticated.

Step 4, authentication delegation—Forefront TMG forwards the client's request to the Outlook Web Access server and authenticates to the Outlook Web Access server by using the client's credentials. The Outlook Web Access server revalidates those credentials, typically using the same authentication provider.

Step 5, server response—The Outlook Web Access server sends a response to the client, which is intercepted by Forefront TMG.

Step 6, forwarding the response—Forefront TMG forwards the response to the client.

Client authentication methods for receipt of client credentials

Forefront TMG Web listeners accept the following types of authentication from clients:

• No authentication.

• Forms-based authentication

• HTTP authentication (received in HTTP header)

• Client certificate authentication

No authentication

You can select that Forefront TMG will not require authentication. If you do so, you are not able to configure a delegation method on rules that use this Web listener.

Forms-based authentication

You can use forms-based authentication in Forefront TMG for publishing any Web server. Three types of forms-based authentication are available in Forefront TMG:

• Password form—The user enters a user name and password on the form. This is 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. 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 applying SecurID or RADIUS one-time password authentication methods. The user name and password are used for delegation.

Fallback to Basic authentication

By default, when form-based authentication cannot be used with a specific client, Forefront TMG requires Basic authentication instead. This is configured in the Forefront TMG COM in the user agent mappings collection:

FPCRuleElements.UserAgentMappings

For more information, see Managing User-Agent Mappings (https://go.microsoft.com/fwlink/?LinkId=106693).

Forms for mobile clients

Forefront TMG provides forms for a variety of mobile clients. These forms are in the CHTML and XHTML (representing XHTML-MP forms) folders, which can be found in the following location:

Forefront TMG Installation Directory\Templates\CookieAuthTemplates

Forefront TMG uses the User-Agent header provided by the mobile client in order to determine the type of form to provide.

Password management in forms-based authentication

When you use forms-based authentication, Forefront TMG enables you to warn users about passwords that are about to expire (in a number of days that you configure) and to allow users to change their passwords. You can use these two functionalities separately or in combination. For example, you can warn users that their passwords are about to expire but not allow them to change their passwords. Or you can allow them to change passwords but not provide a warning about passwords that are about to expire.

When you allow users to change their passwords, that option is available on the logon form. When you configure Forefront TMG to warn users about passwords that are about to expire, users receive a separate warning page on which they can choose whether to change their passwords. For instructions about how to configure the change password feature, see Configuring the change password feature.

HTTP authentication

Forefront TMG supports the following types of HTTP authentication:

• Basic authentication—Using Basic authentication, the requesting client is prompted for credentials. Forefront TMG validates the credentials and, in passing the request to the Web server, uses the credentials in order to authenticate to the Web server in accordance with the configured delegation method. The Web server must be configured to use the authentication scheme that matches the delegation method used by Forefront TMG. For more information about Basic authentication, see About authentication methods.

• Digest and WDigest authentication—Using Digest or WDigest authentication, the client makes a request. Forefront TMG denies the request and asks the client for authentication information. The credentials are sent to a domain controller for validation. For more information, see About authentication methods.

• Integrated Windows authentication (NTLM)—Uses the NTLM, Kerberos, and Negotiate authentication mechanisms. The current Windows information on the client computer is used for authentication. If the authentication exchange fails, the browser prompts until the user enters valid credentials or closes the prompt dialog box. For more information about this authentication method, see About authentication methods.

Client certificate authentication

In the client certificate scenario, the client provides a certificate, and Forefront TMG authenticates the client on the basis of that certificate. This might be a certificate 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.

Methods for validation of client credentials

Forefront TMG supports the following server types for validating client credentials:

• No authentication (allows the internal servers to handle authentication)

• Windows Active Directory

• LDAP server

• RADIUS

• RADIUS one-time password

• SecurID

You can configure the receipt and validation of client credentials on the Web listener for a publishing rule. A publishing rule with a Web listener that uses a specific form of credential validation must use a user set that is consistent with that form of validation. For example, a publishing rule with a Web listener that uses LDAP credential validation must also use a user set that consists of LDAP users. It cannot include AD DS users.

Authentication delegation

After validating the credentials, you can configure publishing rules to use one of the following methods in order to delegate the credentials to the published servers:

• No delegation, and client cannot authenticate directly

• No delegation, but client may authenticate directly

• Basic

• NTLM

• NTLM/Kerberos (Negotiate)

• SecurID

• Kerberos constrained delegation

Configuring authentication delegation

Delegation of client credentials is configured on the publishing rule. In the Publishing Rule wizard, configure this on the Authentication Delegation page. In the publishing rule properties, the authentication settings are on the Authentication Delegation tab.

No delegation, and client cannot authenticate directly

In this option, Forefront TMG does not delegate credentials. This is intended to prevent the unintentional delegation of credentials into the organization, where they might be sniffed. This is the default setting in some Forefront TMG publishing wizards, so you must change the default if you want to delegate the credentials.

No delegation, but client may authenticate directly

When you select the delegation method No Delegation, but client may authenticate directly, Forefront TMG passes the user's credentials to the destination server without any additional action on the part of Forefront TMG. The client and the destination server then negotiate the authentication.

Basic

In Basic delegation, Forefront TMG forwards credentials in plaintext to the server that requires credentials. If authentication fails, Forefront TMG prompts the user for authentication according to the authentication type configured on the Web listener. If the server requires a different type of credentials, Forefront TMG triggers an alert.

NTLM

In NTLM delegation, Forefront TMG delegates the credentials by using the NTLM challenge/response authentication protocol. If authentication fails, Forefront TMG replaces the delegation with the authentication type used by the Web listener. If the server requires a different type of credentials, Forefront TMG triggers an alert.

NTLM/Kerberos (Negotiate)

When you select Negotiate as a delegation method, Forefront TMG first attempts to obtain a Kerberos ticket for the client from the domain controller. If Forefront TMG does not receive the Kerberos ticket, it uses the negotiate scheme to delegate the credentials by using NTLM. If Forefront TMG receives the Kerberos ticket, it uses the negotiate scheme to delegate the credentials by using Kerberos. If authentication fails, Forefront TMG provides the server's failure notice to the client. If the server requires a different type of credentials, Forefront TMG triggers an alert.

The default service principal name (SPN) used to obtain the ticket is http/internalsitename. In the case of a server farm, the SPN is the name of the farm. You can chance the default SPN in Forefront TMG Management on the Authentication Delegation tab of the rule.

SecurID

When a client provides SecurID credentials, you can use SecurID authentication delegation. Forefront TMG passes the proprietary SecurID cookie to the published server. Note that Forefront TMG and the published server must have the same domain secret and cookie name.

Kerberos constrained delegation

Beginning with ISA Server 2006, Kerberos constrained delegation is supported. For more information about Kerberos constrained delegation, see Kerberos Protocol Transition and Constrained Delegation (https://go.microsoft.com/fwlink/?LinkID=56785).

Without Kerberos constrained delegation, Forefront TMG can delegate credentials only when client credentials are received using Basic or forms-based authentication. With Kerberos constrained delegation, Forefront TMG can accept other types of client credentials, such as client certificates. Forefront TMG must be enabled on the domain controller in order to use Kerberos constrained delegation (constrained to a specific service principal name).

If authentication fails, Forefront TMG provides the server's failure notice to the client. If the server requires a different type of credentials, Forefront TMG triggers an alert.

Valid combinations of client credentials and delegation methods

Not every method of delegation is valid for a particular type of client credential. The following table summarizes the valid combinations

Related Topics

Concepts

Overview of authentication in Forefront TMG
About two-factor authentication
About credential caching
About publishing Web servers