1 Kerberos & Its Components
Kerberos is a network authentication protocol heavily associated with Microsoft Active Directory. When an employee signs into a domain-connected Windows machine, Kerberos is normally what lets them reach file servers, database servers, internal web apps, and print servers — without repeatedly retyping their password.
2 Kerberos Authentication Flow
1–2: the workstation authenticates once and gets a TGT. 3–4: it presents the TGT to request a service ticket for the file server. 5: the file server accepts the service ticket — the password is never sent again.
User logs into workstation → Domain Controller → TGT issued
→ User wants file server → TGT presented to Ticket Granting Service
→ Service ticket issued → Service ticket presented to file server → AccessService Principal Names
Kerberos identifies services using Service Principal Names, or SPNs — conceptually HTTP/server.example.com or MSSQLSvc/database.example.com. Incorrect or duplicate SPN configuration can cause authentication failures and sometimes force applications to silently fall back to weaker authentication. SPN troubleshooting is a genuinely common task in enterprise Windows environments.
Kerberos and time
Kerberos depends heavily on time synchronisation — if a client's clock drifts significantly from the domain controller's, Kerberos authentication fails outright. When diagnosing Kerberos problems, DNS health, time synchronisation, and general Active Directory health are all worth checking together.
3 Kerberos Attacks & NTLM Fallback
Kerberos security attacks
Security analysts should recognise: Kerberoasting, AS-REP roasting, Pass-the-ticket, Golden Ticket, and Silver Ticket attacks — understanding these requires understanding legitimate Kerberos first (which is why it comes before this section, not after). Kerberoasting, for example, abuses normal service ticket behaviour to obtain material that may allow offline password cracking against weak service-account credentials. Defences include strong service-account credentials, Managed Service Accounts, privileged-account separation, monitoring abnormal ticket activity, protecting domain controllers, and reducing unnecessary privileges.
NTLM and legacy Windows authentication
Although Kerberos is preferred in modern Active Directory, legacy systems may still fall back to NTLM. This happens when Kerberos can't be used: old applications, systems outside normal domain trust relationships, connecting by IP address instead of hostname, incorrect SPNs, or legacy protocols left enabled. Security teams generally try to reduce NTLM usage because of its weaker security characteristics and history of relay and credential-theft attacks. Recognising why an environment unexpectedly falls back from Kerberos to NTLM is a genuinely useful troubleshooting skill — it's usually one of the five causes above.
4 LDAP
LDAP (Lightweight Directory Access Protocol) lets applications interact with directory services. LDAP is not the same thing as Active Directory — Active Directory is a directory service that supports LDAP among several other protocols, including Kerberos.
LDAP directory structure
LDAP directories are hierarchical:
dc=example,dc=com
|
+-- ou=Users
|
+-- ou=Groups
|
+-- ou=ServersA user might have a Distinguished Name such as cn=Alice Smith,ou=Users,dc=example,dc=com.
LDAP authentication
Older applications frequently authenticate users via an LDAP bind:
Application → LDAP Bind → Directory → Credentials accepted/rejectedApplications may also query attributes — find Alice, retrieve her email, department, groups, and employee ID.
LDAP security
Plain LDAP shouldn't expose credentials or directory information across untrusted networks. Encrypted LDAP (LDAPS, or TLS negotiated during the session) protects it in transit. Don't conflate authentication to LDAP with encrypting the LDAP connection — a correct username and password does not automatically mean the network connection itself is secure.
LDAP in modern companies
LDAP remains common because organisations have decades of applications integrated with directories — Java enterprise applications, VPN systems, Unix infrastructure, network appliances, legacy HR applications, and internal business software. A global company might run Active Directory, Microsoft Entra ID, LDAP, Kerberos, OIDC and SAML simultaneously. Hybrid identity is the normal state, not the exception.
Lab Lab 1 – Inspect Kerberos Tickets
In an Active Directory lab: create a domain user, log into a domain-joined workstation, and access a file server. On Windows, list your current tickets with:
klist🔮 Predict first
Before running klist, predict what you'll see. Then run it and check: do you see a Ticket Granting Ticket? Service tickets for the resources you accessed? Their expiration times? The service principal for each?
Reveal what to try next
Purge the ticket cache in your controlled lab (e.g. klist purge) and try accessing the file server again — observe how a new TGT and service ticket get issued automatically without you retyping your password. This is the entire point of Kerberos: one authentication event backs many subsequent accesses.
Lab Lab 2 – Query an LDAP Directory
Set up a test LDAP-compatible directory (or use an existing lab AD environment) and perform a directory search for a user, a group, an email address, and a department.
🔮 Predict first
What's the difference between an LDAP search and an LDAP bind?
Reveal the answer
A bind is an authentication operation — the client proves who it is to the directory (often the exact step an application performs when "logging a user in via LDAP"). A search is a query operation that retrieves attributes from directory entries and doesn't by itself prove anyone's identity. Repeat your search over an encrypted connection where available, and notice the traffic looks identical in principle — only the transport differs.
Lesson Outcome
You should now be able to describe the Kerberos TGT/service-ticket flow, explain why an environment might unexpectedly fall back to NTLM, name the major Kerberos attacks at a conceptual level, and distinguish an LDAP bind from an LDAP search. Lesson 6 covers RADIUS (the protocol that bridges legacy network gear to modern MFA), certificates and PKI, smart cards, session security, troubleshooting methodology, and closes with a capstone enterprise architecture lab.