Each permission ACE is made up of several pieces of information:

Every permission granted in Active Directory is based on these ACE structures. Objects and properties are only revealed to users who have the appropriate permissions on those objects. Any attribute that doesn’t have an ACE specifically granting the requested access to a trustee is implicitly denied. The security descriptor also allows an administrator to specifically deny access with a deny ACE, but this isn’t needed unless you are attempting to override another more generic ACE that is granting access.

This permission mechanism allows different users or groups of users to have completely different and very granular access to an object. For example, all users might be granted read access to the telephone number and email properties, but only a subset will have access to modify the description.

Microsoft has introduced several new “tools” that are not present in the NTFS ACLs. These tools are called property sets, validated writes, and extended rights. Instead of inserting the schemaIDGUID into the Object Type field of an ACE, you can insert the rightsGuid attribute of the property set, validated write, or extended right object. These objects are all stored in the cn=extended-rights subcontainer of the Configuration container.

Property sets are collections of attributes that can be referenced in a single permission ACE. The big win here is that you could assign one ACE to an SD and have it grant access to 5, 10, 20, or more attributes. The savings in SD size should be immediately obvious: a single ACE that can substitute for 20 different ACEs is a good data reduction ratio. There are several predefined property sets in a default forest; some of these are Personal Information, Public Information, Web Information, and Account Restrictions. You can also add your own property sets as desired. Exchange adds a number of property sets to ease delegation, including Exchange-Personal-Information and Exchange-Information.

While property sets are a great boon for securing the directory in a manner that is simpler than could otherwise have been achieved, the implementation does suffer a major shortcoming. An attribute can only be part of a single property set. Unfortunately, many of the base schema attributes are already included in existing property sets; while most of these can be successfully removed from those property sets or moved to other property sets, you can never be sure doing so won’t break some application. It is generally much safer to stick to managing property sets comprised of your own custom attributes that you add to the directory.

Validated writes are writes that go through additional verification. You cannot modify the validated writes, nor create your own; what comes with AD is what you get. The only validated writes that are currently defined are:

Extended rights are the mechanism used to delegate special operations such as password changes or password resets. While you can add additional extended rights to the directory, you cannot create extended rights that are enforced by the directory. Any new extended rights that you create will simply be additional permissions that can control an application you write that knows how to use the permissions. Your primary use of these extended rights will generally be to delegate to admins the right to set passwords on user objects with the Reset Password extended right.

Many Windows administrators are used to quoting the mantra, “Deny overrides everything.” Fortunately (or maybe unfortunately, depending on what you are trying to accomplish), Active Directory ACLs are a little more complicated than that. You need to specifically be aware of inherited versus explicit permissions. Explicit permissions are permissions that are directly applied to an object. Inherited permissions are permissions that are applied at some level of the tree above the object and “flow down” to the object and its children. When working with inherited and explicit permissions on an object, a deny doesn’t necessarily override a grant.

The rules for what access will result from a set of inherited and explicit ACEs are easiest to understand when taken in steps:

Most simply, the closest ACEs to an object will dictate the access for that object. If you use an inherited deny to prevent access to some attribute on objects in an OU and the deny isn’t effective, look for inherited grant permissions applied further down the branch or for explicit grant permissions applied on the objects themselves.

Every object defined in the schema has the attribute defaultSecurityDescriptor. This attribute is the Security Descriptor Definition Language (SDDL) format of the object’s default SD. It will be applied to any object created without an SD specified during the object creation. These default permissions are rather extensive in Active Directory and are composed entirely of explicit ACEs, so that they override any inherited denies (this tends to make denying access to specific attributes a little more challenging than it probably should be). The DACL defined by the default security descriptor for the user object is listed in Table 16-2.

You can see from Table 16-2 that in a default Active Directory installation members of the Authenticated Users group have access to quite a bit of information. There is even more information available if you have added Authenticated Users to the Pre-Windows 2000 Compatible Access group, as this allows them to see all properties of groups, users, and inetOrgPerson objects. Open access to this information is a sore spot for many companies who don’t want employees to have quite that much information available to them; maybe they want to restrict access to employee phone numbers, or addresses, or other personal information.

Removing the ability to see this information can be difficult to accomplish, especially for the items granted through explicit property set ACEs. In addition, any modification you make needs to be thoroughly tested to verify it doesn’t break any of your line of business applications. Microsoft Exchange is particularly sensitive to permission lockdowns, and if you take away the Authenticated Users group’s access to some attributes, you may need to re-grant the permissions back to the Exchange servers. ADSI is another common tool that is very sensitive to changes to the default permissions. You may find ADSI calls fail with inexplicable errors if assumed permissions have been removed.

