Delegation and Access Control

Applies To: Microsoft Hyper-V Server 2008, Microsoft Hyper-V Server 2008 R2, Windows SBS 2003, Windows SBS 2008, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Access control is the means by which administrators can control, or delegate, the ability of other users to manipulate objects in Active Directory and also to perform actions on domain controllers and file servers. Understanding the access-control model in Active Directory is essential to being able to delegate administration. This section provides an overview of the access control model in Active Directory and describes all relevant aspects of access control that are required to delegate administrative authority.

Access control involves three components:

• The security credentials of the user attempting to access a resource

• Authorization data that protects the resource that is being accessed

• An access check that evaluates whether or not the requested access can be granted

When a user (or a process that is running on behalf of the user) attempts to perform a low-level operation on a securable object, the operation being attempted is subject to an access check. The access check takes into account the user security credentials and the authorization data on the object on which the low-level operation is being requested to determine the abilities of the user in relation to the respective object. If the access check determines that the security credentials of the user requesting the operation and the authorization data on the target object provides sufficient permissions to execute the operation, the operation succeeds. If the user has insufficient permissions to execute the operation that is being requested, the request fails.

The act of delegating Active Directory administrative responsibilities involves identifying the low-level operation that corresponds to the administrative task and the specific data on which it is being performed, and then appropriately modifying authorization settings that protect the data.

Characteristics of the Access Control Model

As in Windows NT 4.0, the access-control model in Windows 2000 and Windows Server 2003 has the following characteristics:

User-based authorization

Provides the ability of a system to identify a user and match that user to access criteria for a resource. Any resource that can be manipulated by a program or process is represented as a securable object. When a user (or a process running on behalf of the user) attempts to perform an operation on a securable object, the operation being attempted is subject to an access check and is only allowed to succeed if the user performing the operation has been authorized to perform this operation on the object in question.

Discretionary access to securable objects

Provides the ability to specify the users who have access to an object, and to specify the access criteria. Every securable object has an owner. The owner is the only security principal who has an inherent right to allow or deny permission to gain access to an object. The first owner of an object is usually the security principal that is associated with the thread that created the object. An object’s owner can transfer ownership by giving permission to take ownership to another security principal. Additionally, any security principal who has been granted the privilege to take ownership of files or other objects on the computer can take ownership of any object on the computer.

Inheritance of permissions

Allows administrators to easily assign and manage permissions for a large collection of objects. This feature allows administrators to specify permissions that can be applied automatically to all objects contained within a container by having the specified permissions be inherited by all child objects in the container.

Administrative privileges

Allow an administrator of a computer system to control which users have the right to perform various administrative functions, or to take any action that affects system-wide resources. There are two types of administrative privileges – user rights and privileges. User rights control the various ways in which users can log on to a system. Privileges control a user’s ability to perform a specific task, usually one that affects the entire computer system rather than a particular object.

Auditing

Enables the tracking of user or system activity by recording specific (specifiable) types of actions in security logs. Audit data can be used to detect attempts to circumvent protections on resources and to create a record of administrative actions on the computer system.

Low-level operations

As mentioned earlier, every administrative task involves some low-level operation on data. An understanding of the various kinds of low-level operations helps to understand the details of how an administrative task works.

The following are the low-level operations can be performed on data:

• Create an object. This low-level operation involves the creation of a new object in Active Directory. For example, the administrative task of creating a new user account involves a low-level operation of creating an object of class User under some parent object in Active Directory

• View an object or all child objects of a specific object. This low-level operation involves being able to view or see an object in Active Directory. For example, when using one or more Active Directory administration tools, viewing the contents of an OU or a domain involves performing multiple low-level operations (one for each object displayed) to view objects in Active Directory.

• Read object attributes. This low-level operation involves accessing and reading the values of one or more attributes on an Active Directory object. For example, any administrative task involving reading some information on a user (for example, phone number or name) involves a low-level read operation on one or more attributes (also referred to as a property) of the user object representing the user’s account.

• Modify object attributes. This low-level operation involves accessing and modifying the values of one or more attributes on an Active Directory object. For example, any administrative task involving modifying some information on a user object (such as telephone number or office location) involves a low-level modify operation. Changing a user’s password involves performing a low-level modify operation modifying the password attribute of the user object corresponding to the user’s account. Similarly, modifying the association of a subnet to a specific Active Directory logical site involves a low-level operation modifying the siteobject attribute on the objects representing that specific subnet.

• Read the security descriptor of an object. Every securable object is protected by a security descriptor which is stored as an integral part of that object and, for Active Directory objects, is represented by the NTSecurity-Descriptor attribute. The security descriptor contains among other information, a list of access control entries specifying who can perform what low-level operations on an object. Any administrative task involving viewing or changing permissions involves the low-level operation of reading the security descriptor of an object. For example, the administrative task of determining who can modify a group’s membership involves a low-level operation that reads the security-descriptor of the corresponding group object.

  Note

  An administrative task involving changing permissions also involves the low-level operation of modifying the access-control list stored as part of the security descriptor, as described in “Modify the access control list protecting the object” later in this document.

