Freigeben über

Account stores

  • Artikel

Applies To: Windows Server 2003 R2

Active Directory Federation Services (ADFS) 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 and define their priority. The Federation Service uses Lightweight Directory Access Protocol (LDAP) to communicate with account stores.

ADFS supports two types of account stores: Active Directory account stores and Active Directory Application Mode (ADAM) account stores.

Active Directory account stores

ADFS is tightly integrated with Active Directory. ADFS retrieves user attributes and authenticates users against Active Directory. ADFS also uses Windows Integrated Authentication and security tokens that Active Directory creates.

For a user to log on to Active Directory, 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). After the user is logged on and impersonated, user security IDs (SIDs) are enumerated from the access token. The SIDs are then mapped to organization group Claims.

E-mail claims, common name claims, and custom claims can be extracted from user object attributes that are defined in Active Directory 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 an Active Directory domain trust in place to the latter domain.

There is no direct way of determining whether any given user name exists in Active Directory and in all directories that are trusted (either directly or transitively) by Active Directory. Active Directory 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, Active Directory account store logon failures are always nonauthoritative, and the next-priority account store is tried. For more information about account store logon failures, see ADFS troubleshooting.

The following is the list of configuration items for the Active Directory account store:

  • A setting indicating whether this entry is enabled

  • The display name for the trusted Active Directory account store

  • Optional: A list of SIDs that map to particular organization group claims

  • Optional: Configuration defining how to extract organization claims from user object attributes in Active Directory:

    • E-mail identity claim or common name identity claim

    • Custom organization claim

The name of a user object attribute defines the claim name when a custom claim is built.

ADAM account stores

ADAM provides data storage and retrieval for directory-enabled applications, without the dependencies that are required for Active Directory. ADAM provides much of the same functionality as Active Directory, but it does not require the deployment of domains or domain controllers. Similar to the way in which ADFS uses Active Directory account store information, ADFS also retrieves user attributes and authenticates users with ADAM.

Note

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

Security claims are obtained when the Federation Service account is used to perform an LDAP search of the object. This is a two-step process:

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

    Note

    This process requires the ADAM 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 by binding to the found user object with the supplied password using LDAP. If Transport Layer Security and Secure Sockets Layer (TLS/SSL) are configured for the ADAM account store properties in the trust policy, the user credentials are protected.

    Important

    It is strongly recommended that the traffic between the ADAM 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. For more information about authentication failures, see ADFS troubleshooting.

Because the presence of the user object is always determined, if the user account exists in the ADAM store, the ADAM store logon is authoritative. Therefore, no additional account stores are attempted. The following is the list of configuration items for the ADAM store:

  • A setting indicating whether this entry is enabled

  • The display name for the trusted ADAM account store

  • The ADAM server name

  • An LDAP user object attribute containing the user name

  • Optional: Port number. If the port number is not specified, it defaults to 389.

  • Optional: Search base. If a subtree is specified, searches are performed on the specified subtree. Otherwise, the entire directory tree is searched.

  • Optional: Client timeout: the maximum time that Federation Service waits for a response from the ADAM server before timing out the connection. The default is five seconds.

  • Optional: Configuration defining how to extract organization claims:

    • UPN/e-mail/common name identity claim: The name of a defined user object attribute whose value is extracted as the UPN/e-mail/common name claim value

    • Group organization claim: The name of a user object attribute and its value that, if present, results in the particular group claim

    • Custom organization claim: The name of a defined user object attribute whose value is extracted as the particular custom claim value

If this configuration is absent, the directory is used only to log on the user — without extracting claims.

Determining the priority order of user logon requests

When a logon request is made to either Active Directory or ADAM through an ADFS client, it is passed immediately to the specified account store. However, if the account store Uniform Resource Identifier (URI) is not specified, each of the stores is tried 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 result of authentication by one of the stores was authoritative.

  • Authentication by one of the stores was successful.

Disabling account stores

Each account store can be marked 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 an account store that is currently disabled are discarded or deleted, and the client is directed to the logon page.