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
"I need more circuits in this room," I told him.
"Oh, computers don't draw that much electricity," Bob the electrician
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
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
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
- 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
- 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
- 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.
only (Effective ACL).
subfolders and files.
and all child objects
folder and files.
object is specified.
and files only.
only (Inherit ACLs).
A comparison of NTFS and AD Inheritance Choices
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
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
descriptor information (doesn't include
the right to read the SACL).
in object's security descriptor.
ownership of object.
of synchronization. A thread (the small
executable portion of a process) can
wait until the object is in the signaled
||Get or Set
descriptor, examine object and children
and read all properties.
and write DACL. Add and remove object
delete children, delete subtree, Read
and Write properties, examine children
and object, add and remove object from
directory, Read or Write with extended
(the ACE can specify child object type
that can be created. If it doesn't,
this right allows creation of all child
(the ACE can specify the child object
type that can be deleted. If it doesn't,
this right allows deletion of all child
membership of group object.
of object (ACE can specify property
that can be read. If it doesn't, this
right allows reading of all properties).
(ACE can specify property that can be
written. If it doesn't, this right allows
writing of all properties).
children of object, regardless of permission
||List a particular
object (if not granted to a user, the
object is hidden from user).
||Right to perform
operation covered by an extended access
right-either a specific extended right
or by omission all extended rights.
Additional standard access rights not available
on all objects. The list and descriptions
come from the Platform SDK documentation.
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
- Without credentials (i.e. using the context of the user that runs
- 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
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!
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
What do you think happens when a user or group has
explicit Allow permission to Delete All Child Objects
on a parent container, yet an ACE on a child object
explicitly sets the Deny Delete permission for the same
user or group?
If you said that the explicit
Deny on the object would take
precedence, you'd be wrong.
Unlike NTFS permissions, in
which the file DACL overrides
the parent folder DACL, certain
parent-set permissions, such
as Delete All Child Objects
and Delete Subtree, will override
the child setting.
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.)
DACL vs. Missing DACL
|Most of us common
folk modify the security descriptor
by setting those elements through
the GUI interface—the Security
Property page of the Active Directory
object—much like we manipulate
file and folder permissions. Whether
they're building AD-enabled applications
to perform some useful corporate
function or maliciously break
into your network, programmers
use the AD Services Interface
(ADSI) or Win32 security APIs
to establish security settings
on new objects or modify existing
ones writing AD-enabled applications.
This means they can do such things
as create an object without a
DACL or take advantage of some
An object without a DACL is
different than one with an empty
DACL. Empty DACLs implicitly
deny access to an object. However,
if no DACL exists, then there's
no restriction on access to
the object. In other words,
everyone has Full Control.
This is an interesting situation,
and one I'd not want to discover
in my AD. If you're responsible
for coding directory-enabled
apps or able to influence those
that do, please explain the
concept to them—especially
the part on how undesirable
it is to allow everyone Full
Control of any object. Good
references on DACLs and this
interesting anomaly can be found
online at http://msdn.microsoft.com/
or in Chapter 9 of the AD
Programmers Guide, part
of the five-volume AD Developer's
Reference Library from Microsoft
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
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
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
- 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
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
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.