Once you have decided to proceed with the lockdown, your next step is to decide how to accomplish it. The “how” and the resulting workload and impact depend entirely on the attribute in question and how the access is being granted.

By far, the simplest case is when the access is granted through inheritance. You can either remove the inherited grant if it is just the one attribute, or add an inherited deny for the attribute or attributes you want protected. An example of an inherited permission you may want to remove is read access to the employeeID property. Authenticated Users are granted read access to employeeID through an ACE applied to the root of the domain that grants the Pre-Windows 2000 Compatible Access group permission to read all properties of users. Inserting an inheritable deny read ACE on the root of the domain or other container for Authenticated Users will effectively block the inherited grant read access to this attribute. Read access can be re-added further down the tree beneath the deny ACE if desired, with either an additional explicit or inherited grant read access ACE.

If the access is granted through an explicit ACE, locking down is considerably more involved and may actually be so difficult it isn’t feasible. There are several mechanisms available for locking down explicitly granted access:

After five years of customers wrestling with the directory lockdown difficulties previously outlined, Microsoft added a feature called “confidential attributes.” As part of this feature, a new searchFlags bit called the confidentiality bit was added. This is bit 7, which has the value 128. When the bit is enabled, the attribute is considered to be confidential. Only users with both Read Property permission and Control Access permission for the attribute on an object can view the attribute. This means anyone with Full Control or All Extended Rights (Control Access for object) or Control Access for the specific attribute. Assuming default permissions, this means access would be granted to:

As you can see, this would appear to give us a great new solution to the issues mentioned previously with explicit permissions. In theory, you can simply mark any troublesome attributes as confidential, and normal users will no longer be able to see them. This is a great plan, but there is still a challenge: you cannot set the confidentiality bit on Category 1 attributes, which are more generically known as base-schema attributes. So, many of the attributes companies may be trying to lock down can’t be locked down with this capability.

Unfortunately, there is not an easy mechanism to grant the Control Access right with a GUI tool. The best available tool is LDP. The ACL editor in ADUC and ADSI Edit only supports granting Control Access over all the attributes of an object (via the All Extended Rights permission), not just a single attribute. For more information on managing ACLs with LDP, refer to Chapter 20.

A common problem Active Directory administrators have faced is when an object or an entire OU tree is accidentally deleted. Usually this happens because of a careless mistake made with the Active Directory Users and Computers tool. The ensuing recovery process often involves authoritative restores and business downtime. Newer versions of ADUC include a checkbox in the MMC called “Protect object from accidental deletion.” Behind the scenes, this checkbox simply adds an ACE to the ACL for the object it is applied to and prevents deletion. Consequently, this will prevent a tree from being deleted, since its parent cannot be deleted. In order to delete that object or tree, the administrator must first uncheck the checkbox or remove the ACE manually.

In order to see the “Protect object from accidental deletion” checkbox, you must first select View→Advanced Features in ADUC. Once you have done this, you can right-click an object in the directory and select Properties, and then access the Object tab. Figure 16-2 shows the People OU being protected in ADUC, and Figure 16-3 shows the People OU being protected with ADAC.

Figure 16-2. Protecting the People OU with ADUC

Figure 16-3. Protecting the People OU with ADAC

If you try to delete an object that is protected from accidental deletion, you will receive an error similar to the one in Figure 16-4. In order to delete the object, you must go back into the properties and uncheck the “Protect object from accidental deletion” (“Protect from accidental deletion” in ADAC) checkbox.

Figure 16-4. Error message when trying to delete a protected object

Figure 16-5 shows the ACE that was added to the ACL for the People OU in order to protect it. Notice that the well-known Everyone security principal has been denied the rights to delete the object or the subtree.

Figure 16-5. ACE created by protecting the People OU

In Figure 16-7, you may have noticed the “Restore defaults” button at the bottom of the screen. This button allows you to revert the current permission set to the defaults, as defined in the schema for the objectClass of the object. If you click “Restore defaults” for an object on which you have not modified the permissions, you may notice that the list still changes. If you look more closely, you’ll see that the inherited permissions were the ones removed. That is because inherited permissions are not defined as part of the default security of an object. Even if you then click OK to apply the permissions, as long as the “Disable inheritance” button isn’t pressed, the inherited permissions will still apply. Having the ability to apply the default permissions is a useful feature, especially for administrators who are trying to determine what changes have been made from the default installation.

