When I create a new user object, its ACL includes not only the permissions that the object inherits from its parent organizational unit (OU) but also other permissions that are defined as explicit access control entries (ACEs). Where are the default permissions for Active Directory (AD) objects defined?
Each AD class has a defaultSecurityDescriptor attribute, which defines ACEs that Windows 2000 Server automatically adds as explicit permissions to an instance of a class when the class is created. To view a class's defaultSecurityDescriptor attribute, you must first enable schema changes on the domain controller (DC) that serves in the forest's Schema Master role. To enable schema changes, open regedt32 and navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry subkey and set the Schema Update Allowed REG_DWORD value to 1 (create the value if it doesn't exist). Remember that schema changes are forestwide and mistakes made when editing the schema can wreak havoc on your domain.
After enabling schema changes, open the Microsoft Management Console (MMC) ADSI Edit snap-in and connect to the Schema Master DC. (The ADSI Edit snap-in is available in the Microsoft Windows 2000 Server Resource Kit.) Double-click the Schema partition and work your way down the details pane to the User class, as Figure 1 shows. Double-click the User class to open the User Properties window. In the Select a property to view drop-down list, select defaultSecurityDescriptor, as Figure 2 shows. The Value(s) field contains the default explicit ACEs for new user objects. The ACEs are represented in Security Descriptor Definition Language (SDDL). To easily examine these ACEs, I copied the contents of the Value(s) field and added line breaks after each entry. Figure 3 shows the field contents, one entry per line.
The ACE begins with a token. The D: token specifies that the subsequent lines are discretionary ACEs. (For information about other tokens that denote owner, primary group, and system ACL—SACL, see "Security Descriptor String Format" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/security_descriptor_string_format.asp.) Each subsequent entry, called an ACE string in SDDL, appears within parentheses and specifies an ACE.
The entry at callout A in Figure 3 gives Full Control to the Domain Admins group. Semicolons delimit each field of the ACE string. The first field, called the ace_type string, specifies whether the ACE is specific to the entire object or to a certain property on that object and whether the ACE allows or denies the access rights string that follows. In the first ACE string in the figure, the ace_type value A specifies an allow-type ACE that applies to the entire object. (For information about other ACE field values, see "ACE Strings" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/ace_strings.asp.)
The next field, which is blank in the example, specifies any ACE flags that control inheritance. The third field, called the rights string, specifies the access rights that the ACE allows or denies. The value RPWPCRCCDCLCLORCWOWDSDDTSW in Figure 3 specifies all access rights; these rights appear as Full Control when you view an object's permissions. The access rights string comprises one or more two-letter abbreviations for various access rights. For example, the abbreviation RP specifies Read Property and, because it's in an object-level ACE rather than a property-level ACE, means Read All Properties.
The next two fields, which are blank in the example, define object globally unique identifiers (GUIDs), which I explain later. The final field in the first entry (DA), the SID string, identifies the ACE's trustee or the group or user account to which the ACE grants or denies access. SDDL uses two-letter abbreviations for common or well-known SIDs such as built-in groups, SYSTEM, and NETWORK. (For more details and a list of SID string constants, see "SID Strings" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/security/sid_strings.asp.) For users or groups for which no abbreviation is available, such as a user or group you created, you can use that object's SID. The DA SID string in the first entry in Figure 3 identifies Domain Admins.
The entries at callout B grant SYSTEM (SY) and Account Operators (AO) full control, respectively. The entry at callout C grants the user (the PS in the SID string field stands for Principal Self) Read All Properties, List Contents, and Read Permissions.
In the entry at callout D, the OA ace_type string specifies that this ACE is specific to a particular property of user accounts. To determine which property the ACE applies to, look at the fourth field, which is the object_guid field. The combination of the CR access right and this object_guid value (i.e., ab721a53-1e2f-11d0-9819-00aa0040529b) specifies Change Password. By virtue of the PS SID string at the end of the entry, this ACE lets users change their password.
The two ACEs at callout E give the user Send As and Receive As rights to his or her account. For more information about these rights, see the Microsoft article "XADM: How to Grant a User 'Send As' Rights in Exchange Server 5.5 and Exchange 2000" (http://support.microsoft.com/?kbid=281208).
The entry at callout F shows three more property-level ACEs that grant Read/Write access to three property sets. Property sets provide a way to group several properties together so that you can grant or deny access to them as a group. In this case, the property sets (which are specified in the object_guid field) are Personal Information, Web Information, and Phone and Mail Options, which Figure 4 shows. (For a description of property sets and their members, see "Property Sets" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adschema/ad/win2k3only_entry_controlaccessrights_propertyset.asp.)
The four OA ace_type strings at callout G grant Read Property access to the RAS and IAS Servers group to four other property sets—Remote Access Information, Account Restrictions, Logon Information, and Group Membership. The entry at callout H grants Read Permissions access to Authenticated Users.
Surprisingly, the ACE at callout I grants Change Password access to Everyone. However, that right isn't as permissive as it appears. AD's Change Password operation lets you change an account's password only if you know the current password. (In contrast, the Reset Password operation lets Administrators and Account Operators change passwords without knowing the current password.) Consequently, this ACE does nothing more than let a user change his or her password, just as the fifth entry, which grants Change Password authority to Principal Self, does. I don't know why Microsoft added this ACE to the default permissions.
The entry at callout J grants Read/Write permissions over the userCertificate authority to the Cert Publishers group. This ACE lets Enterprise Certificate Authorities in the domain publish certificates on corresponding user accounts.
All other permissions on a user account come from the account's parent objects. By default, the domain root propagates Full Control to Enterprise Admins, Full Control minus a few rights to Administrators, and Read access to the Pre-Windows 2000 Compatible Access Group.
