This topic provides an overview of the authentication servers that can be used to validate client credentials in Forefront TMG. They include:
Windows Active Directory Domain Services
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
- User principal name
- 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
- User principal name
- 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.
RADIUS one-time password
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
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
|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:
- 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