Active Directory Object Permissions 101

Understanding the ins and outs of AD and object permissions is no simple task, but your efforts can help avoid catastrophe.

• By Roberta Bragg
• October 01, 2001

"I need more circuits in this room," I told him.

"Oh, computers don't draw that much electricity," Bob the electrician said.

I think he just didn't want to poke wires through the walls of my early 20th-century house or figure out which fuse goes where on either of my two electrical boxes. So Bob left, and the orange extension cords still snake around my house like a mad spider web to support my 30-some system network.

The plumbing in my house isn't any better, either. Every winter my plumber and I discover some new pipe that, when it thaws, spews ice-cold water into the basement, across the bathroom or down my driveway at midnight. It's not that he's a bad plumber; it's just that this house was built before indoor plumbing was all the rage. Quite frankly, there are days I wish they hadn't added it—or at least that they hadn't hidden all my pipes inside drop-down ceilings, remodeled plaster walls, and nooks and crannies that no one's been in for years. If you want an idea, run the 4-G Pipes screensaver. If you could remove the walls and ceilings in my house, it'd look like that.

In both cases, someone who didn't really know the ins and outs of household infrastructure was saddled with the job of "just getting it done." Either the information wasn't available to them, they figured they knew enough already or they just didn't care. The end result is the same. Rest assured, before I tackle any repairs or additions on my own, I'll do some research into the wiring and plumbing information database.

Understanding and maintaining this stuff is sort of like the job you have implementing and maintaining Active Directory in your enterprise. You gotta know what you're doing (and what others have done) if you're going to do the job correctly and avoid floods and fireworks down the road. However, the information isn't always available or easily locatable when it comes to the internal details.

Oh, there's a wealth of documentation on AD out there, but a lot of it is duplication, doesn't go far enough or is scattered as if shot randomly about by my .22. It's quite difficult to find the ultimate guide. What we may have to do is use the old divide-and-conquer routine: Separate the universe into manageable chunks, pick a chunk and research the hell out of it. Then we keep working on it and document the results whenever we can add something new. If we all did this and shared the results with each other—well, need I say more? Here's a contribution then: A short guide to AD object permissions.

Raison du Jour?
The reason we need to understand AD object permissions seems obvious. Object permission settings allow the control of access to the object. If I don't want every Tom, Dick and Mary to be able to obtain a recovery agent certificate for Encrypting File System (EFS), I set object permissions on the certificate template object to allow only approved recovery agents to obtain the certificate. If I do want the help desk group to be able to reset passwords for users in the respective Organizational Units (OUs) they manage, I use object permissions on the OU to do so. From determining whether users can change their own addresses to who can write a Group Policy Object (GPO), object permissions are critical to the smooth functioning and protection of your enterprise. Set them correctly, and most folks won't even know they exist. Muck it up and, at best, you'll have trouble making things work. (What's worse? Well, improper object permissions will allow unwanted access to critical objects. Can you spell, "H-A-C-K-E-D"?)

How Permissions Work
In our haste to implement Windows 2000, many of us are like the apprentice handyman or do-it-yourselfer. We've got a job to do, by-gummy. Like the non-existent map of my wiring and plumbing, documentation on what each AD permission means isn't so easy to find. So we descend the steps to the basement, brush apart the cobwebs, knock off a little plaster and risk a little electrical shock or a bath in ancient effluents to make headway. A safer plan, however, would be to learn the basics of wiring and the pluses and minuses of ohms and amps before our curiosity turns us into charcoal. Object permissions don't work on electrical currents or underwater pressure—Ohm's law won't apply. Instead, each object follows the Windows NT/Win2K access-control model. The model requires that you understand four basic concepts.

First, there's the security principal: Any object within the AD that can be assigned privileges and access control rights or permissions (Access control rights or permissions control access to securable objects). Computers, Services, Users and Groups are security principals.

Second, there's security context. When there's an attempt at accessing an object, the application provides the credentials of a security principal, usually whoever started the application. These credentials determine the security context—the list of group memberships and the privileges (privileges control rights to perform system tasks) and SID of the security principal.