The Effective Access (or Effective Permissions in some versions of Windows) tab is available from an object’s Advanced Security Settings screen (accessible in ADUC by viewing the object’s properties, selecting the Security tab, and clicking the Advanced button). This screen allows you to select a user or group and determine its effective (or actual) access to the object, taking into account group membership and permission inheritance. Figure 16-10 shows the effective permissions for Authenticated Users on the People OU object. As you can see, Authenticated Users have List Contents, Read All Properties, and Read Permissions rights. All objects in the forest will inherit these permissions unless inheritance has been blocked. As you might guess, this is a significant feature that allows for much easier troubleshooting of permission problems. There are some limitations to be aware of, however.

Figure 16-10. Viewing the effective permissions for Authenticated Users on the People OU object

The Effective Permissions tool provides only an approximation of the actual permissions a user or group has and does not take into account many of the well-known security principals, such as Anonymous Logon and Network. Another potential issue to be mindful of is that the user running the Effective Permissions tool must have the rights to read the group membership of the target user or group. By default, the Authenticated Users has group this right.

To help with delegating permissions for objects in Active Directory, Active Directory Users and Computers comes with a Wizard called the Delegation of Control wizard. It is intended to allow administrators to delegate management of certain types of objects to key individuals or groups in the organization. It is activated by right-clicking almost any container in the tree and selecting the wizard from the pop-up menu. Builtin and LostAndFound are the two containers for which it does not work by default.

The wizard is useful only when you need to clearly apply general allow permissions to one or more object types below a container. It is not useful if you want to specify deny permissions (which it doesn’t support), remove previously delegated control, delegate control over individual objects, or apply special permissions to branches of the tree. The wizard’s great strength is its ability to set permissions and apply them to multiple users and groups at the same time. We use the wizard to set these sorts of permissions, although much less regularly than we do the standard GUI, since it is much more limited in what it can do. Scripting with ADSI also provides a solution here that is more adaptive to an administrator’s own needs.

The wizard provides several screens for you to navigate through. The first is the welcome screen, which tells you what the wizard does. The second is an object picker for you to select which users or groups to delegate to. The third screen asks what task you wish to delegate control for in that container. Figure 16-11 shows this window.

Figure 16-11. Delegation of Control wizard—task selection

The default is to delegate control for a specific task, and there are several to choose from. Since the list scrolled off the screen in Figure 16-11, we’ll list them here:

If you choose the Custom radio button and click Next, an extra page opens, allowing you to specify individual objects. Figure 16-12 shows this.

Figure 16-12. Delegation of Control wizard—choosing objects to delegate

If you want to delegate certain permissions to computer or user objects in a specific container or branch, you can do it from here. The next screen of the wizard allows you to specify what permissions you wish to assign for the selected users/groups. Figure 16-13 shows this screen.

Figure 16-13. Delegation of Control wizard—access rights selection

When the window opens initially, only the first checkbox is checked. As you click each of the other boxes, the list of specific permissions that you can delegate becomes very large as it encompasses all of the permissions that you could potentially delegate. Finally, the last screen of the wizard summarizes the previous answers and allows the user to go back, cancel, or finish and grant the permissions.

However, just as the permissions listed in the security properties for an object (Figure 16-6) can change, so can the permissions listed in the access rights box, depending on the object(s) to which permissions are being applied. A good demonstration of this is to open up the security properties for any user and scroll through the displayed list of permissions. Next, open up the wizard on any container and select “Create a custom task to delegate” (see the screen shown in Figure 16-11) and only user objects (see Figure 16-12). The screen shown in Figure 16-13 should then display the same list of permissions that the screen in Figure 16-6 does. This makes sense—available permissions for one user should be the same as the available permissions for all users—but is still nice to see the correlation in the flesh, so to speak.

This list of rules is not exhaustive; we are sure you will be able to think of others. If, however, these rules spark your creative juices and help you design more effectively, they will have done their job.

The rules are:

Let’s look at these rules in more detail.

There are a number of Active Directory Users and Computers permission sets that administrators may need to implement in their organizations. Some examples are:

While we could go through each of these cases and show how to design permissions for each, every organization is different. For that reason, it seems better to try to show what we consider to be the best method to use when designing Active Directory permissions for all types of organizations.

First, create two documents, one called Allow and the other called Deny. On each document, label two sections, one called Global Tree Permissions and the other Specific Tree Permissions. Place two subheadings under each of the two sections, calling one General Permissions and the other Special Permissions. Then, under each general and special heading, create three columns: “LDAP path,” “What to set,” and “To whom.”

