Anonymous LDAP and "Pre-Windows 2000 Compatible Access": closing unauthenticated reads
An attacker who lands on the network without any credentials first tries to find out what the directory is willing to tell them. In a recent, well-maintained domain, almost nothing. But forests that have lived through several generations of Windows often retain compatibility settings that allow accounts and groups to be enumerated anonymously.
Why anonymous access matters
The list of accounts, groups and their members, descriptions that sometimes contain passwords, the domain password policy: this information lets an attacker prepare a password spraying campaign or pick out accounts to target. Obtaining it without any credentials saves them valuable time and spares them from compromising an account first. Closing anonymous access will not stop a determined attack, but it removes the first step.
Anonymous LDAP: dSHeuristics
Since Windows Server 2003, domain controllers refuse anonymous LDAP operations by default, except for reading the rootDSE, which clients need in order to work. This behaviour can be changed through the dSHeuristics attribute of the CN=Directory Service object in the configuration partition: when its seventh character is set to 2, anonymous operations are allowed, subject to the permissions granted on objects.
We still find this value in forests where a legacy application, sometimes long gone, once required it. The dSHeuristics attribute carries other settings as positional characters, so any change must be made with care, altering only the relevant character and recording the original value.
The "Pre-Windows 2000 Compatible Access" group
This built-in group receives broad read permissions on users, groups and the domain object. It exists for services inherited from Windows NT that queried the directory without a user context. What matters is its membership:
- if it contains Anonymous Logon, those read permissions are granted to unauthenticated connections;
- if it contains Everyone, the effect is similar when the setting that makes Everyone permissions apply to anonymous users is enabled;
- if it contains Authenticated Users, the situation is different: this is the usual configuration for recent domains and opens nothing to anonymous users.
Anonymous Logon or Everyone in this group usually stems from promoting the first domain controller with the option for compatibility with pre-Windows 2000 servers. More than twenty years on, it is almost never justified.
A dangerous combination. It is the combination that creates the exposure: anonymous LDAP operations allowed by dSHeuristics, and read permissions granted to Anonymous Logon, either directly or through this group. We always check the two together.
Null sessions and RPC enumeration
LDAP is not the only channel. Anonymous SMB sessions, known as null sessions, allow poorly configured systems to be queried remotely through the SAM and LSA services to enumerate accounts, groups and shares, or to translate security identifiers into names. Several security policy settings govern this access:
- do not allow anonymous enumeration of SAM accounts and shares;
- restrict anonymous access to named pipes and shares, and empty the exception lists;
- do not allow anonymous SID/name translation;
- do not let Everyone permissions apply to anonymous users.
These settings must be applied to domain controllers and member servers alike, through Group Policy, rather than left at values inherited from old security templates.
Cleaning up without surprises
Genuine dependencies are rare, but it is better to identify them before cutting anything off. Before making changes, temporarily enable LDAP interface diagnostic logging on domain controllers, or run targeted network captures, to spot clients that connect without authenticating. Then remove Anonymous Logon and Everyone from the pre-Windows 2000 group, restore the default value of the relevant dSHeuristics character, and harden the null session settings. Finally, confirm from a non-domain machine that anonymous enumeration no longer succeeds.
What an audit checks
- The value of
dSHeuristics, in particular whether anonymous operations are allowed. - The membership of the "Pre-Windows 2000 Compatible Access" group.
- Permissions granted directly to Anonymous Logon or Everyone on directory objects.
- Policy settings for anonymous access on domain controllers and servers.
- A real-world test of anonymous LDAP and RPC enumeration from a non-joined machine.