Securing Active Directory Objects and Attributes

In Active Directory, all attributes of all objects and the objects themselves have permissions that can be defined when the object is created or after it has been created. You must be able to examine these permissions and secure them according to your organization s security policy. This is especially true if your organization is planning on extending the Active Directory Schema to include additional attributes or objects.

You can secure Active Directory objects at their creation globally for all newly created objects of a given object class by modifying the default security descriptor for the object class in the schema. You can also secure objects after their creation by creating an object-specific ACE on the parent container that the object will be created in or by configuring the DACL on the object directly.

The method used to build a DACL for a new Active Directory object differs slightly from the method used to build DACLs for other object types. Two key differences exist. First, when building a DACL for a new Active Directory object, each object class defined in the schema has a default DACL that is applied to all objects when they are created. Second, the rules for creating a DACL distinguish between generic inheritable ACEs and object-specific inheritable ACEs in the parent object s security descriptor. Generic inheritable ACEs can be inherited by all types of child objects. Object-specific inheritable ACEs can be inherited only by the type of child object to which they apply. Other objects that have DACLs, such as files, do not have object-specific ACEs.

Configuring Default DACLs on Objects and Attributes

You can configure the default DACL on object classes by modifying the schema. To modify the schema, you must be a member of the Schema Admins security group and the schema FSMO must be marked as writeable. To configure a default DACL on an object class, perform the following steps:

Open a blank MMC from the command prompt by typing MMC.
Add the Active Directory Schema MMC snap-in to the blank MMC.
Right-click the object class that you want to modify. Then select Properties and click the Security tab of the object class.
Configure the default DACL and close the open windows.

The schema partition of Active Directory will need to fully replicate throughout the forest before all new objects will receive the new default security as defined on the default DACL.

Figure 4-5 shows a custom security group named Security Managers being granted Full Control permissions over all new user objects in the forest. Because a single schema exists for the entire forest, the DACL that you modify will be applied to all new objects of that object class created in any domain in the forest. Consequently, if you are assigning permissions to a new security group rather than modifying the existing permissions, you should use universal groups to ensure that the permissions are applicable throughout the Active Directory forest. You can then make the appropriate global groups members of the universal group.

figure 4-5 adding a security group to an object class default dacl

Figure 4-5. Adding a security group to an object class default DACL

The new default DACL only applies to new objects. Existing objects of the object class that you have modified the default DACL of will not be affected. The change will affect only objects created after the schema has replicated to the domain controller where the new object is created. Settings in the default DACL remain with the object even if they are moved to a different container.

Securing Objects After Being Created

Setting the default DACL on an object class is an effective way to configure the security of Active Directory objects during their creation because the change is forestwide in scope and affects only newly created objects. However, you might want to configure an object-specific ACE on the parent object, such as an OU. The object-specific ACE will be applied to the object when the object is created or when objects are moved into the parent object. For example, rather than assigning the Security Managers security group full control of all newly created user objects in the forest, you might want to only grant them full control over all user objects in an OU. You can do this by editing the DACL for the organizational unit. The following steps explain how to do this:

Open Active Directory Users and Computers.
Right-click the OU, click Properties, and select the Security tab.
Click the Advanced button.
Click Add and add the appropriate security groups to the DACL. Then click OK.
In the Apply Onto drop-down box, ensure that the correct object class is chosen.
Configure the new access that you are granting or denying.
Close all windows.

You must enable the Advanced view in Active Directory Users and Computers to expose the Security tab on objects.

Figure 4-6 shows the creation of an object-specific ACE granting full control over user objects to the Security Managers custom security group.

figure 4-6 adding an object-specific ace to an ou

Figure 4-6. Adding an object-specific ACE to an OU

When adding an object-specific ACE to an OU, the OU (or any other type of parent object) will propagate the immediate inheritance of the permissions to all objects of that object class in the OU and in all child OUs. Similarly, when objects of that object class are moved into the OU, the permissions will be inherited by the object. If the object-specific ACEs are removed from the OU, the permissions will be immediately removed from the objects of that object class in the OU and all child OUs. If an object of that object class is moved to a new parent container, the ACE will be removed from the object.

Active Directory not only enables you to configure security on objects but also to configure security on individual properties. Setting security on properties entails the same process as setting permissions on objects.

Configuring DACLs from the Command Line

Although configuring DACLs by using the MMC is convenient, you might want to set permissions from the command line. In Windows 2000, you can do this in one of two ways: though Active Directory Services Interface (ADSI) scripts, or by using the Support Tools utility Dsacls.exe. You can install Support Tools from the Windows 2000 Server CD, from the Support\Tools directory.

Writing custom ADSI programs is beyond the scope of this book. The MSDN Library provides detailed information on controlling access to objects in Active Directory using ADSI at http://msdn.microsoft.com/library/en-us/netdir/ad/controlling_access_to_ active_directory_objects.asp.

Dsacls.exe is the command-line equivalent of the Security tab in the Properties dialog box for an Active Directory object in Active Directory tools, such as Active Directory Users and Computers. You can display all permissions on a given object in Active Directory by typing dsacls ou=sales.dc=woodgrovebank,dc=com . Another convenient feature of Dsacls.exe is its ability to reset the security on an object or set of objects to the default DACL of the object s object class in the schema. To reset the security on an object, type dsacls ou=sales.dc=woodgrovebank,dc=com /S. This is a common use of Dsacls.exe in a test environment when evaluating changing permissions on Active Directory objects. The complete syntax of Dsacls.exe can be referenced in the Support Tools Help file.

Another important tool for managing DACLs on Active Directory objects is Acldiag.exe, which you can also obtain from Support Tools. Acldiag.exe enables you to do the following:

Compare the current DACL on the object against the default DACL on the object s class. For example, typing acldiag cn=jobrown,ou=sales,dc=woodgrovebank,dc=com /schema would compare the DACL of the user object Jo Brown to the default DACL on the object class user.
Determine the effective permissions that a user or group has to an object. Typing acldiag cn=jobrown,ou=sales,dc=woodgrovebank,dc=com /geteffective:* would retrieve the effective permissions for the user object Jo Brown and all the properties of the object and then print them to the console.
Export the permissions to a comma-delimited or tab-delimited file. By using the switches /cdo or /tdo at the end of an Acldiag command, you can format the output in comma-delimited or tab-delimited format. This is especially useful if you want to import the permissions into a spreadsheet or database.

You can direct the output of any command-line program to a text file or local printer by using the standard redirector in the operating system. To direct the output to a file, append the command string with >filename. To direct the output to a local printer, append the command string with >lpt1. For example, acldiag cn=jobrown,ou=sales,dc=woodgrovebank,dc=com /geteffective:* /cdo >joDACL.csv will compile the effective permissions for all users on the user object Jo Brown on a comma-separated file named JoDACL.csv.