• Modify the access control list protecting the object. The security descriptor contains, among other information, a list of access control entries specifying who can perform what low-level operation on an object. Any administrative task involving viewing or changing permissions involves the low-level operation of reading and modifying the access control list stored in the security descriptor of an object. For example, the administrative task of delegating another administrative task or authorizing a user access to some object involves the low-level operation of reading the security descriptor and modifying the access-control list stored in the security-descriptor of the corresponding object.

• Modify the owner of an object. Every securable object has an owner. The owner of an object has the inherent ability to modify the access control list of the object and to transfer the ownership. The identity of an object’s owner is also stored in the security descriptor of the object. The administrative tasks of taking ownership of an object or transferring ownership of an object involve the low-level operation of modifying the owner of the object.

• Delete an object or delete an entire subtree of objects. This low-level operation involves the deletion of an existing object from Active Directory. For example, the administrative task of deleting an existing user account involves a low-level operation of deleting the user class object representing the user’s account from Active Directory.

Active Directory Permissions and Other Access Rights

Delegating an administrative task involves granting to the delegated administrator the appropriate permissions that are required to perform the low-level operations that the administrative tasks involve. Therefore, understanding the various permissions that control low-level operations is essential to delegating administration.

Active Directory permissions control who can do what on objects in Active Directory. These permissions can be separated into two broad categories – standard permissions and special permissions. Standard permissions control the standard operations that can be performed on objects in Active Directory, such as creating and deleting child objects, or reading and writing the object properties. However, certain Active Directory administrative operations require access to be controlled in a way that is not supported by the standard permissions. To facilitate these operations, Active Directory allows the standard access control mechanism to be extended through special permissions that control specific Active Directory administrative tasks.

In addition to requiring permissions that control low-level operations on Active Directory data, certain administrative tasks involve the ability to perform specific actions on domain controllers (or in some cases on member workstations). User rights can be specified that allow these actions. User rights are different from permissions in that they control the various ways in which a user can log on to a computer. User rights also control the user’s ability to perform specific operations that typically have a system-wide effect.

Standard Permissions

Permissions regulate which users can gain access to an object (an Active Directory object or a file system folder or file) and in what manner.

The following standard permissions control the ability to perform the indicated low-level operations:

• Create Child. The right to create children of the object.

• Delete Child. The right to delete children of the object.

• Delete. The right to delete the object.

• Delete Tree. The right to delete all children of the object, regardless of the permissions on the children.

• Read Permissions. The right to read data from the security descriptor of the object, not including the data in the system access control list (SACL).

• Modify Permissions. The right to modify the discretionary access control list (DACL) in the object security descriptor.

• Modify Owner. The right to assume ownership of the object.

• Read Property. The right to read properties of the object.

• Write Property. The right to write properties on the object.

• List Child. The right to list children of the object.

• List Object. The right to list a particular object. If the user is not granted such a right, and the user does not have List Child set on the object parent, the object is hidden from the user.

  Note

  This right is ignored if the third character of the dSHeuristics attribute of the object has a value of 0 or is not set. For more information about this right, see “Controlling Object Visibility” on the Web at https://go.microsoft.com/fwlink/?LinkID=19828.

• Access System Security. The right to get or set the SACL in the object security descriptor

For a detailed description of the standard Active Directory permissions, see Appendix C: Active Directory Standard Permissions in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Special Permissions

In addition to the standard set of permissions that are applied in the DACLs of Active Directory objects, other permissions are available to accommodate special requirements that are not supported by the standard permissions. These permissions fall into two categories:

• Validated writes

• Extended rights

Validated Writes

Certain administrative operations in Active Directory require that, before writing a value to a property on an Active Directory object, the system perform value checking, or validation, beyond that which is required by the schema. Validated writes are a special type of permission that facilitates the ability to perform validation prior to modifying a property on an Active Directory object. This type of permission ensures that the value that is entered for the property conforms to required semantics, is within a legal range of values, or undergoes some other special checking that would not be performed for a simple low-level write to the property. A validated write is associated with a special permission that is distinct from the Write propertyName permission. The Write propertyName permission allows any value to be written to the property with no value checking.

Extended Rights

Extended rights provide the ability to perform access checks on operations that have some special significance in Active Directory and that are not covered by the standard set of access rights. For example, the User class can be granted a Send As right that can be used by a mail application to determine whether a particular user can allow another user to send mail on his or her behalf. To facilitate these special requirements, Active Directory extends the standard access control mechanism through the controlAccessRight class of objects. These objects are called extended rights.

Instances of the controlAccessRight class are created by the system. These objects are stored in CN=Extended-Rights,CN=Configuration,DC=ForestRootDomain. Rather than being administratively set, properties of these objects automatically identify the type of access in the DACL of the appropriate object.

For a list of all extended rights, see Appendix D: Active Directory Extended Rights in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Property Sets and Extended Rights

