In Windows Active Directory Domain Services (AD DS) validation, the credentials entered by the client are passed to a domain controller, which checks the credentials against the AD DS list of users. The client must use one of the following formats when entering the credentials recognized by the domain controller:

• Security Accounts Manager (SAM) account name (domain\username).
  
  
• User principal name (username@domain.com).
  
  
• Distinguished name.
  
  

AD DS validation can take place only when Forefront TMG is a domain member (either in the same domain as the domain controller, or in a trusted domain).

You can use AD DS to validate client credentials for outbound Web requests and inbound requests for published Web servers.

This validation method is similar to Windows AD DS validation. In this method, Forefront TMG connects to a Lightweight Directory Access Protocol (LDAP) server over an LDAP protocol (LDAP, LDAPS, LDAP-GC, and LDAPS-GC are supported). Note that every domain controller is an LDAP server. The LDAP server keeps a store of the AD DS users' credentials. Because each domain controller can only authenticate the users in its domain, Forefront TMG, by default, queries the global catalog for a forest to validate the user credentials.

The client must use one of the following formats when entering the credentials recognized by AD DS:

• SAM account name (domain\username).
  
  
• User principal name (username@domain.com).
  
  
• Distinguished name.
  
  

You can use LDAP to validate client credentials only for inbound requests for published Web servers.

When Forefront TMG acts as a Remote Authentication Dial-In User Service (RADIUS) client, it sends user credentials to a RADIUS server. The RADIUS server authenticates the RADIUS client request and sends back a RADIUS message response. In the Forefront TMG Management console, you can configure RADIUS servers to be used for authentication and configure a shared secret. You configure the same shared secret on the RADIUS server.

You can use RADIUS authentication for outbound Web proxy requests and incoming requests for published Web servers.

Forefront TMG can use a RADIUS one-time password to validate credentials for incoming requests to published Web servers. One-time password mechanisms typically consist of portable devices (physical tokens) and a server. Both the server and the devices produce a new passcode at a given frequency. The passcodes are specific to each device (no two devices share the same passcode). The server that validates the passcodes is installed on a RADIUS server and can be associated with the existing list of RADIUS users.

Note the following information about passcodes:

• Each passcode can only be used once.
  
  
• On the form provided by Forefront TMG, the user enters the user name and passcode provided by the portable device. Forefront TMG sends the user name and passcode to the RADIUS server for validation.
  
  
• Because the passcode cannot be used a second time, Forefront TMG does not revalidate the credentials for each request. Instead, Forefront TMG issues a cookie to the client that allows continued communication without reauthenticating.
  
  
• Some RADIUS servers block the logon of a user who has failed to log on after a specified number of times. If a malicious user intentionally attempts to log on that number of times, by using a legitimate user name and wrong passcodes, the user is locked out of the system until you reset access for the user. It is recommended that you disable the lockout feature on the RADIUS one-time password server to prevent this from occurring. The Forefront TMG setting HTTP requests per minute, per IP address (which you can configure on the Flood Mitigation properties of Forefront TMG) mitigates brute force password-guessing attacks, so you can disable the RADIUS lockout feature safely.
  
  

RSA SecurID is based on technology from RSA Security Inc. Forefront TMG can also use SecurID to validate the credentials for incoming requests for published Web resources.

SecurID requires that a remote user provides the following information to gain access to protected resources:

• Personal identification number (PIN).
  
  
• Physical token that produces a time-limited one-time password.
  
  

Note:
Neither the PIN nor the token-generated one-time password grant access in isolation from each other. Both are required.

When a user attempts to access Web pages controlled by a rule using SecurID authentication, the Forefront TMG server, on behalf of the server running Internet Information Services (IIS) that Forefront TMG secures, checks for a cookie. This cookie will be present only if the user has authenticated recently, and if it is not persistent. If the user's cookie is missing, the user is prompted for a user name and passcode for SecurID. The passcode consists of a combination of the user's PIN and tokencode. The RSA ACE/Agent on the Forefront TMG server passes these credentials to the RSA ACE/Server computer for validation. If the RSA ACE/Server successfully validates the credentials, a cookie is delivered to the user's browser for subsequent activity during the session, and the user is granted access to the content.

Note the following information:

• For SecurID delegation, Forefront TMG generates cookies that are compatible with RSA Authentication Agent 5.0. When you use SecurID delegation, you must configure the authentication agent computer to trust those cookies. To do this, in the authentication agent computer registry, add the following string value:
  Agent50CompatibleCookies under HKLM\Software\SDTI\RSAAgent.
  
  
• If Forefront TMG is configured with multiple network adapters, and you create a Web listener with RSA SecurID authentication enabled, you should explicitly configure the network adapter address through which Forefront TMG connects to the RSA ACE/Server for authentication purposes; otherwise, Forefront TMG may fail to perform SecurID authentication. Specify the IP address in the following registry key as a string value:
  HKEY_LOCAL_MACHINE\SOFTWARE\SDTI\AceClient\PrimaryInterfaceIP
  
  
• It is recommended that you use SSL to encrypt the communication between the client and Forefront TMG.
  
  
• For additional information about RSA ACE/Server installation, configuration, and authentication concepts, see the documentation available at the RSA Web site (http://www.rsasecurity.com).
  
  

Concepts