AD FS is tightly integrated with AD DS. AD FS retrieves user attributes and authenticates users against AD DS. AD FS also uses Windows Integrated Authentication and security tokens that AD DS creates.

For a user to log on to AD DS, a user name must be in the user principal name (UPN) format (user@adatum.com) or in the Security Accounts Manager (SAM) account name format (adatum\user).

Access tokens are generated when a user logs on. They contain the security identifiers (SIDs) for the user and any groups that the user belongs to. A copy of the access token is assigned to every process that the user starts.

After the user is logged on and impersonated, user SIDs are enumerated from the access token. The SIDs are then mapped to organization group claims.

Caution

When you enable the Windows trust option in the account Federation Service, you are sending actual SIDs to the resource partner organization over the Internet, which may be a security risk. These SIDs are packaged in the AD FS Security Assertion Markup Language (SAML) token. Therefore, enable this option only when you are using the Federated Web SSO with Forest Trust design. This design is meant to establish secure communication within the same organization.

E-mail claims, common name claims, and custom claims can be extracted from user object attributes that are defined in AD DS when the Federation Service account is used to perform an LDAP search of an object.

The Federation Service account must have access to the user object. If the user object resides in a domain different from the domain where the Federation Service account resides, the former domain must have in place an AD DS domain trust to the latter domain.

There is no direct way of determining whether any given user name exists in AD DS and in all directories that it trusts (either directly or transitively). AD DS returns an authoritative failure only if the logon attempt fails as a result of policy restrictions. Examples of policy restriction failures include the following:

• The account is disabled.
  
  
• The account password has expired.
  
  
• The account is not allowed to log on to this computer.
  
  
• The account has logon time restrictions and is not allowed to log on at this time.
  
  

Otherwise, AD DS account store logon failures are always nonauthoritative, and the next-priority account store is tried. For more information about account store logon failures, see Troubleshooting AD FS.

AD LDS provides data storage and retrieval for directory-enabled applications, without the dependencies that AD DS requires. AD LDS provides much of the same functionality as AD DS, but it does not require the deployment of domains or domain controllers. Similar to the way in which AD FS uses AD DS account store information, AD FS can also retrieve user attributes and authenticate users with AD LDS.

	Note
	AD FS cannot authenticate AD LDS accounts that use parentheses as part of the account name. Accounts that have an open parenthesis in the user name cause an LDAP search failure as a result of the user name forming an invalid LDAP filter.

The Federation Service account obtains the claims that are used to perform an LDAP search for the object. For more information, see Understanding Claims. This is a two-step process:

• First, the Federation Service account finds the user object through a search for the object whose configured attribute is equal to the supplied user name. The Federation Service account uses Kerberos authentication or NTLM encryption to protect this communication.
  
  

  	Note
  	This process requires the AD LDS server to be joined to a domain that trusts the domain that the Federation Service is a member of.

• Next, the user credentials are validated through an LDAP bind to the found user object with the supplied password. If Transport Layer Security and Secure Sockets Layer (TLS/SSL) are configured for the AD LDS account store properties in the trust policy, the user credentials are protected.
  
  

  	Important
  	We strongly recommend that the traffic between the AD LDS server and the federation server be protected by TLS/SSL or other means, such as Internet Protocol security (IPsec).

If more than one object is returned from the LDAP query with the supplied user name, this is considered an authentication failure.

The user account is looked up first in the AD LDS account store if it is configured, and then the other LDAP stores are configured in that order. If any of the stores find the user account, it does an authoritative logon of the user, and no other account store is called to process the user logon request.

When a user makes a logon request to either AD DS or AD LDS through an AD FS client, the request passes immediately to the specified account store. However, if the account store Uniform Resource Identifier (URI) is not specified, the Federation Service tries each store in priority order to log on the user. The authentication result is returned if:

• There is only one store configured and credential verification information is returned.
  
  
• The store URI was specified in the logon request and credential verification information is returned.
  
  
• The authentication result by one of the stores is authoritative.
  
  
• Authentication by one of the stores is successful.
  
  

You can mark each account store as enabled or disabled. If an account store is disabled, it does not participate in any account-store-related operations. Cookies with claims that originate from a currently disabled account store are discarded or deleted, and the client is directed to the logon page.