Chapter 11. Active Directory Security: Permissions and Auditing

Permissions can be set in Active Directory in the same way they are set for files. While you may not care that everyone in the tree can read all your users' phone numbers, you may want to store more sensitive information and restrict that access. Reading is not the only problem, of course. You also have create, modify, and delete privileges to worry about, and the last thing you need is a disgruntled or clever employee finding a way to delete all the users in an Organizational Unit. And inheritance increases the complexity in the typical way.

None of this should be new to system managers who already deal with Windows NT Access Control Lists and Access Masks, IntraNetWare's Trustee Lists and Inherited Rights Masks, and Unix's access permissions in file masks. In fact, Microsoft has carried the NT terminology from file permissions forward to Active Directory, so if you already know these terms, you're well ahead. If you are not familiar with them, don't worry. Microsoft has a great tradition of calling a shovel a ground-insertion-earth-management device. Terminology in permissions can seem confusing at first, so we'll go through it all in detail.

Managing the permissions in Active Directory doesn't have to be a headache. You can design sensible permissions schemes using guidelines on inheritance and complexity that will allow you to have a much easier time as a systems administrator. The GUI that Microsoft provides is fairly good for simple tasks but more cumbersome for complex multiple permissions. In Windows Server 2003, the GUI has been enhanced to provide an "effective permissions" option that lets you determine the effective permissions a user group has on the container or object. Also, Active Directory permissions are supported by ADSI, which opens up a whole raft of opportunities for you to use scripts to track problems and manipulate access simply and effectively. Finally, the DSACLS utility allows administrators to manage permissions from a command line if you prefer an alternative to the GUI

Yet permissions are only half the story. If you allow a user to modify details of every user in a specific branch below a certain Organizational Unit, you can monitor the creations, deletions, and changes to objects and properties within that branch using auditing entries. In fact, you can monitor any aspect of modification to Active Directory using auditing. The system keeps track of logging the auditing events and you can then periodically check them or use a script or third-party tool to alert you quickly to any problems.

Figure 11-1 shows the basics. Each object stores a value called a Security Descriptor, or SD, that holds all the information describing the security for that object. Included with the information are two important collections called Access Control Lists, or ACLs, which hold the relevant permissions. The first ACL, called the System-Audit ACL or SACL, defines the permission events that will trigger both success and failure audit messages. The second, called the Discretionary ACL or DACL, defines the permissions that users have to the object, its properties, and its children. Each of the two ACLs holds a collection of Access Control Entries, or ACEs, that correspond to individual audit or permission entries.

Figure 11-1. Active Directory security architecture

ACEs can apply to the object as a whole or to the individual properties of the object. This allows an administrator to control not just which users can see an object, but what properties those users can see. An object is never revealed to users who do not have the permission to see the object. For example, all users might be granted read access to the telephone number and email properties for all other users, but Security Descriptors of users might be denied to all but members of a specially created security administrators group. Individual users might be granted write access to personal properties such as the telephone numbers and mailing addresses on their own user objects. The possibilities are limited only by the objects and their corresponding properties in the tree. The Active Directory schema is extensible, so organization-specific permissions can be allowed and denied for all the objects and properties your organization creates.

Deny permissions always override allow permissions.

Auditing takes place when the system logs an event in the security event log on a particular DC to indicate that an Active Directory event has taken place. You can monitor the creation, modification, or deletion of any object in Active Directory. This can, of course, be useful for maintaining records of security problems, as well as in dealing with unusual behavior by the system.