Hiding Data in Active Directory, Part 3: Enabling List Object Mode in a Forest

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, orcomputers to any security principal, so that many daily operational tasks don't need to be performed by domain administrators. Hiding data in AD by usingnormal 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 theseries.) 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.)

List Object Mode

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'llcover 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 Objectmode is quite simple. When this mode is disabled (which it is by default), AD doesn't evaluate the permissions of any objects underneath any containerobject (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 ListContents permission isn't granted (e.g., because the Read permission is removed), then no child objects are returned to the user. If the List Contentspermission 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 deniedaccess to, the child object. However, a GUI such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in can't correctlydisplay 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 ordeny the List Contents permission on a parent container, to hinder the return of all child objects in the respective container. But AD still processes thepermissions 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 objectto 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:

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 fullyremove 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 inoutsourcing environments, in which the outsourcer hosts a directory for multiple companies and the users or OU admins of each company shouldn't see the OUfor 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. Doingso 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. Whenthis 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 

Enabling List Object Mode

To enable AD's List Object mode, you must edit a property of the Directory Services object in the AD configuration container, which requires EnterpriseAdmin privileges. This change is automatically replicated to all other domain controllers (DCs) in the forest. You can't activate List Object mode on aper-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 to1. 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-zerovalue, leave them as they are. The Directory Services object is in the AD container cn=Directory Service,cn=WindowsNT,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 ListObject permission must be administered in conjunction with the List Contents permission. Table 1 summarizes the rules for using List Object mode with theList 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 thatruns an outsourcing business for multiple customers (see Figure 3). In this context, it's very important that only authorized users (i.e., members of theUserAdmins_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 objectpermissions. (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, removethe 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.

DSACLS Example

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 setthe permissions for multiple OUs. To do so in this example scenario, enter the following command, which first removes all permissions for AuthenticatedUsers and then grants the required Read permissions on the OU without the List Contents permission:

set DN="OU=UserAccounts,DC=root,DC=net"&& set SP="Authenticated Users"&& DSACLS %DN% /R %SP%&&DSACLS %DN% /G %SP%:RCRPLO 

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 toremove the List Contents permission only, this step involves first removing all permissions for Authenticated Users and then resetting the permissions thatyou want to keep (in this case, Read and Read All Properties). For a single OU in our example scenario, use this command:

set DN="OU=CompanyA,OU=UserAccounts,DC=root,DC=net"&& set SP="Authenticated Users"&&DSACLS %DN% /R %SP%&& DSACLS %DN% /G %SP%:RCRP 

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:

for /f "delims=" %I in (queryresult.txt) do set SP="Authenticated Users"&& DSACLS "%~I" /R %SP%&&DSACLS "%~I" /G %SP%:RCRP 

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 grantingthe 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 theauthorized users. If the goal is to further distinguish which objects within the OU should be returned during a query, then the List Contents permissionshould not be set. In this case, the List Object permission would be required on each child object to list the object.

Using a For loop, you can also automate the previous step by using the commandfor /f "delims=" %I in (companylist.txt) do DSACLS "OU=%~I,OU=UserAccounts,DC=root,DC=net" /G "UserAdmins_%~I":LOLCwhere companylist.txt contains a flat list of company names. 

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 therespective UserAdmins_CompanyX group can now view only the accounts from their company. The permissions for a company's UserAdmins group can be furtherextended 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 stillhave full access to all objects through their respective groups' other inherited or explicit permissions on the OUs. Figure 4 and Figure 5 show theresults.

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 thatare 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) andcreate 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 wasintroduced 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 Listpermissions 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 isactivated 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 anABE-enabled share.

In any case, these are the most important things to remember when working with the List Object mode in AD:

Understand the Tasks

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 areapplied 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 nextarticle 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 withthe 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