Identity & Access · Chapter 11 of 16
Kerberos, LDAP and Active Directory
The protocol running inside almost every enterprise on earth, and the four attacks every red team tries first.
Active Directory is thirty years old, runs identity for the overwhelming majority of large organisations, and is the first thing an attacker who lands on a corporate network goes after. Cloud identity has not replaced it; it has been layered on top of it, which means the on-premises weaknesses are now reachable from the cloud and vice versa.
The core idea, in one paragraph
Kerberos exists so that a password is never sent over the network and no service ever needs to know your password. A central Key Distribution Centre — in practice, a domain controller — issues you a ticket-granting ticket after you prove you know your password by encrypting a timestamp with a key derived from it. You then exchange that TGT for individual service tickets, each encrypted with the target service's own key. The service can decrypt its ticket because it holds that key, so it authenticates you without any conversation with the KDC at all.
Two properties follow that explain most of Kerberos' behaviour. It depends critically on synchronised clocks — the default tolerance is five minutes, and clock drift is a classic cause of ‘authentication randomly stopped working’. And whoever holds a service account's key can decrypt tickets for it, which is the foundation of the attacks below.
Service principal names, which are the attack surface
A service is identified by an SPN — MSSQLSvc/db01.corp.com:1433, HTTP/intranet.corp.com. The SPN is registered against the account the service runs as. If that account is a domain user account with a human-chosen password, its key is derived from that password.
This is the single most important fact in AD security, because any authenticated domain user may request a service ticket for any SPN. That is not a bug; it is how the protocol works. The consequence is Kerberoasting.
The four attacks, and the defence for each
Kerberoasting. Request a service ticket for an SPN whose account is a regular user, then crack the ticket's encryption offline. Recovering the password gives you the service account. The defence is not to detect the request — it is indistinguishable from legitimate use. It is to make cracking infeasible: run services as Group Managed Service Accounts, which have 120-character randomly generated passwords rotated automatically, and disable RC4 so tickets use AES. Every human-password service account with an SPN is a standing offer.
AS-REP roasting. Accounts with ‘do not require Kerberos pre-authentication’ set will hand out encrypted material to an unauthenticated requester. The defence is to find them and turn pre-authentication on — it is a single query and there is rarely a legitimate reason for the setting to be off.
Golden ticket. The krbtgt account's key encrypts every TGT in the domain. An attacker who obtains it can mint valid TGTs for any user, including ones that do not exist, with arbitrary group membership and arbitrary lifetime. Changing the password does not help — because AD keeps the previous key, you must reset it twice, with replication completing in between. This is why a domain compromise is usually treated as requiring a rebuild: without the double reset, the attacker retains persistence through every other remediation you perform.
Delegation abuse. Delegation lets a service act as you against another service — a web front end reaching a database as the user. Unconstrained delegation stores your entire TGT on the intermediate host, so compromising that host gives the attacker your TGT and everything you can reach. Constrained delegation limits it to named services; resource-based constrained delegation moves the decision to the target, which is better. The defence is to eliminate unconstrained delegation entirely and to mark sensitive accounts as ‘cannot be delegated’.
NTLM, which is still there and still a problem
NTLM predates Kerberos and remains enabled almost everywhere for compatibility. It is challenge-response over a hash, and it is relayable: an attacker who can coerce a machine into authenticating to them can relay that authentication to a third service and act as the victim, without ever cracking anything.
The practical defences are SMB signing and LDAP channel binding — which stop the relay — and, eventually, disabling NTLM. Microsoft has been moving toward that for years and the blocker is invariably an old application nobody owns. Finding and cataloguing NTLM usage before disabling it is the actual work, and it is a good example of the difference between knowing the answer and being able to deliver it.
LDAP, and what it is actually for
LDAP is the directory query protocol — it is how you read the tree of users, groups, computers and their attributes. It is also, unfortunately, an authentication mechanism: an ‘LDAP bind’ sends a username and password to the directory to check them.
- Simple bind over plaintext LDAP sends the password in the clear. This still happens. LDAPS or StartTLS is the minimum, and channel binding on top of that.
- Anonymous bind may allow enumeration of the entire directory. Check it.
- LDAP injection is a real vulnerability class in applications that build filter strings from user input, exactly analogous to SQL injection and much less well known.
- Application LDAP binds are how a great many legacy applications do authentication, and each one is a service account with a password in a configuration file somewhere. Migrating these to SAML or OIDC is most of what an enterprise identity modernisation programme actually consists of.
Hybrid identity, and why it is where the risk now lives
Almost no organisation runs purely on-premises or purely in the cloud. The synchronisation between the two — Entra Connect and its successors — creates a bridge, and a bridge is bidirectional risk.
- Password hash synchronisation sends a hash of the password hash to the cloud directory. Convenient and resilient; means the cloud holds derived credential material.
- Pass-through authentication keeps validation on-premises via an agent. No credential material in the cloud; the agent becomes a critical dependency.
- Federation hands authentication to an on-premises IdP such as ADFS. Most control, most operational burden, and the ADFS token-signing key becomes an extremely high value target — an attacker who obtains it can forge tokens for any user, which is the cloud analogue of a golden ticket and has been used in real, large-scale intrusions.
- The synchronisation account itself is one of the most privileged objects in the estate and is frequently excluded from the controls applied to named admins. Ask about it.
The strategic point worth making: cloud identity did not remove on-premises risk, it connected it. A domain compromise now frequently becomes a cloud tenant compromise, and the path runs through synchronisation and federation components that sit outside most organisations' privileged-access programmes.
Check yourself