Five Active Directory misconfigurations that hand over domain admin

Internal assessments have a predictable shape. We are given a low privileged domain account or a foothold on a build machine, and within a day or two the question is not whether we will reach domain admin but which of the usual paths we will take. Active Directory has carried enterprise identity for two decades, and the defaults that made it quick to deploy are still in most estates.

These are the five conditions that most often turn a foothold into full control in the environments we test. Not one is a vulnerability with a CVE attached. All of them are configuration, fixable by the people who already own the domain.

Service accounts with weak passwords and too many rights

Kerberoasting, catalogued in ATT&CK as T1558.003, needs nothing more than a valid domain account. Any user can request a service ticket for an account with a service principal name, and part of that ticket is encrypted with a key derived from the account password, so it cracks offline at whatever speed the hardware allows. The technique is old and still productive because service accounts are created by hand, given a password a person chose, and then dropped into a privileged group so an application stops throwing errors. Group managed service accounts remove the problem outright: a long password rotated by the domain is not going to fall to a wordlist.

Certificate templates that issue a certificate as anyone

Active Directory Certificate Services changed internal testing more than anything else in recent years. The ESC1 case is the clearest: a template that permits client authentication, lets the requester supply the subject alternative name, and is enrollable by a broad group such as Domain Users. Put those three properties together and any account in the domain can request a certificate in the name of an administrator and authenticate with it. Certificates outlive password resets, so this is a persistence mechanism as well as an escalation path. Audit the templates, remove the requester supplied subject flag where it is not needed, tighten enrollment rights and require approval on authentication templates.

Delegation left wider than the application needs

Unconstrained delegation stores the ticket granting ticket of every account that authenticates to the host, so compromising one such server and coercing a domain controller into authenticating to it yields a ticket for the controller itself. Constrained delegation with protocol transition is little better when the service list points somewhere useful, and resource based constrained delegation becomes an escalation path wherever an account can write the relevant attribute on a computer object. Delegation deserves its own audit: list every account and computer configured for it, justify each one, and put accounts that must never be delegated into the Protected Users group.

SMB signing off and NTLM relay still available

NTLM relay has been documented for over twenty years and we still report it. Where SMB signing is not enforced and LDAP channel binding is not required, anyone who can coerce or capture an authentication can relay it to another service and act as that account. Coercion is the easy part, because several remote procedure call interfaces will make a machine account authenticate to an arbitrary host on request, and a poisoned name resolution reply over LLMNR or NBT-NS catches whatever else is looking for a share that does not exist. Disable the legacy name resolution protocols, enforce SMB signing everywhere, require signing and channel binding on LDAP, and treat remaining NTLM authentication as an inventory to retire.

Access control entries nobody has read since the migration

The last path is the least glamorous. Somebody granted a service desk group GenericAll on an organisational unit during a migration, a nested group picked up rights through three levels of membership, or an account holds WriteDacl on a group that is itself a member of a privileged group. None of it appears in a vulnerability scan, and the graph is too large to hold in one person's head, which is why attackers and defenders both query it with tooling. Reused local administrator passwords belong in the same category: one cracked hash becomes access to every machine built from that image.

What to fix first

If the whole list will not happen this quarter, the order below is the one we recommend, weighing the attacker effort each item removes against the work it takes.

• Enforce SMB signing and LDAP channel binding, because relay is the cheapest path available and the fix is configuration rather than redesign.
• Review certificate templates for requester supplied subject names and open enrollment rights, since a single template can undo every other control.
• Move service accounts to group managed accounts, or at minimum to long random passwords, and strip the privileged group membership they never needed.
• Deploy a managed local administrator password solution so that one compromised workstation stays one compromised workstation.
• Run a permissions graph against the domain on a schedule and review the paths into your most privileged tier, not only the group memberships.

None of this requires a new product. It requires somebody to own the identity configuration and to review it more often than the estate changes. When we run an internal assessment we would rather spend the second week on the parts of the network that need original thinking, and where these five are handled, that is how it goes.