The first six columns relate to permissions that will apply throughout the whole tree; the last six relate to permissions that will apply to specific locations in the tree. The latter is likely to be the much larger of the two lists. The General columns relate to permissions that can be set without needing to use the Advanced button, such as read access to all objects below an organizational unit. The Special columns relate to those permissions that you have to manually bring up a permissions editor window for, such as allowing read access to all telephone numbers of user objects below a particular organizational unit. In each section, the “LDAP path” column should display the LDAP path to the object that is to have properties set, the “What to set” column should show the permissions that are being set, and the “To whom” column should display the group or user to whom the permissions are being assigned.

The LDAP path under Global Tree Permissions is, strictly speaking, unnecessary, since these columns relate to permissions applied to the domain as a whole. If, however, you have a special need to apply permissions to a large number of organizational units directly below the root, you could use this column for this purpose.

Now go through your Active Directory design and begin to populate both the Allow and Deny tables. For a first pass, you should concentrate on a thorough design, listing all the permissions that you think you will need. Print out a number of copies of the table. Once you have a list in front of you, you can start amalgamating identical permissions into groups. It is likely that you will need to go through many iterations of these designs until you get a pared-down list that you are happy with. As you go through the design, you will start identifying groups of users to which you need to apply permissions. When designing the groups, you have two choices, as previously discussed under Rule 2. You can either create a single group to which permissions are applied and that contains users, or you can create two groups: one to apply permissions to and one to hold users, which is nested in the first group.

The decision on whether to go for single or dual groups is not necessarily an easy one. Our preference is to use single groups as often as possible, unless we need extra flexibility or have a lot of permissions to assign to many groups. In order to help you to make a bit more sense of the decision, a few reasons why you would want to consider one or the other are shown in Table 16-3.

One last point: if you are creating permission groups and user groups, remember to name them sensibly from the outset. Maybe use something such as Finance – Allow User Modify for a group granting user modification rights on the Finance OU and Finance – User Admins for the user admin role over the Finance OU. It makes it easier when managing and scripting if you can easily identify which types of groups are which.

We’ve had people ask what we would recommend to someone arriving at a new company where the previous directory services administrator had left a tree with no proper permissions design or consistency. In this situation, start by analyzing what the organization requires and work from there. You also should analyze what permissions Active Directory currently has assigned, although concentrating solely on this could be detrimental. After all, if the last administrator was not competent or knowledgeable enough to set up a sensible permissions scheme from the start, he may not have accurately implemented the permissions required by the organization.

When analyzing Active Directory, you need to start by identifying the members of the built-in groups on the server, such as Domain Admins, Backup Operators, and so on. Now do the same for the other groups that are specific to the organization. Once this is done, using the previously described tables, you need to list the permissions on the root of the first domain in the tree you are responsible for. Then look at the permissions for the first container or organizational unit in that list. Next, navigate through the branch represented by that container, looking sequentially at the child containers, continually recursing through the tree. Once this first branch of the root is mapped out for the container permissions, you should be getting an idea of what permissions are required. Now go through all the objects in that branch, including printers, users, shares, and so on. This is time-consuming and annoying, but after a while you should start getting an idea of what is going on. All of this is just a sensible approach to going through Active Directory, not a quick-fix solution. You still have to continue throughout the domains you are responsible for to complete the process. It is also often helpful to use a script to iterate through Active Directory and display all of the ACLs for an object.

Your first main goal should be to move the individual user permissions to groups with users assigned to them as often as possible, thus making Active Directory simpler to manage and comprehend. These groups should be sensibly named for what they do rather than whom they contain (after all, you are looking to understand Active Directory first). Ideally, you can start consolidating users with identical permissions into the same group.

Your second goal is to remove permissions that users or your newly created groups should not have. This may, of course, mean that your new groups need to have their members split into two or more separate extra groups. For example, a group that has Read All Properties rights and Write All Properties rights to an object may need to be split into three groups with more limited permissions instead: one with Read All Properties, one with Write All Properties, and one with selected write permissions rather than complete write access. This may be evident from your Active Directory analysis, or it may come out of discussions with users or their managers, with whom you should at least confirm the changes before implementing them just to make sure your analysis is correct.

Ultimately, your third goal, having rationalized the array of Active Directory permissions, is to try to limit the inheritance blocking of objects and branches and to try to move as many advanced permissions to general permissions as you can. You might think that it makes more sense to do this earlier, and in some cases, this is true. However, if you complete the first two goals, you will have an Active Directory tree that you understand and that has been brought back into line with sensible rules. It is much easier to attempt to fix problems with inheritance blocking and advanced permissions once you have a manageable and rationalized tree. You may end up going back and changing groups or permissions that you already sorted out in attaining the first two goals, but consider how much more difficult it would be to attempt to do these concurrently. After all, you are trying to make the best of an already annoying task. There is no sense in trying to do everything at once. As you go through the tree checking for inheritance blocking, you should document the blocked objects and branches, as specified in Rule 5, just as if you had set up the blocking from scratch yourself. That way, you can use the tables to analyze and keep track, crossing off those that are of no use as you rationalize the tree.