Active Directory also uses the controlAccessRight class of objects to represent property sets. A property set is a subset of an object’s properties. For example, the Personal-Information property set includes properties such as street address and telephone number, both of which are properties of user objects. Property sets are useful because they provide the means to specify access to a subset of properties in a single ACE.

Existing documentation about control access rights might seem to suggest that property sets are extended rights or are closely related to extended rights. However, property sets are not related to extended rights in any way other than the fact that they are represented in the system by the same class of objects.

User Rights

User rights are abilities to perform operations on a computer system. User rights apply on every Windows-based computer, independent of Active Directory membership. User rights are essential to service management on domain controllers.

User rights differ from permissions in that permissions control access to individual objects, whereas user rights control the various ways in which users can log on to a system. They also control specific operations that have a system-wide effect on a computer. In the case of user rights on domain controllers, the effect is on Active Directory, and thus on the entire domain.

User rights are set in the local policy on a computer. User rights are set in Domain Controller Security Policy for rights on domain controllers, and in Domain Security Policy for rights on all other computers in the domain. User rights for computers that are joined to the domain can also be specified by using Group Policy linked to OUs. User rights for all domain controllers in a domain are specified in the Default Domain Controllers Policy Group Policy object (GPO), which is applied to the Domain Controllers OU. Thus, all domain controllers in a domain share the same set of user rights assignments.

User rights are of two types:

• Privilege. Specifies a user’s right to perform a specific task, usually one that affects an entire computer system.

• Logon right. Specifies the way in which a user can log on to a system. For example, a user might have the right to log on to a system remotely, but not locally.

Administrators can assign specific rights to security group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories.

User rights define capabilities at the local level. Although user rights can apply to individual user accounts, user rights are best administered to group accounts. Doing so ensures that a user who logs on as a member of a group automatically receives the rights that are associated with that group. By assigning user rights to groups rather than to individual users, you simplify the task of managing user rights assignments.

User rights that are assigned to a group are applied to all members of the group as long as they remain members. If a user is a member of multiple groups, the user’s rights are cumulative, which means that the user has more than one set of rights. The only time that rights assigned to one group might conflict with those assigned to another group is in the case of certain logon rights. In general, user rights that are assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group.

For more information about user rights, see “Appendix C - User Rights and Privileges” in the Microsoft Windows 2000 Security Configuration Guide on the Web at https://go.microsoft.com/fwlink/?LinkID=19829, and “Chapter 4 - User Rights Assignment” in the Threats and Countermeasures Guide on the Web at https://go.microsoft.com/fwlink/?LinkID=19830.

Components of an Access Check

All data that is stored in Active Directory is represented by objects, each of which can be individually or collectively secured. Being secured means that when a user or a process that is running on behalf of the user attempts to perform an operation on an Active Directory object, the security system checks to determine whether the user or process has legitimate access to the requested object before granting the requested access.

The access check takes into account the following:

• Credentials of the security principal that is requesting the operation.

• Authorization data on the target resource, which is stored in the properties of the securable object.

The access check is performed by the local security subsystem of the computer on which the requested resource is stored. The access check compares the user’s security credentials against the authorization data to determine the abilities of the user on the respective object. If the access check determines that the authorization data of the user or process that is requesting the operation includes sufficient permissions to execute the operation, the operation succeeds. If the user has insufficient permissions to execute the operation that is being requested, the operation fails.

Security Principal Credentials

Any entity that can be authenticated by the system is referred to as a security principal. Thus, a security principal could be a user, a computer, or a thread or process that runs in the security context of a user or a computer. A security context is information that describes a particular security principal’s identity and capabilities on the computer. In Windows Server 2003, Windows 2000 Server, and Windows NT, all activities take place in a security context. The security subsystem uses the security context to determine what actions a process and its threads of execution can perform on objects on the computer, and the identity of the responsible security principal.

Security Identifier

A security principal is represented by a Security Identifier (SID), which is a unique value that identifies that security principal. A SID is issued to every security principal when it is created. Security groups are also security principals, and therefore are uniquely identified by a SID. A user security principal can be a member of multiple security groups. Consequently, a user’s credentials include the SIDs of all groups of which the user is a member.

Access Token

A security principal’s security context is represented by an access token. When a security principal logs on to a computer, the security subsystem on that computer authenticates the security principal. After authentication, the security subsystem creates an access token for the security principal. The access token is a data structure that contains the SID for a security principal, SIDs for the groups that the security principal belongs to (with the earlier-noted exception of domain local groups from a different domain), and a list of the security principal’s privileges (also known as user rights) on the local computer. An access token is created for every security principal who logs on locally at the computer’s keyboard, or remotely through a network connection.

The access token provides a security context for the security principal’s actions on the computer to which the security principal is logged on. It is important to note that when a user is logged on to a workstation and requests access to data in Active Directory, a logon session is generated on the domain controller to which the user binds, and a security context is generated for this user on the domain controller. The access token that is created on the domain controller represents the credentials of the user who is accessing Active Directory. Therefore, the information in this access token, not information from the workstation to which the user is logged on, is used by the access check.

