Active Directory Security

Developed by Microsoft for its Windows Server operating system, Active Directory provides an easy method of centrally managing resources and user accounts across potentially very large organisations.
In its simplest terms, an Active Directory domain is a group of machines and user accounts that share a central database for authentication and the indexing of network resources, and each domain can have its own system administrator(s). It’s also referred to as a ‘management boundary’, as admin privileges aren’t generally carried across domains.
The database is stored on a system called a ‘Domain Controller’, which can be any specially configured machine running Windows Server and its own entry in the DNS. This is what users see with the ‘Domain‘ field at the login screen.

Requests and queries are handled through the Lightweight Directory Access Protocol (LDAP) on the following ports:

  • 135: RPC endpoint mapping and location service
  • 137: NETBIOS Name Service
  • 138: NETBIOS Datagram Service
  • 139: NETBIOS Session Service

The exception here are Group Policies, which are requested from the Domain Controller over SMB when the user logs in, or every 90 minutes.


Active Directory is also the successor to the Security Accounts Manager (SAM), storing the user and session authentication data on the Domain Controller in a file called NTDS.DIT (%systemroot%\ntds\ntds.dit). This file is a database with several tables that uses the same technology as Microsoft’s Access database, which means it can be more easily read with the right tools. As such, it also stores far more information about user accounts than the older SAM file.
When a user attempts to access resources on another machine in a network, the destination machine queries the Active Directory to determine whether access is authorised. As we’ll see, there are exceptions to this that enable an attacker to compromise an account.

Enumerating Domain Resources

With the Domain Controller indexing all the resources and user accounts on the network, its database becomes a useful resource for anyone wanting to footprint or scope the system, which is what a skilled attacker would do regardless of how easily the network could be owned. Because of its role, the database can also be a single point of failure, and a critical asset that needs protecting. By the same token, it’s something a pen tester should be very careful with. Any cock up on a Domain Controller will cause problems across everything it manages.

As it happens, enumeration of the domain can often done simply by using an LDAP client to query the Domain Controller, one of which (ldp.exe) is included with the freely available Windows Server Support Tools. Windows Server 2000 used to have anonymous sessions enabled by default, and it’s quite possible the system administrator has enabled Guest accounts that don’t require a password. In theory, if there’s a ‘Guest‘ option at the login screen, an anonymous LDAP client session is possible.

But what if the attacker doesn’t have the login details for an authenticated session? There’s a way around that on older systems, for someone with physical access to the machines. Authentication details were cached locally, in case the Domain Controller becomes unreachable for whatever reason. The procedure in this case is pretty much the same for conventional Windows password cracking, but the attacker will instead crack passwords stored at HKEY_LOCAL_MACHINE\SECURITY\CACHE\NL$1 through to NL$10. To counter this, Microsoft has implemented a more secure hashing method than with SAM, so expect it to take far longer.

Active Directory Domain Listing Tool

Another tool that’s useful for enumerating an Active Directory domain is ADTool. There are GUI alternatives available, but this particular one could be integrated into command line scripts, usually for sysadmin purposes.

Active Directory Diagnostic Tool

The Active Directory Diagnostic Tool (ntdsutil.exe) can be used for manipulating the NTDS.DIT file, or copying it over to another location, if the person doing it has physical access to the Domain Controller. Can also be used to reset the Active Directory admin password prior to forcing a reboot into recovery mode.

A Few Security Basics

With the authentication and management being centralised, the most obvious step would be to secure the Domain Controllers, and limit how they can be accessed. One of the most important things to consider here is how administrator-level privileges are assigned. This should be avoided where possible – more admin-level accounts on the system increases the risk of the network being compromised. Ideally the network would have a very small number of trained and experienced system administrators, just enough to ensure every critical action is witnessed and documented.

Another recommended move would be to rename the Administrator accounts, and disable Guest login. The former will make it more time consuming for an attacker to determine which user has administrator privileges, if there are a large number of accounts. The Guest logins typically provide an entry point into the system for the attacker, as well as making network activity difficult to audit. Everyone with access, even if temporary, should be using only their own accounts.

As we’ve seen, an attacker with physical access to the system could theoretically obtain and crack the password files. Ensure the Domain Controllers are in secure environments, where access is regulated and audited, and that nobody can boot either the servers or clients from another OS.