For secure delegation, use List Object mode to hide data in Active Directory
You can make data in Active Directory (AD) visible only to those who need to see it. Hiding data allows delegated administration of users, groups, or computers to any security principal, so that many daily operational tasks don't need to be performed by domain administrators. Hiding data in AD by using normal AD permissions is one option, as I described earlier in this article series. (See the Learning Path for a list of the previous articles in the series.) Another option, and the one I'll examine in this article, is to enable List Object mode (sometimes referred to as List Mode) in the AD forest. (Later in the series, I'll tell you about a third option: adjusting the default security descriptor of AD objects.)
As I mentioned in my previous articles, Authenticated Users are granted the Read and the List Object permissions on any newly created organizational units (OUs). In its default configuration, AD doesn't enforce the List Object permission, and the AD security editor doesn't display the permission. However, after an enterprise administrator enables List Object mode (which can be enabled only for the entire forest), the List Object permission is enforced. I'll cover how to enable List Object mode later in this article, but first let's concentrate on how this mode works.
It's crucial to understand the difference between the List Contents and the List Object permissions and how they work together. The concept of List Object mode is quite simple. When this mode is disabled (which it is by default), AD doesn't evaluate the permissions of any objects underneath any container object (e.g., an OU) that a user queries.
To view the contents of an OU, the user needs to be granted the List Contents permission (which is a subset of the Read permission) on the OU. If the List Contents permission isn't granted (e.g., because the Read permission is removed), then no child objects are returned to the user. If the List Contents permission is granted, then AD returns all child objects of the OU to the user, regardless of whether the user has the Read permission on, or is denied access to, the child object. However, a GUI such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in can't correctly display the object type unless the user has Read access on a child object. Instead, the type is displayed as Unknown, as Figure 1 shows.
Figure 1: Displaying Objects in List Object Mode
When List Object mode is enabled, AD evaluates the permissions of each object before returning the list of objects to a user. Administrators can remove or deny the List Contents permission on a parent container, to hinder the return of all child objects in the respective container. But AD still processes the permissions on those child objects to determine whether the user has been granted the List Object permission on any child object. If so, AD adds the object to the result set; if not, the object is omitted.
The three example situations in Figure 1 show the difference between using List Object mode and using normal permissions to hide objects in AD:
o List Object mode in AD is turned off.
o The user is granted the List Contents permission on the US parent OU, via the normal Read permission that's granted to Authenticated Users.
o The user also has the Read permission on child objects (i.e., the ATL and PHX OUs).
o The result is that two objects are displayed in Active Directory Users and Computers. The UI can evaluate both objects, which can be displayed with the correct icon and so on.
o List Object mode in AD is turned off.
o The user is granted the List Contents permission on the US parent OU, via the normal Read permission that's granted to Authenticated Users.
o The user still has Read permission on the PHX child object, but Read access to the ATL child object is removed for Authenticated Users.
o The result is that two objects are displayed in Active Directory Users and Computers, but the UI can correctly evaluate and display only the PHX child object; ATL is displayed as an unknown object, although the user knows that the object exists.
o List Object mode in AD is turned on.
o The List Contents permission on the US parent OU is removed for the user, by removing the permission for Authenticated Users.
o The user has the default Read and List Object permissions on the PHX child object. The user still has the default Read permission on the ATL child object, but the List Object permission is removed.
o The result is that only one object -- the one to which the user has the List Object permission -- is displayed in Active Directory Users and Computers. Because of the additional Read permission on other attributes, the UI correctly evaluates and displays the object. The ATL child object is no longer displayed, and the user doesn't know about its existence in AD.
The List Object permission is a useful tool when users aren't supposed to see certain objects in AD. The permission is typically used on OUs, to fully remove an OU's visibility for all users (with the exception of the administrator who is managing the OU). The List Object permission is mostly helpful in outsourcing environments, in which the outsourcer hosts a directory for multiple companies and the users or OU admins of each company shouldn't see the OU for the other companies.
Within an organization, the List Object permission is often used to hide security-sensitive objects, such as admin accounts, from unauthorized users. Doing so limits the potential for Denial of Service (DoS) attacks against these accounts.
As previously mentioned, the List Object permission isn't active or visible in AD's security editor until List Object mode is enabled in the forest. When this feature is enabled, a new permission appears in the AD security editor, as Figure 2 shows.
Figure 2: Active Directory Security Editor, Before and After Enabling List Object Mode in Active Dir
To enable AD's List Object mode, you must edit a property of the Directory Services object in the AD configuration container, which requires Enterprise Admin privileges. This change is automatically replicated to all other domain controllers (DCs) in the forest. You can't activate List Object mode on a per-domain basis.
List Object mode is activated by setting the third character (byte) of the DSHeuristics property (Unicode string syntax) on the Directory Service object to 1. If the DSHeuristics property hasn't been set with other values, set it to 001. If the first two characters, or bytes, are already set to a non-zero value, leave them as they are. The Directory Services object is in the AD container cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,dc=ForestRootDomain.
Other DSHeuristics settings on the Directory Service object are used to control name resolution during AD searches, for example. When enabled, the List Object permission must be administered in conjunction with the List Contents permission. Table 1 summarizes the rules for using List Object mode with the List Contents permission.
The goal of the next permission example is to use the List Contents and List Object permissions appropriately to set up OU permissions for a company that runs an outsourcing business for multiple customers (see Figure 3). In this context, it's very important that only authorized users (i.e., members of the UserAdmins_CompanyX groups) can view their respective OU (i.e., CompanyA, CompanyB, or CompanyC), including the content under the UserAccounts parent OU. Setting up this scenario involves the following steps:
Figure 3: Setting OU Permissions for Multiple Customers
1. Remove the default List Contents permission for Authenticated Users from the UserAccounts OU. Doing so triggers the evaluation of child object permissions. (For information about how to perform this step, see the previous article in this series, " Hiding Active Directory Objects and Attributes .")
2. Remove the default List Object permission for Authenticated Users from all company OUs, to hide the visibility of the company OUs. In addition, remove the List Contents permission from the OU, to hide the objects within the OU. (As a result, these objects won't be returned during a subtree search.)
3. Grant the List Object and List Contents permissions for each UserAdmins group on the respective company OU.
Although the List Contents and List Object permissions can be set from the AD security editor, it's much easier to use the Dsacls command-line tool to set the permissions for multiple OUs. To do so in this example scenario, enter the following command, which first removes all permissions for Authenticated Users and then grants the required Read permissions on the OU without the List Contents permission:
The goal of Step 2 is to remove the default List Object and List Contents permissions for Authenticated Users from all company OUs. As when using Dsacls to remove the List Contents permission only, this step involves first removing all permissions for Authenticated Users and then resetting the permissions that you want to keep (in this case, Read and Read All Properties). For a single OU in our example scenario, use this command:
For multiple OUs, creating a list of distinguished names (DNs) and saving them to a file is easier. You can do so by using Dsquery:
DSQUERY ou -scope onelevel > queryresult.txt
In our example scenario, the command would look like this:
DSQUERY ou "OU=UserAccounts,DC=root,DC=net" -scope onelevel > queryresult.txt
After verifying the validity of your query results, you can perform a FOR loop to execute the previous Dsacls command against all objects in the file:
Note that to use the For command in a batch program, you would specify %%I instead of %I.
In Step 3, the actual permission to view the correct OU and its contents must be granted to the respective UserAdmins group for each company, by granting the List Object permission to the correct group:
DSACLS /G :LOLC
In the example scenario, the command would look like this:
DSACLS "OU=CompanyA,OU=UserAccounts,DC=root,DC=net" /G "UserAdmins-CompanyA":LOLC
Note that setting the List Contents permission next to the List Object permission for this OU ensures that all objects in the OU are returned for the authorized users. If the goal is to further distinguish which objects within the OU should be returned during a query, then the List Contents permission should not be set. In this case, the List Object permission would be required on each child object to list the object.
The result of the previous permission example is effectively to hide all user accounts of any hosted company in AD from unauthorized users. Members of the
respective UserAdmins_CompanyX group can now view only the accounts from their company. The permissions for a company's UserAdmins group can be further
extended to allow appropriate delegated admin functions (e.g., password resets).
To effectively hide all other objects in the AD domain -- such as the Builtin, Computers, System, and Users containers, or any other container object -- from users other than Domain Admins, remove the List Contents permission for Authenticated Users from the domain object itself (e.g., root.net). Then, remove the List Object permission for Authenticated Users for any container that should be hidden. Domain Admins (as well as Enterprise Admins) will still have full access to all objects through their respective groups' other inherited or explicit permissions on the OUs. Figure 4 and Figure 5 show the results.
Figure 4: Viewing Hidden OUs as Domain Admin
Figure 5: Viewing Hidden OUs as UserAdmin of CompanyC
Changing the visibility of objects in AD in this way can also affect other applications that leverage AD. These applications might rely on permissions that are granted to Authenticated Users. In other words: Testing is required to evaluate the effect of hiding OUs in an AD domain.
In a hosted Exchange Server environment, this approach works quite well because the Exchange servers are granted their own special rights on objects. Nevertheless, further adjustments are required to appropriately display address lists to users. You can typically disable the Global Address List (GAL) and create company-specific address lists instead, using an LDAP filter that points to the company OU only.
List Object mode in AD, which has been available since Windows 2000, can be compared with the Access-Based Enumeration (ABE) file-system feature that was introduced in Windows Server 2003 Service Pack 1 (SP1). By default, the normal NTFS file-system permissions on folders allow a user who has Read or List permissions on the folder to see all files and subfolders, regardless of whether the user has permissions to open the files to read them. When ABE is activated on a share, the file server evaluates the user's permissions for every file or subfolder, before returning the list of objects to the user. There's no dedicated List Object permission for files and folders in NTFS, so a user requires at least Read permission to view a file or folder in an ABE-enabled share.
In any case, these are the most important things to remember when working with the List Object mode in AD:
If you've read all the articles in this series, then you know that hiding data in AD can be a daunting task. Understanding the default permissions that are applied to objects in AD is crucial for any permission change, especially before tackling the use of List Object mode.
The last basic type of permission configuration option to be aware of is the default security descriptor of objects in AD, which I'll discuss in the next article in this series. I'll then finish off with a few advanced topics on handling built-in property sets and on handling AD attribute permissions with the confidentiality bit and with the filtered attribute set (FAS).
Learning Path
"Hiding Data in Active Directory"
"Hiding Active Directory Objects and Attributes"
Table 1: Rules for Using List Object and List Contents Permissions
|
Granted Permissions On... |
Result |
|
|
OU |
Child Objects |
|
|
List Contents and List Object |
N/A |
The List Object permission on the OU makes the OU visible. Because List Contents is also granted on the OU, this permission takes precedence over any missing List Object permissions for child objects, and AD automatically lists all objects in the container. A delegated administrator can browse to the OU and to all child objects by using Active Directory Users and Computers. An LDAP query for all objects returns the OU and all child objects. |
|
List Object (List Contents not granted or denied) |
List Object |
The List Object permission on the OU makes the OU visible. If the List Contents permission isn't granted or is denied and the List Object permission is granted on the container object (e.g., an OU), then AD evaluates the List Object permission for the child objects and lists only those on which the List Object (or Read) permission has been granted. A delegated administrator can browse to the OU and selected child objects by using Active Directory Users and Computers. An LDAP query for all objects returns the OU and only those child objects on which List Object permission has been granted. |
|
List Contents (List Object not granted or denied) |
N/A |
The OU isn't visible. Because the List Contents permission is granted on the OU, this permission takes precedence over any missing List Object permissions for child objects, and AD automatically lists all objects in the container. A delegated administrator can't browse to the OU or child objects by using Active Directory Users and Computers. An LDAP query for all objects doesn't return the OU object but does return all the OU's child objects. |
|
Neither List Contents nor List Object |
N/A |
The OU isn't visible. Because neither the List Contents nor List Object permission is granted to the container object (e.g., an OU), AD doesn't evaluate any permission on the child objects. A delegated administrator can't browse to the OU or child objects by using Active Directory Users and Computers. An LDAP query for all objects doesn't return the OU or any of its child objects. |