, , , , , , , , , , ,

Almost all my sysadmin work so far has been with UNIX, but over the next few months I’ll be playing with Windows Server and Active Directory. Given the role of Active Directory in the administration of many corporate networks, its security is a very important subject to cover.

What exactly is Active Directory? Developed by Microsoft for its Windows Server OS, Active Directory provides an easy method of centrally managing resources and user accounts across a network, and normally this would be a large corporate network with several departments and all kinds of resources. This network can be broken down into several domains. 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.

It isn’t strictly limited to Windows machines either, as there are tools, such as Centrify Express, for integrating UNIX-based systems into an Active Directory. The Centrify site has some excellent tutorials, by the way.

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.

So, the above are some of the possible methods I’ll be looking into more closely.

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.