This whole section can be boiled down to two simple words: simplify and secure. You want to end up with the simplest, least delegated model you can attain while meeting the requirements at hand, resulting in the most locked-down directory you can live with.

Windows Server 2008 introduced a completely new Active Directory auditing capability that greatly improves upon the capabilities in Windows Server 2003. On Windows Server 2003 domain controllers, if you enabled the “Audit directory service access” setting, a generic event was logged each time a user succeeded or failed to access an object with a System access control list (SACL) defined. From a practicality standpoint, this functionality was of limited value and could easily flood the security logs on your domain controllers.

Active Directory now allows you to audit changes to the directory on a granular level, as well as to view previous and current values when changes occur. Figure 16-16 shows an example of an attribute-modify audit event. A number of new auditing events have been created that will be logged to the security log when changes occur. See Table 16-4 for a listing of these events.

Figure 16-16. Attribute change audit

Enabling the new auditing functionality is a three- or four-step process:

To enable the “Audit directory service access” setting, browse to it under Computer ConfigurationPoliciesWindows SettingsSecurity SettingLocal PoliciesAudit Policy inside of a group policy that applies to your domain controllers, and audit Success attempts.

Next, you’ll need to configure “Advanced audit policies” in group policy. These settings can be found under Computer ConfigurationPoliciesWindows SettingsSecurity SettingAdvanced Audit Policy ConfigurationAudit PoliciesDS Access.

In order for change audits to be logged, you will need to configure the SACL on the objects to be audited, as discussed earlier in this chapter. Make sure to enable the correct auditing entries, as outlined in Figure 16-15.

Change auditing can be disabled globally for attributes by modifying the searchFlags attribute on the attributeSchema object in the Active Directory schema. The searchFlags attribute is a bit mask, and auditing is managed by the ninth bit. To disable auditing for the info attribute using adfind and admod, you would run the following command:

adfind -sc s:info systemFlags -adcsv | admod systemFlags::{{.:SET:256}} -upto 1

To enable auditing for the info attribute, run this command:

adfind -sc s:info systemFlags -adcsv | admod systemFlags::{{.:CLR:256}} -upto 1

You must be a member of Schema Admins to modify this attribute.

Active Directory supports a series of attributes that, when enabled, store the date and time of the last successful and failed Ctrl-Alt-Delete logons for a user in the directory, as well as the hostnames of the machines on which they occurred. These attributes are part of the user class in the directory. You may be wondering how this is different from the lastLogonTimeStamp attribute. The lastLogonTimeStamp attribute uses special functionality to limit the update frequency to an infrequent (every 10 to 14 days, roughly) interval, and it does not store the hostname associated with the logon attempt. These new attributes are updated immediately.

There are a number of limitations to this feature that you should keep in mind when considering whether or not it is appropriate for your environment. The first is that this functionality only tracks interactive logons. In other words, only logons that occur when a user presses Ctrl-Alt-Delete on a Windows Vista or newer machine are tracked. In order for the tracking to occur at all, the user’s domain must be running at the Windows Server 2008 functional level or better, and a registry setting must be enabled on the client and on the domain controllers.

The registry setting is a REG_DWORD called DisplayLastLogonInfo located at HKLMSotwareMicrosoftWindowsCurrentVersionPoliciesSystem. If, on a domain controller, you set DisplayLastLogonInfo to 1, it will begin storing logon statistics in Active Directory. If you set this value to 1 on a client, the client will begin reporting last logon statistics similar to what’s shown in Figure 16-17 when a user logs in.

Figure 16-17. Displaying last interactive logon statistics

In lieu of setting a registry setting, we recommend that you instead use the corresponding Group Policy setting for this feature. The Group Policy setting is available under Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsWindows Logon Options. The particular setting you want to enable is “Display information about previous logons during user logon.” This setting needs to be enabled in policies that apply to both domain controllers and clients in order to enable storage and display of logon statistics, respectively.

If you enable this setting on clients that have users logging into domains not running at the Windows Server 2008 or better functional level, clients will receive an error similar to Figure 16-18 and be unable to log in. You will also receive the error in Figure 16-18 if this setting is enabled on clients, but not domain controllers.

