The contents of an Active Directory are arguably an organization's most valuable assets because they comprise the very building blocks of IT and identity and access management, i.e. domain user accounts, computer accounts, security and distribution groups, group policies and other valuable components, and in fact are the raison d'etre that Active Directory actually exists and needs to be secured, and access to the entirety of Active Directory's contents is protected by Active Directory's security model.

The following is a summary of how Active Directory's Security Model protects Active Directory Contents -

Every object in Active Directory, is represented as a securable object that is an instance of a specific instantiable Active Directory class, as defined in the Active Directory Schema.

Every instantiated securable object in Active Directory has a security descriptor, comprised of four fields - the object's owner, primary group, a discretionary access control list (ACL) and a system access control list (SACL).

The access control list (ACL) of a securable object contains zero or more access control entries (ACEs), and each ACE specifies the Active Directory Security Permissions that are allowed or denied to a specific security principal on the object.

When an account attempts to access an Active Directory object, the system subjects the request to an access check, which takes into consideration the access requested, the identity (SID) of the account and all of its security affilliations (SIDs of all its group memberships) specified in the account's Access Token and the access specified in the ACEs in the object's ACL, and examines each ACE in the ACL, in order, until a match is found, based on which an access decision, Allow or Deny, is made.




The Most Important Takeaway -

The ACEs in an Active Directory object's ACL are arranged in a specific order, which is -  [ All explicit deny ACEs ]  are followed by  [ All explicit allow ACEs ]  are followed by  [ All inherited deny ACEs ]  are followed by  [ All inherited allow ACEs ].

Since the access check examines each ACE in the ACL until a match is found, in order, starting from the beginning, all explicit deny ACEs will always override all allow ACEs, and all inherited deny ACEs will always override inherited allow ACEs.

Note - Due to this important technicality, just because a user/group has Allow permissions in an Active Directory object's ACL does not mean that he/she actually has the specified access on the object ; he/she could be directly/indirectly denied the same access in another overriding Deny permission.




Consequently it is the resulting i.e. effective access, also known as Active Directory Effective Permissions, that an account has on an Active Directory object that ultimately governs and controls what access the account actually has on the object.

In essence, Active Directory Security Permissions specified in Active Directory ACLs represent an organization's access intent and the resulting Active Directory Effective Permissions determine the actual access that principals have in Active Directory.