Address Book for Some, Reconnaissance for Others

Active Directory's most important function, object lookup, is the primary goal of any LDAP directory service. Microsoft also wanted to offer a kind of enterprise address book in AD where employees could look up internal information. The search function in Windows 2000 and XP had a Search in directory widget to allow users to search the AD from the Start menu. This feature was rarely used because, first, users could not do much with the objects they found, and, second, widespread email and groupware products such as Exchange or Lotus Notes already offered address books at that time that went far beyond the search widget in the Start menu in terms of convenience and performance. Moreover, these application-specific address books do not require the end user to have direct access to the LDAP directory underpinning them.

In the vast majority of cases, normal users do not need to be able to read the entire directory (domain or even forest) with the global catalog. Unfortunately, this is precisely the "view" that AD grants every member of the Authenticated Users group by default. Besides the objects themselves, the scope of attributes that can be read by default is also problematic – to the extent that it is often claimed that everyone is allowed to read everything in AD.

A large part of these excessive rights (e.g., the ability to read the userAccountControl attribute of another user object) is granted by the Pre-Windows 2000 Compatible Access group. After the installation of an AD domain, and even on Windows Server 2025, the Authenticated Users group is a member (Figure 2). In many organizations, removing this membership does not cause any disruptions to operations.

Figure 2: The Pre-Windows 2000 Compatible Access group gives users substantial read authorizations and should be avoided.

However, some applications require selected users to have access to certain attributes of other objects. In 99 percent of these cases, this requirement is attributable to outdated software components that still require an NT domain. In this case, you need to organize the authorizations more carefully and first remove them for Authenticated Users and Pre-Windows-2000-Compatible Access from all OUs and containers that contain privileged objects; then, grant these permissions to any admin groups necessary, if you have not already done so. No normal user needs to be able to list administrators, highly privileged groups, and Tier 0 systems. Also, consider the permissions of the AdminSDHolder container.

The second step is to clear out the Pre-Windows 2000 Compatible Access group. If it turns out that some applications still require permissions granted by it, you can add the required machines or users again. If it unexpectedly turns out that an application still needs these authorizations for all standard users, you can set up a special group to grant them, and you can then delete the group in one fell swoop after you have finally removed the obsolete applications from your AD.

The third measure is to restrict attribute visibility further for authenticated users. You will also want to look at the AD configuration partition, which again contains much information that is of interest to a potential attacker but is unimportant to a normal user.

However, be careful: The Windows Network Policy Server role needs some of the permissions granted by the Pre-Windows 2000 Compatible Access group, so you will need to grant the required read permissions to the machines involved.

Try to work exclusively with Allow permissions, which do not just apply to permissions in Active Directory, but to all authorizations in Windows. If this route is not possible and you need to go for Deny instead, you can use the list object mode to control visibility [7] in a granular way. Note that in large environments with deep OU hierarchies, enabling list object mode will generate a noticeable additional load on the domain controllers.

Although restricting visibility effectively impedes initial reconnaissance by cybercriminals, it can also be used against you as a defensive evasion tactic in a later phase of the attack. The attacker will be able to create a highly privileged user and revoke the access rights to this object from all AD principals. This action does not prevent the account from being authenticated and authorized, but it makes the account invisible to normal consoles and scripts. However, some specialist tools [8] can be found that detect hidden admins.

If you use tools in your AD that evaluate the objects and their configurations to assess the attack surface, you need to make sure your hardening activities do not restrict the capabilities of these tools. If necessary, set up a special account for this purpose and authorize it to see everything.

Conclusions

Although many believe the Active Directory service is inherently insecure, I talked about how to achieve a secure AD design by showing where the security pitfalls lie and how you can avoid them. In the next article in this series, I will look at how to harden the authentication process in Active Directory to prevent credential theft, before moving on to look at configuration maintenance and the practical implementation of these strategies in an existing infrastructure.