Figure 16-18. Last interactive logon statistics failure

There are four attributes that are used to provide this additional logon information functionality in the directory:

Unlike the lastLogonTimeStamp attribute, there is no update frequency safeguard for these attributes. If you enable this feature, keep in mind that every single time these attributes are updated, they will replicate in the next cycle. There could potentially be thousands of updates a day to these attributes in a busy domain. Also, there is no guarantee that the values shown to the user (like in Figure 16-17) are in fact the most accurate values in an environment with more than one domain controller in the domain, since these attributes replicate like any other change to the directory.

The implementation of the last interactive logon statistics feature discussed in this section was designed primarily for compliance with Common Criteria (http://www.commoncriteriaportal.org). Unless you have a business need for this feature or you are enabling it in a small (e.g., single-site) domain, we do not recommend that you enable it.

In this example, an organizational unit called Hardware Support Staff contains the user accounts of an in-house team of people whose job is to repair and fix broken computers within your organization. Whenever a user has a fault, he rings the central faults hotline to request a support engineer. An engineer is assigned the job, which is added to the end of her existing list of faults to deal with. The user is informed about which engineer will be calling and approximately when she will arrive. As with all jobs of this sort, some take longer than others, and users have discovered how to find the mobile or pager number of the engineer they have been assigned and have taken to calling the engineer to get an arrival-time update rather than ringing the central desk. Management has decided that they want to restrict who can ring the pagers or mobiles, but they do not want to stop giving out the engineers’ names as they feel it is part of the friendly service. Consequently, they have asked you to find a way of hiding the pager and mobile numbers in Active Directory from all users who should not have access.

The solution that we will use is to remove the default ability of every user to see the pager and mobile properties of the engineer objects by default. The first thing we need to find out is how the permissions are currently granted to the users. We look at the ACL on a user object and we do not see either attribute listed specifically. We do, however, see an inherited Read Property (RP) access for the entire object granted to the Pre-Windows 2000 Compatible Access group. We also see explicit RP access for several property sets granted to Authenticated Users.

Next, we look at the schema definition for the two attributes and we see that both have the attributeSecurityGUID set to {77B5B886-944A-11D1-AEBD-0000F80367C1}, which means the attributes are in a property set. We scan through the cn=extended-rights container and determine that the property set these attributes are in is the Personal Information property set. We look at the ACL again and see that the Personal Information property set is one of the property sets that has RP access granted to Authenticated Users. We know that the domain has Pre-Windows 2000 Compatible Access enabled, so users are getting access to the pager and mobile attributes through two different ACEs, both explicit and inherited. Recall from the earlier section Permission Lockdown that the explicit property set ACE is the more difficult of the two to deal with. We will focus on that one initially.

The first thing we will do is create a sub-OU under Hardware Support Staff called Engineers and move all of the engineer user objects into that OU. We could try to individually lock down the engineer user objects in the parent OU, but that is a layer of complexity that isn’t needed and should be avoided. Now that all of the engineers are isolated in their own OU, we need to decide which of the previously discussed mechanisms is appropriate to lock down access to the pager and mobile attributes. Again, these options are:

Options 1 and 2 could be used, but we would have to go back through the rest of the forest and add inherited ACEs granting RP access to the pager and mobile attributes for Authenticated Users. All of this extra work would be needed to attain the net effect of a permission change only on the targeted OU. If you think that you will be locking these attributes down for more OUs or maybe for all users in the forest, these options would become more palatable.

With option 3, you target only the engineer objects. When you strip the Personal Information ACE, not only will access to the mobile and pager attributes be affected, but also access to every other attribute in the Personal Information property set, which includes 46 attributes in the default Windows Server 2008 forest.

For all three of these options, if the domain is in Pre-Windows 2000 Compatible mode, users will still have access to all attributes through the inherited ACE granted to the Pre-Windows 2000 Compatible Access group. In order to lock down the two targeted attributes, we would also need to add an inherited deny ACE for each attribute on the Engineers OU. This would work great and everyone would be happy until later on, maybe a year or two down the road after you’ve forgotten all about this change, when you decide, “We don’t need to be in Pre-Windows 2000 Compatible mode anymore” and remove the Authenticated Users group from the Pre-Windows 2000 Compatible Access group. As soon as you do this, the permissions removed in options 1, 2, and 3 would quite suddenly impact you by disallowing access to all attributes that are in the Personal Information property set. Obviously, this could be quite a surprise! You might think it was because you still needed to be in Pre-Windows 2000 Compatible mode, but it would actually just be a delegation issue.

The last option, option 4, would target just the engineer user objects, and there would be no unintended side effects later with other domain changes. This is probably the best solution in this case, though it will require is a good amount of initial work plus ongoing maintenance as new engineer users are added. It would be best if a script were built strictly for doing this work.

You may wonder, “Wouldn’t this be a great place to use the confidential bit?” Unfortunately, no, this isn’t a good example, because it would impact all users in the forest; also more importantly, both the mobile and pager attributes are Category 1 attributes, so you can’t modify them to make them confidential.

The Finance Department has created a new share called Budget_Details and published it in the tree. The permissions to the share itself allow only the correctly authorized staff to read and view the contents, but everyone by default can see the volume object describing the share in the tree. The Finance Department does not want the share visible in Active Directory to anyone who is not a member of the Finance group.

Again, the first thing we need to determine is how the permissions are currently granted to the users. We look at the ACL on a volume object, and the only permission granted to normal users is a Generic Read ACE for Authenticated Users. Since this is a single object, it probably doesn’t make sense to create a whole OU for it, so we open up the permissions editor window for the volume object and remove the Authenticated Users group entry. We then add an entry for the Finance group and assign Read and List permissions.

After much discussion, it is decided that national/regional ID numbers will be moved from a proprietary database and inserted into Active Directory. There is quite a bit of concern about the visibility of the attribute, as only the HR Department and Domain Admins should be able to see it by default.

You extend the schema with a new national/regional ID number attribute and you set the searchFlags attribute to 128 to indicate that the attribute should be protected using the confidential attribute feature. Now you simply have to create a new group called HR-Confidential and assign a single inheritable ACE at the root of each domain that grants this group Control Access to the national/regional ID number attribute on user objects.

Later, if someone decides they want to secure the attribute from domain administrators as well, you will need to go through and apply an explicit deny ACE to every single object for that group. However, trying to deny access to data in the directory to domain administrators is not actually enforceable. At any point that a domain admin would like to get access to the attribute again, she can simply modify the ACL herself. If you absolutely cannot allow domain administrators access to the data, you need to find some other way of protecting the data, such as using third-party encryption or placing it on a machine that isn’t in the domain and therefore is not under the control of the domain administrators.

There a couple of different paradigms for deploying DAC, which makes this discussion more complicated. You can take advantage of the compound ACL functionality with just group membership without any additional configuration. But if you want to start constructing ACLs based on attributes of the users (or their devices), you’ll need to configure claim types in Active Directory as well as some Group Policy settings.

Finally, you can publish filesystem access policies that dynamically apply or model ACLs to filesystem data based on properties of the files themselves. These policies are known as central access policies. Central access policies are comprised of a series of central access rules that govern the ACL that will be applied to matching files and folders. The properties that can be set on files and folders are published via resource properties.

Fortunately, Microsoft has provided a GUI for configuring most of the DAC feature set. If you haven’t already explored the Dynamic Access Control node in the Active Directory Administrative Center (ADAC), take a few minutes to do so. Each of the components we just discussed is configurable under the Dynamic Access Control node. The only component that must be configured solely via Windows PowerShell is the claims transformation functionality that is used when you need to pass claims across a forest trust.

Configuring claim types

The first task you’ll likely want to take on is making attributes available as claims. This is configured by creating claim types in Active Directory. Claim types map an attribute of the user or the user’s device in Active Directory to a claim that is included in the user’s access token. To create a claim type, launch ADAC and browse to Dynamic Access ControlClaim Types. In Figure 16-20, we are creating a claim type called Employee Type. This claim is sourced from the employeeType attribute.

Figure 16-20. Creating the Employee Type claim

If there are a well-known set of values that will be in the claim, you can configure suggested values at the bottom of the screen that will be displayed in a drop-down list in the ACL editor. Figure 16-21 shows how to add a suggested value for full-time employees. The value field corresponds to the actual data that is stored in the Active Directory attribute, while the display name field is what is shown in the ACL editor. Once you create a claim type, it will be available for use on Windows Server 2012 file servers across the forest.

Figure 16-21. Adding a suggested value for a claim

It is very important that you think about the new dependencies that are being created on the data in the attributes that you are publishing as claims. As soon as you publish an attribute as a claim, you will not be able to change the format of the data stored in the attribute without coordinating an update to all of the ACLs that reference that attribute’s format. If you are sourcing attribute values directly from another system (such as a human resources database), you will need to communicate this dependency to the owners of the source system. The values in the source system will not be able to be changed without coordination across the Active Directory and file server teams.

Configuring central access policies

Central access policies enable organizations to apply access rules to data based on properties of the data from a central location (Active Directory). This functionality is especially useful when you have a mechanism in place to classify data and specific policies or regulations to comply with. For example, you might have a policy that any data that contains personally identifiable information (PII; e.g., national/regional ID numbers) that is classified at moderate impact or higher must only be accessible to full-time employees.

To begin, use ADAC to enable the Personally Identifiable Information resource property. This is a resource property that is included out of the box with DAC. You can add as many resource properties as you like and/or customize the resource properties that are included.

Next, you need to use ADAC to define a central access rule that describes the access control you want to implement. A central access rule is comprised of scoping criteria that determine the data that the rule applies to and an ACL to apply to that data. To scope the rule to apply only to PII, edit the target resource criteria as shown in Figure 16-22.

Figure 16-22. Central access rule targeting criteria

Next, configure the permissions to restrict access only to Domain Users who have the Employee Type claim with a value of Full Time Employee, as shown in Figure 16-23. You can either configure permissions to operate in a “proposed” mode, whereby resources that have permissions that don’t match the policy will be logged in the event log, or enforce the permissions on all matching resources. We recommend that you begin with the audit/proposal mode to assess the impact of your policies.

Figure 16-23. Central access rule permissions editor

When you’re done, your central access rule should look similar to Figure 16-24.

Once you have created the rules you want to apply to a resource, you need to add them to a central access policy. Figure 16-25 shows a basic policy that contains the rule we just created. Once you have the policy ready to apply, you’ll need to make it available to the file server via Group Policy.

Figure 16-24. Central access rule configuration

Browse to the Computer ConfigurationPoliciesWindows SettingsSecurity SettingsFile SystemCentral Access Policy node in the group policy with which you’ll be applying the central access policy. You can apply one or more policies by right-clicking and selecting Manage Central Access Policies. Add the policy you created in the previous step.

Figure 16-25. New central access policy

You’ll also want to enable the central access policy auditing features to take advantage of the audit/proposal mode we selected in the central access rule. You can do this by browsing to the Advanced Audit Policy ConfigurationAudit PoliciesObject Access node under Security Settings in the Group Policy Management Editor. Enable success and failure auditing for the Audit Central Access Policy Staging and Audit File System entries.

Once you’ve published a central access policy to a file server, you must apply the policy to a folder structure. Only once you’ve completed this step will the rules in the policy take effect. To complete this step, open the properties of the folder you want to apply the policy to and access the Security tab. Click Advanced, switch to the Central Policy tab, and apply the policy created earlier, as shown in Figure 16-26.

Figure 16-26. Central access policy application

While we’ve looked at how to apply ACLs via a central access policy, it’s also possible to simply start using claims and the new ACL functionality that DAC brings without going through the central access policy processes.

Compound expressions with groups

Out of the box, you can start creating ACLs on Windows Server 2012 file servers that simply involve existing group memberships. The power in this new feature is that you can define Boolean expressions using the AND and OR operators, as well as setting matching (such as requiring that the user is a member of one or more groups in a list).

Consider our earlier example, where we needed to restrict access to a folder to users who were members of the Finance Users group as well as the Managers group. To complete this task, open the security properties of the folder, and then click Advanced. Add the Finance Users group to the ACL and configure the permissions (e.g., read or write access). Next, add a condition that the user is also a member of the Managers group, as shown in Figure 16-27.

Figure 16-27. Compound group expression

While this is a simple example consisting of only two groups, you can see how you can easily construct much more complex expressions that model the structure of your organization using existing Active Directory groups. It would not be out of the question to reduce the number of groups some users are a member of considerably just by taking advantage of this feature on your file servers.

Using claims in your ACLs

The same editor we used in Figure 16-27 can be used to construct expressions based on user and device claims as well as properties of the target resource. As a simple example, let’s extend the expression we constructed earlier that allows access to members of the Finance Users and Managers groups to require that the users not be vendors.

To do this, add a rule that says Employee Type does not equal Vendor, as shown in Figure 16-28. You’ll see that the drop-down list is prepopulated with the list of suggested values we defined when we created the claim type.

Figure 16-28. Excluding vendors from access to data

Auditing

You can use the same concepts we just explored for file access to configure auditing as well. This makes the filesystem auditing functionality in Windows substantially more useful. Previously, auditing was essentially an information overload as there was little flexibility in configuring what operations were audited.

Take into account the ability to construct expressions based on user, device, and resource properties, and you might configure an auditing rule that only audits access to resources that contain PII, as shown in Figure 16-29.

Figure 16-29. Configuring auditing of access to personally identifiable information