About authentication for published resources

When clients request access to published internal resources, there are three components of the authentication process in Microsoft Forefront Threat Management Gateway:

• Receipt of client credentials.

• Validation of client credentials against an authentication provider such as Active Directory, RADIUS, or SecurID Authentication Manager.

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

  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 Active Directory 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.

Note

The Web server must be configured to use the authentication scheme that matches the delegation method used by Forefront TMG.

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.

Notes

• If you do not limit access to authenticated users, as in the case when a rule allowing access is applied to all users, Forefront TMG does not validate the user's credentials. Forefront TMG uses the user's credentials to authenticate to the Web server according to the configured delegation method.
• We recommend that you apply each publishing rule to all authenticated users or a specific user set rather than selecting Require all users to authenticate on the Web listener, which requires any user connecting through the listener to authenticate.

Client authentication methods for receipt of client credentials

Microsoft Forefront Threat Management Gateway 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 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 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" at the Microsoft TechNet Web site.

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.

Notes

• The HTML forms for forms-based authentication can be fully customized.
• When you configure Forefront TMG to require authentication, when a publishing rule applies to a specific user set or All Authenticated Users, or a Web listener is configured to Require all users to authenticate, Forefront TMG validates the credentials before forwarding the request.
• By default, the language setting of the client's browser determines the language of the form that Forefront TMG provides. Forefront TMG provides forms in 26 languages. Forefront TMG can also be configured to serve forms in a specific language regardless of the browser's language.

Security Notes

• When you configure a time-out for forms-based authentication, we recommend that the time-out be shorter than that imposed by the published server. If the published server times out before Forefront TMG, the user may mistakenly think that the session ended. This could allow attackers to use the session, which remains open until actively closed by the user or timed out by Forefront TMG as configured on the form setting.
• You should ensure that your Web application is designed to resist session riding attacks (also known as cross-site-posting, cross-site-request-forgery, or luring attacks) before publishing it by using Forefront TMG. This is particularly important for Web servers published through Forefront TMG, because clients must use the same trust level for all of the Web sites they access through the publishing Forefront TMG firewall.
• In a forms-based authentication scenario where a client certificate is required and the user declines to provide a certificate, the user is able to access the logon form. The logon is then denied by Forefront TMG because of the lack of a client certificate.
• Forms customization involves modification of the Strings.txt file. If you provide the Strings.txt file to a third party for modification, validate that non-text additions have not been made to the file, because these may provide a means of attack on your networks.

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 Active Directory users.

Important

When you use the same Web listener to publish more than one application in the same domain, a user who is authenticated for one application will also be able to access the others, even if single sign-on (SSO) is not enabled.

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 Microsoft Forefront Threat Management Gateway 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.

Note

In Microsoft Exchange Server 2003, Internet Information Services (IIS) runs under the Network Service account. Forefront TMG uses the wildcard SPN HTTP* and replaces the asterisk with the host name of the published site.

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.

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.

Note

• Use of Kerberos constrained delegation requires that you configure Active Directory to recognize Forefront TMG as trusted for delegation.
• The default 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 change the default SPN in Forefront TMG Management on the Authentication Delegation tab of the rule.
• To use Kerberos constrained delegation, your domain must run in the Windows Server 2003 or higher domain functional level.
• Kerberos authentication depends upon UDP packets. These are commonly fragmented. If your Forefront TMG computer is in a domain and you enable the blocking of IP fragments, Kerberos authenticaion fails. For example, if the computer uses Kerberos for authentication during user logon, logon fails. In scenarios where Kerberos authentication is used, we recommend that you do not enable the blocking of packets containing IP fragments.
• SharePoint Portal Server 2003 disables Kerberos by default, so NTLM/Kerberos (Negotiate) and Kerberos constrained delegation do not work with SharePoint publishing. To enable Kerberos, follow the instructions at Microsoft Help and Support.
• In Microsoft Exchange Server 2003, IIS runs under the Network Service account, and Forefront TMG uses the wildcard SPN HTTP\* and replaces the asterisk with the host name of the published site.

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

Receipt of client credentials	Authentication provider	Delegation
Forms-based authentication (password only) Basic	Active Directory (Windows) Active Directory LDAP RADIUS	No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Basic NTLM Negotiate Kerberos constrained delegation
Digest Integrated	Active Directory (Windows)	No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Kerberos constrained delegation
Forms-based authentication with passcode	SecurID RADIUS one-time password	No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly SecurID Kerberos constrained delegation
Forms-based authentication (passcode and password)	SecurID RADIUS one-time password	No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Basic NTLM Negotiate SecurID (not with RADUIS one-time password)
Client certificate	Active Directory (Windows)	No delegation, but client may authenticate directly No delegation, and client cannot authenticate directly Kerberos constrained delegation