Share via

5.1.3.1 Background

  • Article

The security context of a requester (see security context in the Glossary) requesting access to an Active Directory object represents the authorization information that is associated with the requester. A DC performs an access check to determine whether the security context, and thus the requester, is authorized for the type of access that has been requested before allowing any further processing to continue. Access control information associated with an object is contained in the security descriptor of the object.

Every object in Active Directory has an nTSecurityDescriptor attribute whose value is the security descriptor that contains access control information for the object.

An access check compares information in the thread's security context with information in the object's security descriptor:

  • The security context contains a SID that identifies the principal associated with the thread, and SIDs that identify the groups of which the principal is a member.

  • The security descriptor contains a DACL that specifies the access rights that are allowed or denied to specific principals or groups. It also identifies the owner of the object. The structure of a security descriptor is described in [MS-DTYP] section 2.4.6.

A DACL in a security descriptor is an ordered list of access control entries (ACEs) that define the protections that apply to an object and its properties. Each ACE identifies a security principal (that is, a user, group, and so on) and specifies a set of access rights that are allowed, denied, or audited for that security principal. The data structures for an ACE and a DACL are described in [MS-DTYP] sections 2.4.4 and 2.4.5.

There are two types of ACEs: simple and object-specific. A simple ACE applies to an entire object. If a simple ACE gives a particular user read access, the user can read all information associated with the object. An object-specific ACE, on the other hand, can apply to any individual attribute of an object or to a set of attributes. It makes it possible to place independent access controls on each attribute of an Active Directory object.

During an access check, the server steps through the ACEs in the order in which they appear in the object's DACL, looking for ACEs that apply to the principal and group SIDs from the thread's security context. It steps through each ACE until it finds one that either allows or denies access to the principal or one of the principal's groups, or until there are no more ACEs to check. If it comes to the end of the DACL, and the thread's desired access is still not explicitly allowed or denied, the server denies access to the object.

The order in which ACEs are listed in a DACL is important. For example, an object's DACL might contain one ACE that allows access to a group and another ACE that denies access to a principal who is a member of the group. If the access check process encounters the ACE that allows access to the group before the ACE that denies access to the principal, the principal is allowed access to the object. If the ACEs are encountered in the reverse order, then the principal is denied access to the object.

AD LDS security principals cannot appear in an AD DS ACE. Section 6.1.3.3 specifies a restriction on the AD LDS security principals that can be used in an AD LDS ACE.