This document is intended for administrators who need to know Active Directory security works. For more in-depth information, we strongly recommend the book Inside Active Directory by Kouti and Seitsonen. Chapter 4 covers security extremely well, and the rest of the entire book is without equal. You will come to consider this book a priceless addition to your library.
Quick Overview
Active Directory security is totally different from NT4 SAM security. Active Directory supports several new security concepts including ACL inheritance, atomic (or special) permissions, extended right sets (sets of many attributes), and changes much of the default behavior and rights given to common administrative accounts. Additionally, the tools used to perform administration are all completely new, and in many cases hide critical information from you-supposedly for your benefit. Many of the assumptions you might approach AD with will be wrong, and if you are unfamiliar with the concepts and don’t know the gotchas you will be left scratching your head.
We have heard information from Microsoft that Windows .NET Server 2003 will further change the security features to include dynamic authorization. This will mean that access control will be even more complicated, while allowing more flexibility in design. Before the security model gets more complicated, however, you should make efforts to understand the new features that Windows 2000 has introduced.
This document attempts to explain the basic security concepts that Active Directory employs, with an emphasis on what is new and changed from NT4 domain security. This is not an introduction to Windows security, and you are expected to understand basic Windows NT terminology and concepts.
Windows Security Concepts
From a high-level perspective, Windows only supports static access control. This means that the authorization information is statically assigned to the resource, and this static information is used to determine whether access is granted. Windows uses an attribute called the nTSecurityDescriptor to hold this static access control information. This access control information is commonly called an access control list (ACL), that is comprised of multiple entries called access control entries (ACE). An ACE is usually comprised of two pieces of information: the identity given (or denied) access, and the level of access given (or denied).
Windows supports two types of ACLs. The discretionary access control list (DACL) is used to determine access control, just like we’ve been discussing-usually when someone talks about “the ACL” they usually are referring to the DACL. The system access control list (SACL) is used to determine what access should be audited, if auditing is turned on. In addition to these two types of ACLs, Windows also supports the notion of ownership of the object. The owner has hard-coded rights to the object that don’t have to be explicitly granted in the SACL. The owner, SACL, and DACL are all statically held in the nTSecurityDescriptor attribute of each object.
As noted above, future versions of Windows will surely expand the access control model to include dynamic access control. Dynamic access control means that whether access is granted is determined at the time of access based on information that could be dynamically changing right up to the point of access. In other words, the identity placed in the DACL will not refer to a specific account or group, but rather to an open-ended statement that must be computed at the time of access. Many other operating systems and directories support the idea of dynamic access control.
Windows does actually support dynamic access control in a very limited fashion. There are several pre-defined groups and accounts commonly known as Well-Known SIDs. Many of these groups and accounts do not have an explicit mapping to a specific account or a specific list of membership. For example, the group Authenticated Users corresponds to all the users that the forest trusts. There is no membership list maintained for this group. Instead at the time of access, there is a calculation whether the requestor matches the hard-coded qualifications for this group. There are several important well-known SIDs that are extremely useful as listed in the table below.
| Well-known | SIDPurpose |
|---|---|
| Authenticated Users | Any principal (process, computer or user) the forest trusts that has been authenticated. |
| Creator Owner | The user entry that creates a new entry. This can be set on a container as a placeholder for new entries subordinate to the container. EveryoneAny access whether it has authenticated or not. |
| Interactive | Any principal that has authenticated to the same local computer as the resource. |
| Network | Any principal that has authenticated at a different computer than the resource. |
| Self | A placeholder for the entry itself. This can be set on a container to give every subordinate entry access to itself. |
Permissions
Active Directory supports three standard permissions: Read, Write, and Full Control. You should be familiar with these permissions already. Every object in AD has these standard permissions available. Some objects, depending on their object class, may have other standard permissions. However, AD goes beyond these standard permissions to define what it calls special permissions. These are 13 special permissions that are available for every object in AD. Each of the standard permissions maps to a set of these special permissions. I think of the special permissions as incremental or atomic permissions, and the standard permissions as default sets of these incremental permissions. Whether you see standard or special permissions will depend on the combination of the incremental permissions and the GUI view used. The table below lists all 13 of the special permissions, and designates the combinations that map to the standard permissions.
| Incremental Permission | Read Access Set | Write Access Set | Full Control Set | Description |
|---|---|---|---|---|
| All Validated Writes | X | X | The ability to perform any write to this object, subject to the syntax restrictions of that attribute. | |
| All Extended Rights | X | Equal to all extended rights. Extended rights are explained later in this document | ||
| Create All Child Objects | X | The ability to create any child object under this object. | ||
| Delete | X | The ability to delete this object. Child objects under this object may be orphaned. | ||
| Delete All Child Objects | X | The ability to delete immediate child objects of this object. | ||
| Delete Subtree | X | The ability to delete everything under this object. Also requires Delete permission on parent object. | ||
| List Object** | *** | X | The ability to view the name of this object. This permission is not enabled in AD by default, and also is hidden in all GUI tools by default. * | |
| List Contents | X | X | The ability to view the name of all the immediate child objects of this object. | |
| Modify Owner | X | The ability to take ownership of this object. | ||
| Modify Permissions | X | The ability to change the ACLs of this object. | ||
| Read All Properties | X | X | The ability to read all attributes of this object, except the owner and DACL. | |
| Read Permissions | X | X | The ability to read the owner and DACL of this object. | |
| Write All Properties | X | X | The ability to write to all attributes of this object, except the owner and DACL. |
* To enable AD to use List Object permission, you must modify cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=YourDomainStringHere. The dSHeuristics attribute should have a value “001” to enable this permission. The third character controls the list object functionality, and by default the attribute is set to “0” with no second or third character. A value of “1” in the first character will disable ANR (Ambiguous Name Resolution–see chapter 8 of Inside Active Directory) functionality. I don’t know what the second character controls.
** To effectively use list object, you give list object to the container, you give list object to the child object(s) you want viewed. You make sure you don’t give list contents to the container. If list contents is given at the container level, you can remove it and explicitly give list object instead to each of the objects OR you can block inheritance at the child object. But blocking inheritance has side-effects that we will discuss shortly. The container must have the list object permissions given or the user won’t be able to view the child object.
***In pre-release candidates of Windows 2000, read corresponds to 4 incremental permissions–including list object. In the released version, it only corresponds to 3–not including list object. However, several of the default ACLs for object classes are still based on the old definition of read, and include list object. This is one of the many mistakes we’ve seen in the design of the product–and you just have to be aware of it.
In addition to the incremental and standard permissions, there are a few other kinds of permissions. Extended rights allow read or write permission to a set of pre-defined attributes. We’ll discuss this in the extended rights section. Each object class also has special permissions that are specific to entries of that object class. For example, the user object class has several permissions unique to user entries. These include:
| User permissions | Description |
|---|---|
| Change Password | Allows the password of a user object to be changed. In order to successfully use this permission you must enter the old password as verification. |
| Reset Password | Allows someone other than the user to reset the password of that user object. Knowledge of the previous password is not required. Send AsAllows someone other than the user to send email from that user’s mailbox. |
| Receive As | Allows someone other than the user to read email from that user’s mailbox. |
Inherited Permissions
Inherited permissions are when an ACL set on a container (parent object) also apply to the child objects below that container. All entries below that container inherit the ACL set on the parent. This functionality is incredibly useful, but there are many implications to the way Microsoft implemented this feature that should be understood.
Inheritance in AD is static inheritance as opposed to dynamic inheritance. With static inheritance, the inherited ACL is copied to each of the objects below it. With dynamic inheritance, a change is never copied to subordinate objects. But with dynamic inheritance, when a user tries to access an object, the ACL of that object and every parent container must be checked.
There are implications to the fact that AD uses static inheritance. For example, setting an inherited ACL on a container that contains LOTS of objects below it, can take a long time to apply. This is aggravated by the fact that this change must be replicated to all the other domain controllers (and possibly global catalog servers). When an inherited ACL is changed, only the change to the container object’s ACL is replicated. When the other domain controllers get this change, they then copy the inherited ACL to all the child objects as well. Understanding how this works is important, because one should understand the reasons why access to directory objects via one DC might differ from access via another DC. The combination of replication plus copying the inherited ACL might take quite a bit of time to occur, so the window of inconsistency is more pronounced.
Inheritance can be blocked by any child object. Understanding the implications of this are also critically important. If you are trying to allow or restrict access to a set of directory objects, but you have delegated the Modify Permissions permission, your ability to use inheritance to manage access is severely limited. At the child object, one can choose to not allow any inherited ACLs to apply to the child object (and if that child is a container, you would also be blocking inheritance to all the subsequent children). When one chooses to block the inheritance, you are presented with the choice to remove the inherited ACL or to copy the ACL so it is an explicit ACL. In either case, all changes or additions to inherited ACLs from objects above that object will be ignored. Even worse is there is no way to easily re-establish inheritance from the top down. NTFS5, however, does allow re-establishment of inheritance. This is a confusing and limiting design decision, and hopefully Microsoft will change this decision in the future.
Inheritance can also be overridden by any child object. Again if the Modify Permissions permission has been delegated, then you can get in trouble. Fortunately, the implications of this are limited to deny ACEs. Specifically, when you set an inherited deny ACE, it can be overridden by an explicit allow ACE at a child object. When access is determined, the security reference monitor (SRM) evaluates the ACL by comparing each ACE in the ACL to the credentials presented by the user. Generally speaking, you’ve probably heard that a Deny ACE overrides an allow ACE, but this isn’t entirely correct. In an ACL, ACEs are placed in a special order. As soon as a match is made, further evaluation of later ACEs is ignored. So the order of ACEs is critical. The order of ACEs is as follows:
- Noninherited Deny entries.
- Noninherited Allow entries.
- Inherited Deny entries.
- Inherited Allow entries.
So a non-inherited allow ACE is matched prior to an inherited deny, and someone could be given access that you wouldn’t expect, if you went by NT4 assumptions. For this reason, it is generally not good practice to use inherited deny ACEs.
Quiz time:
You set the ACL on the GSB OU to give access to Administrators:Full Control, as well as GSB Admins:Full Control. On Fred’s user account within that OU, you deselect the “Allow inheritable permissions from parent to propagate to this object” checkbox. You are prompted to copy or remove the inherited permissions, and you choose to copy the permissions. On Wilma’s user account within that OU, you leave inheritance alone, but add a non-inherited ACE which allows Administrators:Full Control, even though that group already has access via inheritance. Later, you decide to change the ACL on the GSB OU because you are suspicious of the members of the Administrators group. You remove Administrators: Full control from the inheritable permissions on the OU. You also place an inherited permission of Deny Administrators: Full control on the GSB OU. Can Administrators access any of the objects within the GSB OU and if so, which objects? Explain.
The answer is at the bottom of this document.
Ownership
When someone creates a new object, their account is listed as the owner of that object. An owner has built-in hard-coded rights to their object that are equal to Full Access, so they don’t necessarily need access explicitly given in the DACL. Owners can also delegate ownership to another account. That other account can then take ownership, and have full access to the object.
Attributes (sometimes called Properties)
While attributes themselves are not a security feature or concept, they do deserve a little attention. One can set permissions on an object, on an object class, or on extended rights (which are sets of attributes) or on attributes. However, the GUI view of attributes in the ACLs is intentionally limited by Microsoft. For example, a user has 200+ possible attributes with the default schema. But you can only view and set ACLs on about 60 of these by default via the GUI tools. Fortunately, this behavior is configurable. Every client has a file located at c:\winnt\system32\dssec.dat that controls this behavior. This file contains about 12000 lines of text, and is therefore difficult to modify. If you’d like to modify the file yourself, here’s what you need to know: The file is organized by object class. Each object class is surrounded by brackets. The possible attributes for each object class are listed in each section. Each attribute is followed by a setting that corresponds to the GUI behavior for that attribute. If the attribute is not listed under the object class, then the attribute will be displayed. The possible settings are:
| =0 | Include both Read for that attribute and Write for that attribute. |
| =5 | Only Write for that attribute is included. |
| =6 | Only Read for that attribute is included. |
| =7 | Don’t include that attribute. |
Finally, you’ll notice that some object classes have a @=7 at the beginning of the class. This controls visibility of the object class itself for ACLs in the GUI. The same values are appropriate here.
Extended Rights or Property Sets or Attribute Sets
Attribute sets are commonly defined sets of attributes that can be used in an ACL to indicate the entire set of attributes. By default, there are 10 attribute sets predefined by Microsoft. You can see a mapping of the default attribute sets here. In addition to these default attribute sets, you can define your own. However, there is a serious limitation: any given attribute can only belong to a single attribute set. Another limitation exacerbates the problem: you can’t change which attributes belong to the default attribute sets. Since almost all the default attributes belong to an attribute set, you are extremely limited in creating new ones. Microsoft is aware this is a serious limitation, but has indicated that no changes will happen until two OS revisions in the future. Too bad.
Attribute sets are useful though. They provide an easier way to define ACLs to large sets of attributes. In most cases, the default attribute sets group similar attributes together in a reasonable fashion. This helps make them more useful.
Microsoft confusingly calls this concept “extended rights”. Every object class (type of object, e.g. a user object is one object class and a security group is another object class) can have extended rights defined for it. We’ve only been talking about the extended rights for users. To further exacerbate the confusion associated with the name of this concept, extended rights also mean something else entirely. Read on …
Although we haven’t introduced them in this document, user rights are a common Windows concept. In order to log into your workstation, your account must have the “log on locally” user right on your workstation. With Windows 2000, you can also define new extended rights that correspond to special actions. Microsoft also calls these custom user rights extended rights. For example, there are several extended rights associated with user objects: change password, reset password, receive as, and send as. We mentioned these earlier in this document. In total, there are 39 extended rights defined by default. The Inside Active Directory book lists these on page 228-229.
For our purposes, we’ll use the term extended rights to only mean the definition involving special user rights. The sets of attributes will be called attribute sets (or property sets).
GUI View of Permissions
Whether you see standard or special permissions will depend on the combination of the incremental permissions and the GUI view used. There are 4 different GUI dialogue boxes that can be used to view the DACL of an object. Each of these dialogue boxes specializes in displaying the DACL in a different perspective, but there is some overlap between each of the dialogue boxes.
Permissions are usually displayed in all the GUI dialogues in two columns: Allow or Deny. Explicit ACEs are displayed with a clear box that is either checked or unchecked. Inherited ACEs are shown with a gray box that is either checked or unchecked.
Dialogue B doesn’t follow these conventions. Instead it lists whether the ACE is allow or deny, and displays a special phrase if the ACE is inherited.
Dialogue A
The initial dialog box (which for the purposes of reference I’ll call dialogue A) can be accessed by opening the properties of an object, and selecting the Security tab. Dialogue A only shows the standard permissions, and only shows the DACL of the object. If the DACL of the object has a combination of incremental permissions that add up to one of the standard sets, then they will be displayed clearly. If the incremental permissions don’t add up to any of the standard sets, then the ACE shown will appear empty. This can be highly misleading if you don’t understand that what appears to be an empty ACE really does have incremental permissions below the surface. There is a clue that more permissions are set but not shown. When you select an ACE that has permissions that don’t map to the standard permissions, a small phrase will appear in the dialogue box: “Additional permissions are present but not viewable here. Press advanced to see them.”
You can add or remove ACEs via dialogue A, but not edit existing ACEs. Adding an ACE via dialogue A limits your choices of permissions to the standard sets. In addition to showing the standard view of ACLs, dialogue A also displays whether DACL inheritance is being blocked from parent containers or not. In my opinion, this is the only useful information in dialogue A, but this information can be found elsewhere. Because dialogue A can lead to misunderstanding and there is no information exclusive to it, I personally don’t spend much time looking at dialogue A, and proceed directly to the next dialog box.
Dialogue B
The second dialogue box (which we’ll call dialogue B) is accessed by selecting the Advanced button on dialogue A. Dialogue B shows the DACL, SACL and ownership on separate tabs called Permissions, Auditing, and Owner respectively. On the DACL tab of Dialogue B, whether DACL inheritance is being blocked from parent containers or not is listed. Dialogue B gives you three choices in terms of the DACL. You can add an ACE, remove an ACE or view/edit an existing ACE. Clicking the view/edit button leads to the next level (dialogue C). The number of entries shown in dialogue B correspond the total number of ACEs. Dialogue B similarly gives you the same choices for the SACL. Inheritance of the SACL is separate from the DACL inheritance, and changes in the DACL tab of dialogue B or dialogue A will not affect the setting here. The owner tab of dialogue B displays the existing owner. In addition, if your account has the permission to Take Ownership of this object, then your account will be shown as a possibility under “Change owner to”. You can take ownership by selecting your account and choosing Apply or OK.
Dialogue C
Clicking the view/edit button on either the SACL or DACL tab leads to dialogue C. Note that dialogue C shows a very detailed view of only a single ACE (whichever one was selected when you hit the view/edit button)-and not any other portion of the ACL. Dialogue C has two tabs: Object and Properties. The two tabs determine what view you see of the SACL ACE or DACL ACE.The Object tab shows the 13 incremental permissions, the 39 extended rights, and the ability to create or delete objects of a specific object class. The Property tab shows read/write permissions for individual attributes or attribute sets. Generally speaking, you’ll use the Object tab far more often than the Property tab. But you should keep both in mind.
If you do a great deal of security coding or close configuration of workstation security settings, you’ll want a firm grasp of the Security Descriptor Definition Language (SDDL). Unfortunately, Microsoft has done us no favors in describing SDDL. I’ve cobbled together the pieces of several disparate Microsoft documents on the SDDL syntax in a single coherent document here.
Answer to Inheritance Quiz:
There are several important factors here that complicate this question. One is inheritance, another is order of ACEs within the ACL, and still another is the rights (hard-coded or explicit) that certain security principals have. We’ll assume that none of the members of the Administrators group are also members of the Domain Admins group. Given that, the answer is that Administrators would have no access to objects under the GSB OU, except for both Wilma AND Fred. Why them?
Fred first. Fred’s account isn’t participating in inheritance anymore. So any inherited changes above his account will never affect him, until his account is configured to allow inheritance again. You can *NOT* re-establish inheritance from the top-down. So don’t simply change the inherited ACL on the OU, and expect it to apply to every object beneath. You will also need to hunt down all the exceptions.
On Wilma’s account, the non-inherited allow ACE is matched prior to the inherited deny, and administrators would be given access.
Finally, the person thinking outside the box might think … the Administrators group is all powerful … by default they can just take ownership of anything and have access. So they still have access to it all if they want. *Not true*. The Administrators group does *not* have the take ownership right hard-coded (meaning written into the OS code where it can’t be changed by an inept administrator) nor explicitly by default for directory objects. Domain Admins do have this right both explicitly and hard-coded, as well as Enterprise Admins. Administrators are excluded from several other hard-coded rights in the directory. This is a change from NT4 to AD, and should be noted.
Re-used with permission from Stanford University for which Brian Arkills originally wrote this documentation, http://windows.stanford.edu/Public/Security/ADSecurityOverview.htm