For more information about SIDs, see Security Identifiers Technical Reference (https://go.microsoft.com/fwlink/?LinkId=157928). For more information about well-known SIDs, see Appendix B: Default Active Directory Security Groups in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Security Groups

Security groups are security principals that you can use to aggregate users into categories and roles for the purpose of applying access control. Security groups have scopes that define where they can be applied and membership requirements that define the selection of members they can have and the groups of which they can be members. The different types of security groups that are available and whether or not they appear in a user’s access token is subject to the domain mode (Windows 2000) and domain or forest functional level (Windows Server 2003) that is in effect.

Security groups play a key role in delegation of administration. Security groups are used to represent specific instances of administrative roles and contain as members the user accounts of all delegated administrators who have been assigned to the specific administrative role represented by this security group. An understanding of the various types of security groups is thus beneficial in implementing delegation, as the various security group types differ in their scope, applicability, and uses.

There are four types of security groups, differing primarily in their application, scopes, and membership criteria:

• Local groups (also referred to as Built-in groups)

• Domain Local groups

• Global groups

• Universal group

Group Scope

Using security groups effectively for delegation of administration requires a strategy that makes use of the group scopes that are available in Active Directory. The scope of a group identifies the extent (domain or forest) to which the group can be applied:

• Domain local. A single domain; that is, domain local groups are visible for administration in only the domain in which the group is created, and thus can be assigned permissions on objects in only that domain. However, a domain local group can have users and groups from its own domain and other domains as members. For this reason, you can best use domain local groups as resource groups to collect other groups that need the same level of access to a resource. Rather than adding multiple groups to an ACL, add all the groups to one domain local group and add only the domain local group to the ACL for the target object.

  Note

  When specifying read access to specific attributes of, or list access to, an Active Directory domain object, do not use a domain local group to set permissions if the attribute or attributes are included in the partial attribute set that is replicated to global catalog servers. Instead, use a global group.

• Global. All domains in a forest; that is, a global group is visible for administration within its domain and all trusted domains and thus can be assigned permissions on objects in all domains in the forest. Because global groups have forest-wide visibility, they are best used to organize users or groups of users into administrative roles.

• Universal. All domains in a forest; that is, a universal group is visible for administration within its domain and all trusted domains and thus can be assigned permissions on objects in all domains in the forest. When multiple roles require the same access to a resource, add global groups to a single universal group and add the universal group to a domain local group for the resource.

Group Scope Availability and Membership Rules

Group scopes vary according to functional conditions in the domain or forest. Not all scopes are available under all conditions, and group membership is subject to conditions in the domain or forest according to domain modes in Windows 2000 forests and domain functional levels in Windows Server 2003. A domain mode or functional level that indicates “mixed” provides functionality that is consistent with Windows NT 4.0 domain controllers. For this reason, features that are not compatible with Windows NT 4.0 are not available in mixed domains.

The following rules limit the availability of group scopes:

• Domain local groups are always available.

• Global groups are always available.

• Universal groups are not available in:

  • Windows 2000 mixed-mode domains.

  • Windows Server 2003 domains that have a domain functional level of Windows 2000 mixed.

The following rules limit the membership of security groups:

• Domain local groups:

  • Can always contain individual user accounts and global groups from any domain in the forest.

  • Can also contain universal groups from any domain in the forest as well as domain local groups from the same domain in Windows 2000 native-mode domains or Windows Server 2003 domains that have a domain functional level of Windows 2000 native or Windows Server 2003.

• Global groups:

  • Can always contain users from the same domain.

  • Can also contain global groups from the same domain in Windows 2000 native-mode domains or Windows Server 2003 domains that have a domain functional level of Windows 2000 native or Windows Server 2003.

• Universal groups, when available, can always contain user accounts, global groups, and other universal groups from any domain in the forest.

For more information about group scope and membership rules, see Help and Support Center for Windows Server 2003. For a list of the default administrative groups that are created when Active Directory is installed, and their default abilities, see Appendix N: Default Active Directory Service Administrator Groups in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Local Security Groups

Local groups can be used to grant access to local resources on a computer. As such, each computer (workstation, server, or domain controller) that is running a version of Windows has a set of default local group accounts. On domain controllers, these security groups are domain local accounts that are stored in the Builtin container. The domain controller itself does not have local computer groups. On workstations and servers, these accounts are local to the computer only.

SIDs for these default local accounts are always placed in a user’s token, independent of the user’s domain and the computer’s domain. When a computer (workstation or server) is joined to a domain, by default the Domain Admins group is made a member of the Administrators local group on the computer.

Local groups can contain any security principal. One exception is that on domain controllers, Builtin accounts cannot contain domain local groups.

For information about the abilities that are assigned to local groups by default, see Help and Support Center for your version of Windows.

Group Membership Changes and Replication

Delegating administration might involve adding or removing members of large groups. Changing the membership of a large group can result in a significant volume of replication in Windows 2000 forests and in Windows Server 2003 forests that have Windows 2000 domain controllers. The reason for the increase in replication is that group membership is stored in the single, linked, multivalued Members attribute of the group object, and with Windows 2000 forests and domain controllers, the attribute is the smallest value that can be replicated. Therefore, changing the membership of a group results in replication of all group members, not just the changed member value. In addition, changes can be lost if two administrators change the membership of the same group on different domain controllers; only one of the changes can be written to the Active Directory database during the same period of replication latency.

In Windows Server 2003 forests, group replication is improved to eliminate these replication issues, but the improvements have functional level requirements. The improvements are available in Windows Server 2003 forests that have a forest functional level of:

• Windows Server 2003 (all domain controllers are running Windows Server 2003).

  - OR -

• Windows Server 2003 interim (all domain controllers are running either Windows Server 2003 or Windows NT 4.0, but no domain controllers are running Windows 2000).

At these functional levels, the discrete values of linked, multivalued attributes are replicated separately, not the entire attribute. At the Windows 2000 forest functional level in a Windows Server 2003 forest (the default level that accommodates Windows 2000 domain controllers that do not recognize certain new features), or in all Windows 2000 forests, the attribute is still the smallest unit of replication, and updating a large group (greater than 5,000 members) can still result in excessive network bandwidth consumption and lost changes. For this reason, groups that have greater than 5,000 members are not supported in Windows 2000 forests.

For more information about Windows Server 2003 functional levels, see “Enabling Advanced Windows Server 2003 Active Directory Features” in Designing and Deploying Directory and Security Services of the Microsoft® Windows® Server 2003 Deployment Kit (or see “Enabling Advanced Windows Server 2003 Active Directory Features” on the Web at https://go.microsoft.com/fwlink/?LinkId=6937).

Authorization Data on Directory Objects

All objects in Active Directory are securable by means of authorization data that protects the object. This data is stored in the Security Descriptor property of each object.

Security Descriptors

The security descriptor includes owner and group identifiers, as well as two types of access control lists (ACLs):

• Owner. The security identifier (SID) for the current owner of the object. The object owner is usually, but not always, the creator of the object.

• Group. The SID for the owner’s primary group. This component of the security descriptor is not used by Active Directory access control, but is available for Portable Operating System Interface for UNIX (POSIX) compliance only.

• Discretionary access control list (DACL). A list of zero or more access control entries (ACEs) that specify who has what access to the object.

• System access control list (SACL). A list of zero or more access control entries that specify what audits to generate.

Object Owners and Creators

Every securable object has an owner. The owner is the only person who has the inherent right to control who has permission to perform operations on the object and in what way. An object’s owner can grant or deny permission for different kinds of access to particular users or groups of users. An object’s owner can transfer ownership by giving another security principal permission to take ownership.

It is important to understand how the owner of an object is assigned and how ownership can be transferred. The first owner of an object is usually the security principal that is associated with the thread that created the object. When a user makes a request to create a new object in Active Directory, the information in the user’s access token is used by the security subsystem on the domain controller to establish object ownership. The information in the access token is generated by the contacted domain controller. In addition to other information, the access token contains the following information about the user:

• User. A field (Token-user) that contains the SID of the user who is logging on.

• Default object owner. A field (Default-owner-in-token) that contains the SID of the user or security group that becomes the owner of any object that this user creates.

When the access token is created, the user’s SID is inserted into the Default-owner-in-token field unless the user is a member of certain administrative groups. In this case, the SID of the group is inserted into the field and any member of the administrative group can manage the object. If the user is a member of more than one such administrative group, the group with the highest level of authority is the object owner. As the object owner, you cannot change the owner to another user or group; that is, you cannot change the value in the owner field to specify an owner. However, you can apply a user right that allows another user to take ownership.

For more information about how the list of the administrative groups that become default object owners differs in Windows 2000 and Windows Server 2003, see Appendix J: Default Owners of Active Directory Objects in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

DACL

DACLs contain ACEs that identify the security principals that have access to the object. Each ACE has fields that specify the abilities (permissions) for the respective security principal. For each security principal that you add to the access control list, you can define a set of permissions that specify the extent to which that user or group of users can manipulate the object. If a user does not appear in an ACE, either individually or as a member of a group, that user has no access to the object.

SACL

The SACL is similar to the DACL except that it is used to audit rather than control access to an object. When an audited action occurs, the operating system records the event in the security log. Each ACE in a SACL has the following elements: a header that indicates whether auditing is triggered by success, failure, or both; a SID that specifies a particular user or security group to monitor; and an access mask that lists the operations to audit. The content of the SACL is controlled by security administrators for the local computer. Security administrators are users who have been assigned the Manage auditing and security log privilege. By default, this privilege is assigned to the built-in Administrators group.

DACLs and ACEs

For the most part, delegation involves specifying permissions on Active Directory objects in order to authorize delegated users to carry out administrative tasks. As mentioned earlier, these administrative tasks involve low-level operations each of which can be individually authorized. Authorizing a low-level operation involves identifying the object representing the data being targeted in the low-level operation and appropriately modifying permissions in the DACL of the target object’s security descriptor. This authorization is usually expressed in the form of an access control entry (ACE). An understanding of the various aspects of DACLs and ACEs is essential to being able to successfully delegate administration. This section describes DACLs and ACEs in detail.

Where DACLs come from

It is important to understand where the ACEs in a DACL come from. When you create an object in Active Directory programmatically, as the object’s owner you can create and pass in through the API an explicit security descriptor. Permissions are specified in the Security Descriptor Definition Language (SDDL). If you create an explicit security descriptor, the ACEs in the DACL in this security descriptor are merged with any inheritable ACEs that this object would inherit from its parent object’s security descriptor. If you do not specify an explicit security descriptor, a default security descriptor is applied to the new object. Every object class definition in the schema has an attribute called Default-Security-Descriptor. This default security descriptor becomes the security descriptor of the object if an explicit security descriptor is not specified during creation. In this case, the ACEs in the DACL of the default security descriptor are merged with any inheritable ACEs that this object would inherit from its parent object’s security descriptor.

Over the lifetime of the object, it continues to inherit any inheritable ACEs that are present in the DACL of the parent object’s security descriptor. The addition of new inheritable ACEs on the parent object results in the inheritance of these new ACEs by the object. These inherited ACEs might be effective or ineffective, depending on whether the Inherited-object type field is set and to what value. Similarly, the removal of any inheritable ACEs on the parent object or any object from which the parent inherits will result in the removal of that inheritable ACE on this object.

Inheritance enables the access control information that is defined for a container object in Active Directory to apply to any subordinate objects, including other containers and their objects. Inheritance eliminates the need to apply permissions each time a child object is created.

Default Security Descriptor Protection on Service Administrator Accounts

To prevent the security descriptors on the key service administrator accounts in each domain from being modified and possibly becoming unusable, a background process runs on the primary domain controller (PDC) emulator that periodically checks and applies a standard security descriptor on the protected accounts. This process ensures that if a hostile user or other administrator does manage to modify the security descriptor on one of the administrative accounts, the change will be overwritten with the protected settings. This process starts 15 minutes after the system starts, and then runs once every half hour after that. This refresh interval is not configurable.

The following table lists the accounts and all their nested member groups and users that are protected by this process. The list of protected accounts varies in different versions of Windows Server.

Windows 2000 Server Windows 2000 Server with Service Pack 1 (SP1) Windows 2000 Server with Service Pack 2 SP2 Windows 2000 Server with Service Pack 3 (SP3)	Windows 2000 Server with Service Pack 4 (SP4) Windows Server 2003	Windows Server 2003 with SP1 Windows Server 2003 with SP2	Windows Server 2008 Windows Server 2008 R2
Administrators	Account Operators	Account Operators	Account Operators
Domain Admins	Administrator	Administrator	Administrator
Enterprise Admins	Administrators	Administrators	Administrators
Schema Admins	Backup Operators	Backup Operators	Backup Operators
	Cert Publishers	Domain Admins	Domain Admins
	Domain Admins	Domain Controllers	Domain Controllers
	Domain Controllers	Enterprise Admins	Enterprise Admins
	Enterprise Admins	Krbtgt	Krbtgt
	Krbtgt	Print Operators	Print Operators
	Print Operators	Replicator	Read-only Domain Controllers
	Replicator	Schema Admins	Replicator
	Schema Admins	Server Operators	Schema Admins
	Server Operators		Server Operators

The master security descriptor for these accounts is stored as the security descriptor attribute of the AdminSDHolder object, which is located in the system container of the domain directory partition (CN=AdminSDHolder,CN=System,DC=DomainName).

The security descriptor on this object serves two purposes:

• It controls access to the AdminSDHolder object itself.

• It acts as the master security descriptor, which is periodically applied to the service administrator groups and their members to ensure that they remain protected.

For the default settings in the master security descriptor of the AdminSDHolder object, see Appendix K: Default Settings in the Master Security Descriptor of the AdminSDHolder Object in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

If you want to modify the security descriptor on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object so that it will be applied consistently. Care must be taken when making these modifications because you are also changing the default settings that will be applied to all of your protected administrative accounts. For more information about changing the security descriptor on AdminSDHolder, see Understanding AdminSDHolder and Protected Groups at https://go.microsoft.com/fwlink/?LinkId=157927 and see “Changing the Security Descriptor on AdminSDHolder” in “Appendix: Procedures” in the Best Practice Guide for Securing Active Directory Installations: Part I on the Web at https://go.microsoft.com/fwlink/?LinkID=21258.

Order of ACEs in a DACL

The DACL contains a sequential list of ACEs. The order of ACEs in the DACL affects the outcome of the access check. By default, ACLs have a preferred order called the canonical order. Although a DACL can be in a non-canonical order, most UI tools canonicalize the DACL during an operation on the object.

The access check algorithm checks the ACEs in the DACL in sequence. For each permission that is requested by the user, the algorithm stops at the first ACE that allows or denies the requested access. Thus, the outcome of the access check depends on the relative ordering of ACEs within the DACL.

The following is the canonical order of ACEs in a DACL:

• Explicit ACEs precede inherited ACEs

• Within a given set of explicit or inherited ACEs, Deny ACEs precede Allow ACEs

This effect can be summarized by the following canonicalized DACL:

Explicit Deny Ace 1
…
Explicit Deny Ace n
Explicit Allow Ace 1
…
Explicit Allow Ace n
Inherited Deny Ace 1
…
Inherited Deny Ace n
Inherited Allow Ace 1
…
Inherited Allow Ace n

Further, within the set of Deny inherited ACEs and Allow inherited ACEs, inheritable ACEs that are specified on the parent object precede inheritable ACEs that are specified on the parent object’s parent object, and so on upward until reaching the ACEs that are specified on the domain root object. Thus, in the event of a conflict of permissions, permissions specified in an inheritable ACE set on the parent object will override the permissions specified in an inheritable ACE set on an object higher up in the object hierarchy.

A security descriptor might contain no DACL if a security descriptor that is passed in programmatically has no DACL specified, and no ACEs are inherited from the parent object. A security descriptor can also have a DACL that contains no ACEs.

The effect on security of having no DACL as opposed to having a DACL that has no ACEs is significant:

• No DACL in the security descriptor has the effect of granting unconditional access to Everyone.

• An empty DACL has the effect of not granting access to anyone.

In the case of an empty DACL, the owner of the object always has the inherent right to modify the DACL and grant permissions. If no DACL exists, the owner can create a DACL programmatically and then grant permissions.

For more information about using SDDL to specify permissions programmatically, see the Microsoft Platform Software Development Kit (SDK) link on the Web Resources page at https://go.microsoft.com/fwlink/?LinkId=95521.

Protected DACLs

The DACL of an object can be marked as protected. Marking a DACL as protected will block the inheritance of any permissions from the parent object. Any inheritable permissions in the DACL of the parent objects will not be inherited by this object. Additionally, child objects of an object whose DACL is marked protected will also no longer inherit any permissions specified on the protected object’s parent. However, they will continue to inherit all inheritable permissions specified in the DACL of the protected object unless the child objects also have their DACLs marked as protected.

ACEs

An ACE contains authorization intent for a specific security principal for whom access is allowed, denied, or audited.

Every ACE in the DACL has the following structure:

(ACE Type ; ACE Flags ; Permissions ; Object Type ; Inherited Object Type ; Trustee)

The following is a brief description of the various fields of an ACE:

• ACE Type – This field specifies whether the ACE is an Allow type ACE or a DENY type ACE. An ALLOW type ACE allows access and a DENY type denies access.

  This field can take on one of six values:

  • Allow – Indicates that the ACE is of the standard ACCESS ALLOWED type, where the ObjectType and InheritedObjectType fields are NULL.

  • Deny – Indicates that the ACE is of the standard system-audit type, where the ObjectType and InheritedObjectType fields are NULL.

  • System Audit – Indicates that the ACE is of the standard system type, where the ObjectType and InheritedObjectType fields are NULL.

  • Object Allow – Indicates that the ACE grants access to an object or a subobject of the object, such as a property set or property. The ObjectType or InheritedObjectType field or both contain a GUID that identifies a property set, property, extended right, or type of child object.

  • Object Deny – Indicates that the ACE denies access to an object or a subobject of the object, such as a property set or property. The ObjectType or InheritedObjectType field or both contain a GUID that identifies a property set, property, extended right, or type of child object.

  • Object System Audit – Indicates that the ACE audits access to an object or a subobject of the object, such as a property set or property. The ObjectType or InheritedObjectType field or both contain a GUID that identifies a property set, property, extended right, or type of child object.

• ACE Flags – This field contains multiple inheritance related flags that govern the inheritance aspects of the ACE.

  This field can take values including but not limited to one or more of the following:

  • Container Inherit – Child objects will inherit this access-control entry (ACE). The inherited ACE is inheritable unless the ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE flag is set.

  • No Propagate – The system will clear the ADS_ACEFLAG_INHERIT_ACE flag for the inherited ACEs of child objects. This prevents the ACE from being inherited by subsequent generations of objects.

  • Inherit Only – Indicates an inherit-only ACE that does not exercise access control on the object to which it is attached. If this flag is not set, the ACE is an effective ACE that exerts access control on the object to which it is attached.

  • Inherited – Indicates whether or not the ACE was inherited. The system sets this bit.

• Permissions – This field contains the specification of the permissions granted or denied to the trustee (the security principal for whom the permissions specified in this ACE will apply). This field can take one of the following values:

  • RC – Read Control

  • SD – Standard Delete

  • WD – Write DACL

  • WO – Write Owner

  • RP – Read Property

  • WP – Write Property

  • CC – Create Child

  • DC – Delete Child

  • LC – List Child

  • LO – List Object

  • SW – Validated write

  • DT – Delete Tree

  • CR – Extended Right

  For more information about these rights, see Appendix C: Active Directory Standard Permissions in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

• Object Type – This field can contain the GUID representing an object’s class. The GUID refers to a property or a property-set if the permissions specified are Read-Property or Write-Property permissions. The GUID specifies an object class when the permissions specified are Create Child or Delete Child permissions

• Inherited Object Type – This field can contain the GUID of an object class. When such a GUID is set, the ACE is an effective ACE only on objects of the class referred to by the GUID.

• Trustee – This field contains the SID of the security principal for whom the permissions specified in this ACE will apply.

For a detailed description of the various fields of an ACE, see “IADsAccessControlEntry” in the MSDN Library on the Web at https://go.microsoft.com/fwlink/?LinkID=21262.

Example ACEs

The following example ACEs illustrate how ACEs specify delegation intent:

• An ACE that grants Account Admins the ability to create user objects in an OU and in all OUs within the subtree rooted at this OU:

  • (OA ; CI ; CC ; User Class ; Organizational Unit class ; Account Admins)

• An ACE that grants Account Admins the ability to reset user passwords in an OU but only on User objects:

  • (OA ; CI ; CR; Reset Password ; User class ; Account Admins)

• An ACE that grants Account Admins the ability to modify the membership of all group objects (but only group objects) in a specific OU (on which this ACE is being applied). This ACE does not give Account Admins the permission to modify the group memberships of any groups that might exist as child objects of other OUs that might be child objects of the OU on which the ACE is being applied.

  • (OA ; ; WP; Member ; Group class ; Account Admins)

    Note the absence of any inheritance flags in this ACE.

Inheritance and Organizational Units

Active Directory data is stored in containers. While some containers are general purpose containers, other containers have a specialized purpose in that they are specific in the nature of data that they are intended to store. Generic containers are represented by objects of the generic class Container, while specific containers are represented by specific object classes. An example of a generic container would be the Services container in the Configuration partition, which is intended to contain various kinds of objects representing service specific information. An example of a specific class of container is the Sites container in the Configuration partition which is intended to contain site and subnet related information and is represented by an object of class SitesContainer. While different kinds of configuration information can be stored in different kinds of containers, domain data is typically stored in a special purpose class of objects called Organizational Units (OUs).

OUs are special purpose containers in that they are intended to contain domain data like user accounts, computer accounts, and groups. Additionally, OUs can contain other OUs within them. In this manner, domain data is stored within a hierarchy of OUs which serve the role of containers for domain data. OUs are different from other containers in that Group Policy can be applied to them. The application of Group Policy to an OU results in the inheritance of the applied Group Policy by user and computer objects, on which that Group Policy becomes effective subject to the precedence order of the application of Group Policy.

OUs are used to form a hierarchy of special purpose containers within a domain for the purpose of storing user and computer accounts and security groups and applying Group Policy onto a collection of user and computer accounts. Organizations create an OU hierarchy structure based on their Group Policy requirements and collectively store user and computer accounts and groups within specific OUs depending on the Group Policy requirements for these user and computer accounts.

Organizational units also play a major role in delegation of administration. Delegation of administration involves granting an administrative group sufficient permissions to allow the group the ability to perform specific administrative tasks. Usually, administrative authority is delegated to manage a set of users. While it is possible to grant an administrative group permissions on the specific user accounts that belong to a set of users, individually modifying the DACL of every single user account in a set is usually unmanageable and impractical. To simplify the application of the permissions required to delegate authority and control access, the inheritance feature of Active Directory enables the application of inheritable permissions on objects.

Instead of having to explicitly specify permissions in the DACL of every managed object, administrators can simply specify the same permission on an OU or any object that contains one ore more objects and mark the specified permissions as inheritable. The inheritance feature of Active Directory will take any permission specified as inheritable and propagate them down to all child objects within the container on which the permission was applied and to all child objects of any container objects within the subtree rooted at the container object on which the inheritable ACE was applied.

Since domain information is typically stored in OUs, inheritable permissions are typically applied on OU objects, and inheritance takes care of propagating all inheritable permissions down to all objects in the subtree rooted at the OU on which these inheritable permissions were applied.

Organizations should take into account two primary requirements when designing their OU structures:

• Group Policy application requirements

• Delegation of Administration requirements

When Active Directory is installed, only one OU, Domain Controlers, is automatically created. Domain Controllers is the default container for new domain controllers.

In addition, a number of other containers are automatically created, two of which, Computers and Users, are of interest from the perspective of domain data storage:

• Computers represents the default storage area for new computer objects that were originally created through legacy APIs that are not Active Directory–aware.

• Users represents the default storage area for new user accounts that are created through legacy APIs that are not Active Directory–aware.

By default, when computers are joined to the domain, the computer accounts for these computers are created in the Computers container. Because these two containers are not OUs, Group Policy cannot be applied to them.

Thus, after the deployment of Active Directory, an organization must typically create an OU structure to store domain data including user and computer accounts and groups. When designing an OU structure, organizations must take into account Group Policy application requirements and requirements around delegation of administration.

For best practices and design considerations for creating an effective OU structure, see Chapter 4: Delegating Data Management.