Third is the security descriptor. Each directory object contains security information in a structure called a security descriptor. This can contain the following:

• A Discretionary Access Control List (DACL), which comprises Access Control Entries (ACEs) that indicate which users and groups have been explicitly allowed or denied a specific type of access to the object. The ACE may specify which operations they can perform and whether or not they can create child objects or define private or extended access rights.
• A SID to identify the owner of the object. Ownership, by the way, implies the right to modify the DACL.
• A System Access Control List (SACL), which identifies the types of actions that generate an audit log entry. The ACEs in this list indicate a user or group, the type of access attempted, and whether success or failure or both will generate the audit.
• Security_Description_Control provides the control flags that qualify the meaning of the security descriptor or its components.
• A set of SE_DACL_PROTECTED flags, which can be used to protect a security descriptor DACL from inheriting ACEs from its parent.
• A SID to identify the primary group of the object. Current documentation states that the primary group isn't used by AD.

The security descriptor exists whether or not we, as administrators, take any action. Where does the security descriptor come from? A security descriptor may be:

• Inherited from the parent container. (Inheritance is discussed shortly, under "Who Gets What.")
• Provided by the definition of the object. During dcpromo, a default security descriptor is provided for each object class. (An object class can be thought of as a conceptual view of an object someone wants to store in the directory. It's defined in the schema.) AD-enabled applications may add additional object classes to the schema and should provide their own default security descriptor for each object class they create.
• Programmatically created and attached to the object at the time of creation. A class is just a definition of what an object can be. The default security descriptor is part of the definition. When an object is created, it may be given an explicit security descriptor.
• Replaced during execution of some program. As administrators, we use utilities through the GUI to add ACEs to the object's DACL or SACL and to modify inheritance. We also use the Delegation of Authority Wizard or modify the ACE of a Group Policy Object (GPO) to filter its application to users and computers within its Group Policy Container (GPC). In addition, third-party tools and administrative scripts can be used to manage settings.

Fourth in the access control model is access check. Access is granted to the object only if the security descriptor grants the rights requested to the security principal (or groups of which he or she is a member) attempting to use them.

How Rights are Evaluated
Two types of rights exist: permissions (authorization to do something such as read or reset a password on a specific object) and privileges or user rights (authorization to do something, like log on or add users, that affects an entire computer rather than a specific object). Similar to the evaluation of file system access control, the right to access or use AD objects is determined by the security context attached to the application that attempts the access.

When users authenticate to a system, the authorization information (their SID, SIDs of groups they belong to, and privileges) they've been given is collected and later used to create an access token. The access token is used when they attempt to gain access to some object. Programmatically, an access token can be created using the security context of some other security principal, say, the operating system, and used instead during the applications processing. When the application requires the use of some file system, operating system or AD object, the information in its access token is compared with that in the security descriptor of the object. If a match occurs, and no explicit Deny permission exists, access is granted. If no match occurs, or the explicit Deny exists, the requested access is denied.

Seems pretty simple doesn't it? It does, unless you understand that an AD-enabled application has choices in how it identifies itself in its actions with AD to the operating system. When the program is written, its author may choose to have it "bind" or connect to AD in one of the following ways:

• Explicitly by hard coding and, therefore, specifying a username and password.
• Without credentials (i.e. using the context of the user that runs the application).
• By impersonating a user.
• If LDAP is used, binding without authentication—in which case, the group Everyone's security context is used.

With any luck, the application is written using choice two or three. One, of course, is vulnerable to attack. Placing usernames and passwords within code is never a good idea. Choice four exposes access to where rights have been given to the group Everyone.

Is This Just Like NTFS Permissions?
Because the same security model is used to control access to objects in AD that's used to control access to files and folders, don't we know all there is to know? At first glance, object permissions in AD appear to model that interface. There's a security tab on each object's property box, a window that allows us to select Allow or Deny permissions, and an Advanced button to modify more closely what can be done by whom. Inheritance can be regulated, and there's an array of functions that determines exactly how permission settings affect child objects. Sounds like NTFS—but wait! Here's where your knowledge of NTFS gets in the way of understanding AD permissions.

NTFS settings are well documented and limited to a comprehendible number of possibilities. While a new inheritance model and the ability to either Allow or explicitly Deny any setting have complicated file system object permissions in Win2K, you can reasonably expect to get your arms around them. The list of AD object permissions, however, goes on forever. Think about it. The file system has two basic types of objects—folders and files. Permission types vary slightly for each object, as there are only two objects. While you can create new files and new folders, you can't create new file system object types. On the other hand, new object types for AD can and will be introduced to your enterprise. Your AD, therefore, is composed of an infinite number of object types—each of which can have unique access control settings.

Inheritance is different, too. Like NTFS, inheritance for AD objects can be specified by object type; but, once again, for NTFS that's rather limited. For AD, a rather large array of objects may be allowed within a container. In addition, there's at least one surprising difference in the way child and parent object permissions interact (See "Zing! Got Ya!").

Let's peel apart these distinctions and talk about them a little more.

Who Gets What
The rules of inheritance define how permissions set on an object affect child objects. While not all AD object classes can have children, many can. OUs can contain Users, Computers, other OUs and Printers. For AD objects, like NTFS folders, two conditions need to be considered: Is inheritance allowed and how will settings be inherited? You may block inheritance by clearing the Access Control Settings Permissions page box "Allow inheritable permissions from parent to propagate to this object" or by programmatically setting the SE_DACL_PROTECTED security descriptor control flag. This setting prevents inheritable permissions from parent objects.

To control inheritance, you set the specific type you desire for each ACE. To do so, use the Advanced button on the Security Properties page to expose the special permission page, select the ACE desired, and click on View/Edit to access the Object Permissions Entry page. The "Apply onto" drop-down box can then be used. Your choices are similar to those available for setting inheritance for NTFS (Table 1). You can set permissions on the following:

• Only on the current object. No changes will be made to child objects.
• Only on its child objects. The ACE won't be applied to the container or parent object, but is only present so it may be inherited.
• On the object and all of its children. Both parent and child have the ACE applied.
• On any child object class. If an object class can be in the container, you can restrict permission settings only to this type of object. For example, the ability to control users and not computers may be given to our help desk group.

How Many Permissions Are There?
When first initialized AD appears to have about a gazillion built-in object classes. Each object class may be controlled with standard access control rights and potential extended access control rights (possibly unique to its class). It also has the potential for additional unique object permissions. Like NTFS rights, each AD access control right may be composed of multiple special permissions. In addition, each object may have multiple properties, and distinct access control permissions may be set on each property. This is roughly comparable to a situation in which you could allow someone to write only certain information to a file object in the file system. To make matters even more convoluted, not all object permissions are exposed in the GUI. They're available programmatically, and there are ways of exposing them. Each new AD-enabled application added to the forest may extend the schema and, hence, the range of possible access control rights. (Take a look at access permissions and extended rights after installing Microsoft Exchange, for example.)

To the neophyte administrator, this combination of vast possibilities is enormously awe-inspiring and confusing. Heck, to experienced administrators and others who've spent some time studying AD, its object permissions are enormously awe-inspiring and confusing. Ask Microsoft for a reference to find each setting described and you'll probably get the answer, "Have you checked TechNet?" (Please note that no such comprehensive resource exists on TechNet or anywhere else as far as I can tell—at least as of this writing—and may never exist.)

While it's impossible to document what doesn't yet exist and equally impossible in one small article to describe the umpteen-million, plain-vanilla AD object permissions, there's a lot I can do to get you started.

We have two areas to explore:

• Standard access rights, or basic predefined settings that exist for all AD objects.
• Extended access rights, predefined settings that uniquely exist for certain AD object classes and the ability to define new extended access rights.

Of course, any creation of new AD object classes—such as those provided by an installation of Exchange 2000 or other AD-enabled application—can add new, uniquely defined settings for these new classes.

Standard Access Rights
Open the security page for any AD object and you should see the following standard object access rights or permissions:

• Full Control. Can do it all.
• Read. Can read the properties of the object.
• Write. Can modify the properties of the object.
• Create All Child Objects. This permission is necessary on the object type of the parent container. A security principal, could, for example, have the right to create users, but not computers within a given OU.
• Delete All Child Objects. This permission is necessary on the object type of the parent container. See "Zing! Got Ya!" for an interesting lesson.

These standard permissions are fairly straightforward. One exception is the intended functioning of Write when you attempt to modify several properties of the object and don't have Write permission on all the properties. (For instance, the GUI might let you select modifications to the address, home phone number and manager for user Bob even if you only have Write permission for address and home phone number. In this case, however, none of the properties will be changed.) One caveat: If you attempt the same thing programmatically and haven't applied Service Pack 1, you'll succeed. Worse yet, an audit record would show the attempt as failed! Microsoft Security Bulletin (MS00-026) and Knowledge Base Q259401, "Active Directory Objects May Be Modified Programmatically," explain the problem.

Additional standard access rights not available on all objects are listed in Table 2. The list and descriptions come from the Platform SDK documentation. (The Platform SDK or software development kit is composed of documentation, tools, APIs and code samples provided to assist in the development of applications for Windows platforms.)

Extended Control Access Rights
Extended control access rights are of three types:

• Extended rights, or specific rights on objects, aren't listed in the standard access control rights. Each user, for example, has the "change password" right on his or her user object. The "reset password" right may be given over a set of user objects contained in an OU. Each object class in the AD may have specific extended rights. The Enterprise Administrator Group would have the Add GUID extended right.
• Property rights, or the ability to control access to a subset of rights. By modifying one setting, you can control a number of rights. For example, the Personal Information property set controls access to things like street address and phone number. In fact, the default security descriptor setting for the User object in the schema allows each user access to modify Personal Information items. Knowledge Base Q292304, "How to Prevent Windows 2000 Users from Changing Personal Detail Information," explains this, as well as how to modify the schema if you don't want users to be able to change their personal information. (You'll want to modify the schema default to ensure that each new user created can't modify his or her information.)
• Validated rights, which require the system to do additional checking (beyond schema requirements) of values (perhaps to determine if a value is within a certain range or some other restriction) before writing the value of a property to a DS object.

Figure 1. You can identify the control access rights available in your forest via the Extended Rights container in the configuration partition. (Click image to view larger version.)

If you wish to identify which control access rights are available in your forest, they're listed in the Extended Rights container of the configuration partition. The list will be composed of standard extended control access rights defined during dcpromo and additional extended control access rights defined during schema modification. You can explore this container by loading the Win2K support tools and firing up ADSI Edit (Figure 1). (Warning! You can get yourself in a lot of trouble using ADSI Edit. Don't modify things here until you know exactly what you're doing. And even then, if the setting can be changed elsewhere, do it there. Think of this like you do regedt32—an awesome tool in the right hands, a potential disaster in the hands of the careless.)

I haven't found any documentation that details which object classes these rights are available on, nor which lists. Likewise, I've seen no documentation for what each extended right means. Some extended rights are defined somewhere in the vast documentation available on Microsoft's Web site and within published articles, books and white papers. Others appear to be obvious from their name. Open an object's Security Property page to see which extended rights are added to the standard rights. Remember that each standard right and extended right may be composed of multiple special permissions. Use the Advanced button to expose the ACL editor to list these special permissions.

Delegation of Control
No discussion of permission settings and AD objects would be complete without mentioning the Delegation of Control Wizard. As you know, you can use it instead of setting individual permissions. The interface is fairly straightforward and allows you to set things like allowing a less-than-full administrator to reset passwords or create new users within a specific OU.

The delegation wizard simplifies setting permissions on AD objects. That's all. However, it does have an advantage over you directly addressing permission settings on the object—especially in a virgin forest (some directory-enabled applications will expose more of the available permission settings for you). It knows more of what's available and allows you to set some things that aren't exposed in the GUI. Without it, or some manipulation of the interface, you couldn't get the job done. Once the permission is set, it does appear in the GUI. To modify it, simply open the object's security pages, find the setting and remove or change it. There's no wizard that will help you do this.