Active Directory Federation Services (AD FS) uses account stores to log on users and extract security claims for those users. You can configure multiple account stores for a single Federation Service. You can also define their priority. The Federation Service uses Lightweight Directory Access Protocol (LDAP) to communicate with account stores. AD FS supports the following two account stores:
- Active Directory Domain Services
- Active Directory Lightweight Directory
Services (AD LDS)
AD FS works with both enterprise-wide deployments of AD DS or instances of AD LDS. When it works with AD DS, AD FS can take advantage of the strong authentication technologies in AD DS, including Kerberos, X.509 digital certificates, and smart cards. When it works with AD LDS, AD FS uses LDAP Bind as a means to authenticate users.
AD DS account stores
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 (firstname.lastname@example.org) 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.
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
- 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 account stores
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.
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.
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
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.
Determining the priority order of user logon requests
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
Disabling account stores
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.