Understanding ADAM access control

  • Article

Applies To: Windows Server 2003 R2

Access control

The term access control describes how a directory service provides and secures access to directory data. Access control in Active Directory Application Mode (ADAM) consists of two parts. First, ADAM authenticates the identity of users requesting access to the directory, allowing only successfully authenticated users into the directory. Second, ADAM uses security descriptors, called access control lists (ACLs), on directory objects to determine to which objects an authenticated user has access.

Authentication

Users, or security principals, request directory data from ADAM through directory-enabled applications, which in turn make requests to ADAM using Lightweight Directory Access Protocol (LDAP). Before making a request for data, the directory-enabled application must present the user's credentials to ADAM for authentication, or binding. This request includes a user name, password, and—depending on the type of bind—a domain name or computer name.

ADAM can accept authentication, or bind, requests from both ADAM security principals and Windows (local and domain) security principals. ADAM security principals are authenticated directly by ADAM. Local Windows security principals are authenticated by the local computer. Domain security principals must authenticated by an Active Directory domain controller. The following table summarizes supported authentication methods in ADAM, based on the type of security principal.

Security principal Accepted credential formats Authenticated by

ADAM
  • Distinguished name

  • Canonical name

  • displayName attribute value

  • User principal name (UPN)

ADAM instance

Workstation account
  • Machine name\account

Local Security Authority (LSA) on the local computer

Domain account
  • Domain name\account

  • UPN

LSA on a domain controller from the user's domain

Note

A UPN that is used in ADAM does not require the use of the "@" symbol.

The possible authentication paths in ADAM are shown in the figure below.

ADAM authentication

For more information about binding to LDAP directories, see Establishing an LDAP Session (https://go.microsoft.com/fwlink/?LinkId=99557).

ADAM security principals

ADAM security principals are users or other objects that are created and reside in the ADAM directory. ADAM security principals can be created based on the importable user classes (including inetOrgPerson) that are provided with ADAM. Or, ADAM security principals can be created from any object class in the schema that contains the SecurityPrincipal static auxclass and the unicodePwd attribute. ADAM assigns each ADAM security principal a unique security ID (SID), which is guaranteed to be unique across all ADAM naming contexts. For more information about ADAM security principals, see Understanding ADAM users and groups.

ACLs

Permissions on ADAM directory objects are assigned to users and groups using access control lists (ACLs). An ACL contains a list of users and groups that have been assigned permissions on a directory object, and it also contains the types of permissions (read, write, and so on) that they have been assigned. (Each individual entry in an ACL is called an access control entry (ACE).) If an ACL on a directory object does not explicitly assign permissions to a user, or to any groups that a user is a member of, the user will be denied access to that object.

For the most part, ACLs in ADAM function the same as in Active Directory. ACEs differ between ADAM and Active Directory in that ADAM validates SIDs as they are added to the ACE, while Active Directory allows all user SIDs. ADAM user SIDs are allowed only if one of the following conditions is true:

  • The ADAM user is in the same naming context as the object to which the ACE is added.

  • The object is in the schema naming context.

  • The object is in the configuration naming context.

Security context

After a user has been successfully authenticated, ADAM can construct the security context for the authenticated user. This security context specifies the SID of the user, along with a list of all of the groups to which the user belongs.

The security context for an authenticated Windows security principal includes:

  • The user's SID

  • The user's Windows group memberships

  • The user's ADAM group memberships (including those groups in which the user is a direct member and those groups in which the user is a member through recursive group expansion)

The security context for an authenticated ADAM security principal includes:

  • The user's SID

  • SIDs of each of the following ADAM groups:

    • Everyone

    • AuthUsers

    • Users group from the partition in which the ADAM user resides

    • Users group from the configuration partition

    • Groups in which the user is a member through recursive group expansion

By comparing an authenticated user's security context with the ACL on the directory object to which the user has requested access, ADAM can determine whether to grant the user access to the object.

Retrieving user SIDs

You can retrieve an active user's SIDs by explicitly querying the tokenGroups attribute on the rootDSE. The tokenGroups attribute is a multivalued attribute. The first value represents the user's individual SID, with the values following representing the user's ADAM and Windows group SIDs.

For more information about how access control is determined in Active Directory and ADAM, see Controlling Access to Objects in Active Directory Domain Services (https://go.microsoft.com/fwlink/?LinkId=99558).