Hiding Data in Active Directory

Active Directory (AD) has decent capabilities for setting permissions on objects to allow delegated administration of items such as users, groups, orcomputers 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 ADpermissions 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 featurecalled List Mode, or a little-known option called the confidentiality bit (introduced a few years back with Windows Server 2003 SP1). Windows Server2008 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 futurearticles 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 thedesign 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, thereare pros and cons to both approaches. I would even argue that these less-restrictive default permissions are part of AD's success: Less administratoreffort 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 ADimplementations. 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, incompanies for which delegation of administration is important, the access to and visibility of sensitive accounts is a crucial aspect that needs to beplanned 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 administratoror 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 improvewhen we look at the default permissions for the different types of AD objects (e.g., a userClass object). As Table 1 shows, authenticated users aregranted 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 editmany 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 thepermissions for authenticated users in such a way that users don't see everything by default. Understanding every annoying detail of AD permissions andhow 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 securityreference monitor must evaluate the list of permissions in ACLs and compare them to the user security identifier (SID) and group SIDs in the securitytoken, to determine whether access should be allowed or denied. To do so, the security reference monitor processes an ACL, starting at the top. Whenthe monitor finds enough access control entries (ACEs) to determine that the access should be denied or allowed, it stops processing the ACL andreturns the authorization result (i.e., deny or allow) to the requesting process. The order in which ACEs occur in the ACL determines the effectivepermissions. 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 inheritan explicit allow permission, that permission also overrides a deny permission that's inherited from further up the OU hierarchy. Thismeans 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 inAD, 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-OUsstill apply the default permissions, which grant authenticated users read access to most objects and attributes. These permissions also apply to newlycreated 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 ofpermissions 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 collectionof attributes. Without property sets, you'd need to apply many separate ACEs for each attribute. A good example of a property set is the PersonalInformation 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 theproperty 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 formultiple 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 ACEthat 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, savingspace. 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 canfind 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 thedefault 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 thisseries.

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 setswere updated during schema updates, when new features such as LastLogonTimeStamp (in Windows 2003) or ManagedAccounts (in Server 2008 R2) wereintroduced.

Microsoft Exchange Server also extends the schema through various attributes, some of which are added to the default property sets. But it wasn't untilExchange Server 2007 that Microsoft chose to create new permission property sets that are dedicated to Exchange. In fact, it's rather curious thatExchange doesn't leverage the Phone and Mail Options property set, which you would think was meant for a messaging system. Instead, beforeExchange 2007, all relevant attributes (120 of them) went into one existing property set: the Public Information property set. This property set alsoincludes all the extensionAttributes, which are expected to store information of public interest only, because authenticated users have default readaccess 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, PersonalInformation, Web Information, and Public Information), the Personal Information property set is usually of greatest interest to administrators who wantto hide access to specific account data. This set contains potentially sensitive data, such as the employee's home phone or home address. Althoughcompanies might not feed this data into AD automatically, every user can do so through the default permissions that are granted to the SELF securityprincipal. 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 defaultpermissions 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 ofexplicit allow permissions over inherited deny permissions, and it becomes clear that hiding the data of attributes that are part of a property set isno 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'swhy administrators must have a good understanding of property sets and the attributes that belong to them, to fully understand the effect ofpermissions 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 requiresremoving existing permissions that are granted by default. These permissions need to be adjusted in the native permissions of the directory-only afterbeing 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. Bynow, it should be clear that the challenge of hiding data in AD is closely related to three things:

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 managingobjects in Atlanta (ATL) and another for managing objects in Phoenix (PHX). Note that both location-level OUs have sub-OUs to further subdivide objecttypes 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 ofthe 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 endusers.

Another reason for hiding users or complete OUs is to prevent other users knowing of their existence in AD. This capability can be important insensitive environments such as financial institutions, government agencies, or outsourcing companies, in which each top-level OU represents a differentcustomer, 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 ADobjects. 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 thegroup's membership attribute (the forward link). In our previous sample OU structure, suppose that a delegated administrator has all the requiredpermissions to manage groups and users in Phoenix (OU PHX) but not in Atlanta (OU ATL). That administrator, by default, can still add users from theATL 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 establishcross-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 ofresponsibility (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 areoutside the OUs that a delegated administrator manages so that the administrator can't add those users to their groups or to any other linkedattributes, 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 completeobject. 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 thatinformation 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 includeattributes for cost centers or special application-specific roles, or even attributes that store token IDs to support other authentication methods thatuse 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 deskoperators. 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:

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 allowedto 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, ratherthan first granting general access (i.e., default allow) to an object (e.g., to all authenticated users) and then trying to deny access to unauthorizedusers. We also need to differentiate which data is supposed to be hidden in the first place: the whole object, or just specific attributes of anobject?

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 therespective 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 achallenge in the first place, gives examples for when you might need to do so, and helps you understand the available options for solving thischallenge. 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 specificattributes of AD objects. Part 2 will discuss how to use normal permissions on AD objects and attributes, enable List Object Mode in a forest, oradjust 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 theconfidentiality bit and how to configure the filtered attribute set to adjust which attributes are replicated to read-only domain controllers (RODCs).