Active Directory (AD) has decent capabilities for setting permissions on objects to allow delegated administration of items such as users, groups, or computers according to any security principal. But when it comes to making specific data visible to only those users who need to see it, the default AD permissions can make the task rather complex.
This multi-part series will discuss AD data-hiding options. These options can be based on typical AD permissions, a special AD permission feature called List Mode, or a little-known option called the confidentiality bit (introduced a few years back with Windows Server 2003 SP1). Windows Server 2008 R2 and Windows Server 2008 have included only minor enhancements with respect to setting permissions on AD data, which I'll also describe.
Before we delve into the details of hiding data in AD, you need a good understanding of the challenge. I'll describe the solution in the future articles in this series.
Understanding the Challenge
The main reason that hiding data in AD is something of a challenge is the various default permissions that are granted in an AD forest. During the design of AD, Microsoft chose to grant numerous read permissions to all authenticated users, for almost all new objects that are created in a forest, instead of locking down the default settings and forcing administrators to grant the appropriate read permissions for the environment. As always, there are pros and cons to both approaches. I would even argue that these less-restrictive default permissions are part of AD's success: Less administrator effort is required to make things work.
Companies are slowly realizing the wealth of default read (and write) permissions that are granted to all the user accounts in their corporate AD implementations. Most companies might want to differentiate between employees, who are allowed to query for all accounts in AD, and external users (e.g., contractors). Also, companies that want to adopt AD as not just a network OS (NOS) directory (which authenticates users to the network) but also as a plain LDAP directory (which is used by other applications) require more control over who can see what. Furthermore, in companies for which delegation of administration is important, the access to and visibility of sensitive accounts is a crucial aspect that needs to be planned carefully. This is certainly the case for outsourcers that might host users from various companies within one AD forest.
By default, all authenticated users in an AD forest are granted explicit read permissions on any organizational unit (OU) that a domain administrator or delegated administrator creates. In this case, any logged-on user can see all objects within any OU in an AD forest. The situation doesn't improve when we look at the default permissions for the different types of AD objects (e.g., a userClass object). As Table 1 shows, authenticated users are granted various read permissions, but SELF (i.e., the user, when accessing his or her own account) has the right to read all properties and to edit many of them.
Besides these explicit permissions for every new object, various permissions are inherited from parent OUs. Fairly critical default permissions, including Read All Properties for user objects, are granted to the Pre-Windows 2000 Compatible Access group. One of the main challenges is limiting the permissions for authenticated users in such a way that users don't see everything by default. Understanding every annoying detail of AD permissions and how to adjust them now becomes crucial.
Notice I used the term "explicit permissions." Explicit permissions are those that are set directly on objects, as opposed to inherited permissions, which are set on a container object and configured to apply to objects within that container and its subcontainers.
Explicit vs. Inherited Permissions
Both explicit and inherited permissions are needed for an efficient AD authorization model. When a user tries to access an AD object, the security reference monitor must evaluate the list of permissions in ACLs and compare them to the user security identifier (SID) and group SIDs in the security token, to determine whether access should be allowed or denied. To do so, the security reference monitor processes an ACL, starting at the top. When the monitor finds enough access control entries (ACEs) to determine that the access should be denied or allowed, it stops processing the ACL and returns the authorization result (i.e., deny or allow) to the requesting process. The order in which ACEs occur in the ACL determines the effective permissions. Table 2 lists ACE ordering and evaluation priorities.
Deny permissions take precedence over allow permissions, but explicit allow permissions override inherited deny permissions. If child objects inherit an explicit allow permission, that permission also overrides a deny permission that's inherited from further up the OU hierarchy. This means that even if an administrator were to deny access to a certain user attribute (e.g., phone-number) for all external users at the domain head in AD, these permissions generally would be overridden by the default explicit read permissions that are granted to all authenticated users in the forest.
Figure 1 illustrates an example. Although the ExtUsers group is denied read permissions at a top-level OU or at the domain node, some of the sub-OUs still apply the default permissions, which grant authenticated users read access to most objects and attributes. These permissions also apply to newly created objects. And the top-level deny permission can't travel all the way down the tree if it comes across an OU that blocks inheritance of permissions from the parent OU. The future articles in this series will show you how to get past this problematic behavior.
Figure 1: Sample explicit allow permission overriding top-level deny permission
Permission Property Sets
Many AD attributes are grouped into permission property sets. Property sets allow one ACE to grant or deny permissions on an AD object for a collection of attributes. Without property sets, you'd need to apply many separate ACEs for each attribute. A good example of a property set is the Personal Information set. In Server 2008 R2, this set contains 47 attributes, including the user's address and telephone number.
An attribute is defined as belonging to a particular property set by its attributeSecurityGUID property, which matches the rightsGUID property of the property set. Figure 2 shows how the permissions of a property are viewed in the AD security editor and how they're applied to and evaluated for multiple user-object attributes.
Figure 2: AD permissions can apply to multiple attributes via property sets
Property sets were introduced both to simplify administration and to preserve storage space in AD. The latter shouldn't be underestimated. Every ACE that applies to an object needs to be stored in AD. A permission that's given to a property set is both displayed and stored as a single ACE, saving space. Be aware that any attribute in AD can belong to only one property set-an important restriction when it comes to customizing AD security. You can find the definition of all default property sets on the Microsoft Property Sets page at msdn.microsoft.com/en-us/library/ms683990.
Although the majority of property sets are the same across Windows Server versions (as Table 3 shows), an important feature-the ability to edit the default property sets-is available only in Windows 2003 and later. I'll cover the editing of these sets in more detail in the second part of this series.
Table 3 also shows that most of the default property sets still contain the same number of attributes as the initial release of AD. However, a few sets were updated during schema updates, when new features such as LastLogonTimeStamp (in Windows 2003) or ManagedAccounts (in Server 2008 R2) were introduced.
Microsoft Exchange Server also extends the schema through various attributes, some of which are added to the default property sets. But it wasn't until Exchange Server 2007 that Microsoft chose to create new permission property sets that are dedicated to Exchange. In fact, it's rather curious that Exchange doesn't leverage the Phone and Mail Options property set, which you would think was meant for a messaging system. Instead, before Exchange 2007, all relevant attributes (120 of them) went into one existing property set: the Public Information property set. This property set also includes all the extensionAttributes, which are expected to store information of public interest only, because authenticated users have default read access to this property. (The Personal Information property set is left untouched by an Exchange installation.)
Of the four property sets to which authenticated users are granted default read permissions on user objects (i.e., General Information, Personal Information, Web Information, and Public Information), the Personal Information property set is usually of greatest interest to administrators who want to hide access to specific account data. This set contains potentially sensitive data, such as the employee's home phone or home address. Although companies might not feed this data into AD automatically, every user can do so through the default permissions that are granted to the SELF security principal. Figure 3 lists the 47 attributes that belong to the Personal Information set in Server 2008 R2.
Figure 3: Attributes of the Personal Information property set
So, why are property sets important when discussing hiding data in AD? It's quite simple. Take another look at Table 1, which lists the default permissions that are granted to every new user object in AD. You'll see that four explicit allow read permissions for authenticated users (i.e., General Information, Personal Information, Web Information, and Public Information) are granted to property sets. Add this to the higher priority of explicit allow permissions over inherited deny permissions, and it becomes clear that hiding the data of attributes that are part of a property set is no simple task. You can't just set a deny permission for an object attribute at the OU level and force inheritance to the respective objects. That's why administrators must have a good understanding of property sets and the attributes that belong to them, to fully understand the effect of permissions that are granted or denied to specific attributes in AD.
Note that using third-party tools to manage AD permissions usually helps only when granting new permissions. However, hiding data often requires removing existing permissions that are granted by default. These permissions need to be adjusted in the native permissions of the directory-only after being validated and tested in a proper test lab, of course.
When Is Hiding Data Necessary?
This article would certainly have a different focus if the default read permissions for authenticated users in AD weren't as pervasive as they are. By now, it should be clear that the challenge of hiding data in AD is closely related to three things:
- the default read permissions that are granted to new AD objects
- the priority of inherited permissions during the ACL evaluation process
- the grouping of AD attributes into property sets
Most OU structures are designed to group objects of a similar type or location into one OU. Figure 4 shows how a company might have one OU for managing objects in Atlanta (ATL) and another for managing objects in Phoenix (PHX). Note that both location-level OUs have sub-OUs to further subdivide object types for each location. These divisions allow the delegation of different administrative rights or the application of different Group Policy policies.
Figure 4: Sample OU structure
Also notice the special sub-OU called Local Admins in Figure 4. This sub-OU is meant to hold special account data for the delegated administrators of the location. To protect these users from potential misuse or Denial of Service (DOS) attacks, it's a good idea to hide the Local Admins OUs from end users.
Another reason for hiding users or complete OUs is to prevent other users knowing of their existence in AD. This capability can be important in sensitive environments such as financial institutions, government agencies, or outsourcing companies, in which each top-level OU represents a different customer, each of which should be able to see only that customer's objects.
There are also technical reasons to hide data in AD, especially when it becomes important to limit delegated administrators' ability to link AD objects. When you add a user as a member of a group, you link that user to the group. You aren't actually editing the user object properties, only the group's membership attribute (the forward link). In our previous sample OU structure, suppose that a delegated administrator has all the required permissions to manage groups and users in Phoenix (OU PHX) but not in Atlanta (OU ATL). That administrator, by default, can still add users from the ATL OU (or any other place in the AD forest) to groups in OU PHX. Companies usually accept this issue, which also offers an easy way to establish cross-boundary access to shared resources, such as file servers, or to provide vacation coverage for site admins.
However, in ISP scenarios and other sensitive environments, administrators often must not be able to add users from outside their scope of responsibility (i.e., outside the OU or OUs that they manage) to groups that they do manage. In such cases, you also need to hide users that are outside the OUs that a delegated administrator manages so that the administrator can't add those users to their groups or to any other linked attributes, such as to the manager attribute of a user or the managedBy attribute of objects such as printers, groups, or OUs.
Finally, companies might need to hide data that's stored in specific attributes of different types of objects in AD, instead of hiding the complete object. This need depends on the sensitivity of the data. For example, if a company stores users' employee numbers in AD, it might want to hide that information to all users who aren't in HR. Similarly, the company might want to restrict access to the home phone number attribute. More often, companies have added their own attributes in the AD schema to store additional information for other applications. Common schema extensions include attributes for cost centers or special application-specific roles, or even attributes that store token IDs to support other authentication methods that use AD as an LDAP server. Many of these special attributes aren't meant to be seen by end users or lower-privileged administrators, such as Help desk operators. The information in these special attributes could pose a risk to the company if it falls into the wrong hands.
In summary, these are the most common reasons for hiding data in AD:
- to protect administrative accounts from misuse and DOS attacks
- to hide the existence of specific objects for legal reasons
- to honor least privilege for special administrative tasks, such as ensuring that delegated group administrators can change membership for users within their own administrative scope only
- to ensure that sensitive data within attributes is disclosed to authorized users only
Options for Hiding Data
In general, the goal when hiding data in AD is to hide data from unauthorized users and make it accessible only to those who are specifically allowed to view it, via membership in an appropriate security group, for example. With this goal in mind, the preferable solution is to limit access (i.e., default deny) to objects or attributes by ensuring that only specific security principals (e.g., security groups) are granted access to them, rather than first granting general access (i.e., default allow) to an object (e.g., to all authenticated users) and then trying to deny access to unauthorized users. We also need to differentiate which data is supposed to be hidden in the first place: the whole object, or just specific attributes of an object?
Table 4 lists the main options that are available to hide data in AD, including the scope (objects or attributes) and the OS version that supports the respective option. In reality, administrators often need to combine different permission configuration options to reach their AD data-hiding goals.
As with most things, understanding the problem before designing an appropriate solution is crucial. This article describes why hiding data in AD is a challenge in the first place, gives examples for when you might need to do so, and helps you understand the available options for solving this challenge. The future articles in this series will explain, in detail, how to use these options to hide objects in AD or data that's stored in specific attributes of AD objects. Part 2 will discuss how to use normal permissions on AD objects and attributes, enable List Object Mode in a forest, or adjust the default security of objects in AD. Part 3 will cover adjusting the built-in property sets. Finally, Part 4 will explain how to use the confidentiality bit and how to configure the filtered attribute set to adjust which attributes are replicated to read-only domain controllers (RODCs).
