Kerberos and NTLM authentication

Overview

In What is Active Directory? you saw that Active Directory (AD) is the central identity store for most corporate Windows networks: it holds users, computers, and groups, and it decides who is allowed to do what. This lesson zooms in on the single most important job AD performs every second of every day: authentication — proving that a user or computer really is who it claims to be.

Security objective. The asset you are protecting is domain identity: user credentials, service-account passwords, Kerberos tickets, and above all the krbtgt key that underwrites the whole domain. The threat is an attacker who already has a low-privilege foothold (a stolen laptop, a phished user, one compromised host) and wants to escalate to full domain control. By the end you will be able to detect the log signatures of the classic AD authentication attacks and prevent them by hardening service accounts, encryption types, and the legacy NTLM surface.

AD authenticates with two protocols that have coexisted for decades:

• NTLM — an older challenge-response protocol. It is still everywhere because of backward compatibility, and it is the source of pass-the-hash and NTLM relay.
• Kerberos — the default and preferred protocol since Windows 2000. A central authority hands out time-limited tickets so the user does not re-prove their password to every service. It is the source of Kerberoasting, AS-REP roasting, pass-the-ticket, and the Golden Ticket.

Here is the idea that ties the whole lesson together, and the reason these attacks exist: the cryptography in NTLM and Kerberos is sound. Attackers almost never break the math. Instead, they abuse the fact that the secret keys used by both protocols are derived from account passwords. A weak service-account password, a stolen hash sitting in memory, or a captured ticket gives an attacker a working credential without ever cracking an algorithm. Once you internalize that, the named attacks stop looking like magic and start looking like predictable consequences of the design.

This is a defensive, concept-track lesson that builds directly on the identity model from What is Active Directory?. You will not run exploits against anyone. The goal is to understand the flows well enough to harden them and to recognize the telltale signs of abuse in logs — always in a lab you own or are explicitly authorized to test.

Why it matters

Active Directory is the backbone of identity in the vast majority of enterprises, hospitals, governments, and universities. If an attacker compromises AD authentication, they typically own the whole organization — every file share, mailbox, and server trusts the domain. That is why domain-compromise incidents are among the most expensive breaches to recover from: rebuilding trust in a domain can mean resetting every credential and, in the worst case, rebuilding the forest.

Nearly every famous AD attack is a direct consequence of how NTLM and Kerberos use password-derived secrets:

For a defender, this matters because the fixes are concrete and within reach: strong, long, randomly generated service-account passwords (ideally Group Managed Service Accounts), disabling legacy NTLM where possible, enforcing SMB signing and LDAP channel binding, requiring AES, and watching the right event logs. In real authorized work, blue teams write these exact detections into their SIEM, incident responders rotate krbtgt after a breach, and penetration testers verify (under written scope) that the controls actually hold. You cannot defend what you do not understand — so we start with the flows.

Core concepts

Each protocol and each attack is taught separately below. Read the flow first, then the attack that the flow makes possible. Before the details, here is the map of what you are defending.

Threat model

ASSETS                          ENTRY POINTS                 TRUST BOUNDARY
- krbtgt key (domain god)       - any domain user account     [ Domain users ]
- service-account passwords     - one compromised host            |  request tickets / auth
- user NTLM hashes / tickets    - relayed NTLM authentication     v
- Domain Admin credentials      - IP-based/legacy NTLM apps    [ Domain Controller / KDC ]
                                                                   |  holds krbtgt + every key
                                                                   v
                                                               [ FULL DOMAIN ]

The critical boundary: any authenticated domain user can request tickets — that is by design. So a "low-privilege foothold" is enough to start Kerberoasting or AS-REP roasting. Design your defenses assuming the attacker already holds an ordinary user account.

1. NTLM: challenge-response on a password hash

Definition. NTLM (NT LAN Manager) is a challenge-response authentication protocol. The client proves it knows the user's password hash without sending the password or the hash itself across the network.

How it works internally. The server sends a random challenge (a nonce). The client computes a response by keying an HMAC with the user's NTLM hash over that challenge and sends back the response. The server (or the Domain Controller it forwards to) computes the same thing and checks for a match.

Client                                  Server / DC
  |  1. NEGOTIATE  ----------------------> |
  |  2. CHALLENGE (random nonce) <-------- |
  |  3. AUTHENTICATE                       |
  |     response = f(NTLM_hash, nonce) --> |
  |                                        | verify response
  |  4. OK / DENY <----------------------- |

Key insight: because the response is computed from the hash, the hash behaves exactly like the password. Whoever holds the hash can produce a valid response.

When it is used: local logons, older apps, connections by IP address instead of hostname, and fallback when Kerberos is unavailable. When NOT to rely on it: new deployments — prefer Kerberos and restrict/disable NTLM where you can.

Common pitfall (defender): assuming "we use Kerberos" means NTLM is gone. NTLM silently kicks in for IP-based connections and many legacy apps. You must measure NTLM usage (audit logging) before disabling it.

Knowledge check: Why does NTLM never put the actual password on the wire, yet still let a thief who only has the hash log in? (What insecure assumption does "the password never travels" hide?)

2. Pass-the-Hash (NTLM)

Definition. An attacker who has obtained a user's NTLM hash (e.g., from LSASS memory on an already-compromised machine) authenticates as that user by feeding the hash directly into the challenge-response, with no need to crack the password.

Why it works: see concept 1 — the protocol only ever needs the hash. Cracking is unnecessary.

Defensive levers: prevent the hash from being stolen in the first place (Credential Guard, LSASS protection, no privileged accounts logging into untrusted machines), and limit lateral movement (unique local admin passwords via LAPS, a tiered admin model).

3. NTLM relay

Definition. Instead of cracking or replaying a hash, the attacker positions themselves in the middle, captures a victim's NTLM authentication, and relays it to a third service, authenticating as the victim there.

Victim --(NTLM auth)--> [Attacker relay] --(same auth replayed)--> Target service
                                                                  (acts as victim)

Defenses: message signing (SMB signing, LDAP signing) and channel binding (Extended Protection for Authentication, EPA) bind the authentication to the specific connection, so a relayed copy no longer validates.

Knowledge check (find-the-bug): A team enables SMB signing on file servers but leaves LDAP signing / channel binding off on the Domain Controllers. Which relay path is still open, and which log would show the relayed bind?

4. Kerberos: tickets instead of repeated passwords

Definition. Kerberos is a ticket-based protocol. A trusted third party on the DC — the Key Distribution Center (KDC) — issues time-limited tickets so the user authenticates once and then presents tickets to services.

The three exchanges:

        (1) AS-REQ / AS-REP        (2) TGS-REQ / TGS-REP
Client ------------------> KDC    Client ------------------> KDC
   |  proves password,   (AS)        |  presents TGT,      (TGS)
   |  receives TGT  <-----+          |  asks for service   |
   |                                 |  ticket, gets TGS <-+
   |
   |        (3) AP-REQ / AP-REP
   +----------------------------> Service
      presents TGS; service trusts it

1. AS exchange: client proves knowledge of its password and receives a TGT (Ticket-Granting Ticket). The TGT is encrypted with the krbtgt account's key.
2. TGS exchange: client presents the TGT and asks for a service ticket (TGS) for a specific service (named by its SPN, Service Principal Name). The TGS is encrypted with the service account's key.
3. AP exchange: client presents the TGS to the service. The service decrypts it with its own key and trusts the contents.

The crack in the armour: every ticket is encrypted with a key derived from some account's password — the user's, the service's, or krbtgt. Each of the attacks below targets one of those keys.

Common pitfall: thinking ticket times don't matter. Kerberos depends on synchronized clocks (default 5-minute skew). Misconfigured time is the #1 cause of "Kerberos suddenly broke."

5. Kerberoasting (Kerberos)

Definition. Any authenticated domain user can request a TGS for a service account (one with an SPN). That ticket is encrypted with the service account's password hash. The attacker takes the ticket offline and brute-forces the password against it — no further interaction with AD.

Why it works: the encryption is fine, but if the service-account password is weak, an offline guess-and-check eventually matches. RC4-encrypted tickets crack far faster than AES.

Defense (this is the lesson's headline fix): use Group Managed Service Accounts (gMSA) or very long random passwords (25+ chars) for service accounts, require AES encryption types, apply least privilege, and alert on bulk/unusual TGS requests (Event ID 4769).

6. AS-REP roasting (Kerberos)

Definition. If an account has Kerberos pre-authentication disabled, the KDC will return AS-REP material encrypted with the user's password hash without the requester proving anything first. An attacker requests it for such accounts and cracks it offline.

Defense: ensure pre-authentication stays enabled (it is by default); audit for the rare accounts where DoesNotRequirePreAuth was turned on, and alert when it is flipped.

7. Pass-the-Ticket and Golden Ticket (Kerberos)

Pass-the-ticket: tickets are bearer tokens — whoever holds a valid TGT/TGS can use it until it expires. A stolen ticket lifted from a compromised host's memory grants the victim's access.

Golden Ticket: if the attacker has obtained the krbtgt account's key, they can forge a TGT for any user with any privileges and any (long) lifetime. Because every TGT is validated against krbtgt, the forged ticket is accepted — effectively domain god-mode. The standard remediation after krbtgt compromise is to rotate the krbtgt password twice.

Knowledge check: Why is recovering the krbtgt key so much more dangerous than recovering one ordinary user's hash? And why are all of these only ever practiced in an authorized lab?

Syntax notes

These protocols are not something you "type," so instead here is the vocabulary you must read fluently when looking at logs, diagrams, and tools. Treat this as the field guide for the rest of the lesson.

KDC   Key Distribution Center  — the service on the DC that issues tickets
AS    Authentication Service   — issues the TGT (step 1)
TGS   Ticket-Granting Service  — issues service tickets (step 2)
TGT   Ticket-Granting Ticket   — proves you authenticated; encrypted with krbtgt key
TGS   (also) the service ticket itself, for one service
SPN   Service Principal Name    — unique name of a service, e.g. MSSQLSvc/db01.corp.local:1433
krbtgt special account whose key signs/encrypts every TGT in the domain
NTLM  NT LAN Manager           — legacy challenge-response protocol
hash  the NTLM hash of a password; functions as a credential in NTLM
EPA   Extended Protection for Authentication — channel binding that defeats relay
gMSA  Group Managed Service Account — AD auto-manages a long, random, rotated password

Annotated example of an SPN, which is what a Kerberoasting request targets:

MSSQLSvc / db01.corp.local : 1433
  |          |               |
  service    host the        port (optional)
  class      service runs on

Reading a Kerberos event tells you which exchange happened:

4768  AS exchange   — a TGT was issued (initial logon)
4769  TGS exchange  — a service ticket was issued (name + SPN + encryption type logged)
4771  Kerberos pre-authentication failed (bad password / roasting probes)

You will use these IDs in the detection section. The encryption type recorded in a 4769 event (RC4 vs AES) is itself a signal: an RC4 request for an AES-capable account is suspicious.

Lesson

AD authentication uses two protocols, and most AD attacks abuse how they work.

NTLM (legacy, challenge-response)

The client proves it knows the password's hash through a challenge-response exchange, without ever sending the password. This design has two consequences:

• Pass-the-Hash. The hash itself is the credential. A stolen NTLM hash authenticates the attacker without needing to crack it.
• NTLM relay. An attacker relays a victim's authentication to another service (often over SMB) and acts as that victim.

Kerberos (default, ticket-based)

Instead of sending credentials to each service, the client obtains tickets from the DC's Key Distribution Center (KDC).

The flow has three steps:

1. Authenticate to the KDC to get a TGT (Ticket-Granting Ticket).
2. Present the TGT to get a service ticket (TGS) for a specific service.
3. Present the TGS to the service itself.

Tickets are encrypted with key material derived from account passwords. That is the crack in the armour:

• Kerberoasting. Request a TGS for a service account. It is encrypted with that account's password hash, which can then be cracked offline.
• AS-REP roasting. Accounts with Kerberos pre-authentication disabled hand out crackable material without any authentication.
• Pass-the-Ticket / Golden Ticket. Stolen or forged tickets grant access. A Golden Ticket forged with the krbtgt key is effectively domain god-mode.

Takeaway

You rarely "break" the cryptography. Instead, you abuse the fact that password-derived secrets back the tickets and hashes. As a result, weak service-account passwords and exposed hashes or tickets can lead to full domain compromise.

Code examples

There is no single "vulnerable line of C" here — the vulnerability lives in configuration. So the INSECURE -> SECURE -> VERIFY shape below is expressed as (1) an insecure service-account setup, (2) the hardened replacement, and (3) checks that prove the fix. Everything runs against a domain you own or administer.

(1) Insecure setup

# WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.
# Anti-pattern: a service account with a short, human-chosen password, RC4 allowed,
# pre-auth disabled "to make an old app work", and Domain Admin membership.
New-ADUser -Name 'svc-web' -AccountPassword (ConvertTo-SecureString 'Summer2026!' -AsPlainText -Force) -Enabled $true
Set-ADUser  -Identity 'svc-web' -ServicePrincipalNames @{Add='HTTP/web01.corp.local'}
Set-ADAccountControl -Identity 'svc-web' -DoesNotRequirePreAuth $true   # enables AS-REP roasting
Add-ADGroupMember -Identity 'Domain Admins' -Members 'svc-web'          # weak pw now = domain takeover

Why it is dangerous: svc-web has an SPN (Kerberoastable), a guessable password, RC4 tickets crack fast, pre-auth is off (AS-REP roastable), and Domain Admin means a single cracked password is game over.

(2) Secure fix

# --- AUTHORIZED LAB ONLY: run against a domain you own/administer ---
# One-time prerequisite for gMSA (safe to run once): create the KDS root key.
# Add-KdsRootKey -EffectiveImmediately   # in production, allow 10h replication instead

# Replace the risky account with a Group Managed Service Account:
# AD generates and rotates a 120+ character random password automatically.
New-ADServiceAccount -Name 'gmsa-web01' -DNSHostName 'web01.corp.local' `
  -PrincipalsAllowedToRetrieveManagedPassword 'WebServers' `
  -KerberosEncryptionType AES128, AES256          # no RC4
Set-ADServiceAccount -Identity 'gmsa-web01' -ServicePrincipalNames @{Add='HTTP/web01.corp.local'}

# Keep pre-authentication ENABLED (this is the default; assert it explicitly):
Set-ADAccountControl -Identity 'gmsa-web01' -DoesNotRequirePreAuth $false
# Least privilege: the gMSA is NOT a member of any privileged group.

(3) Verify the fix rejects bad state and accepts good state

# CHECK A — no account still has pre-auth disabled (should return NOTHING):
Get-ADUser -Filter { DoesNotRequirePreAuth -eq $true } -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName

# CHECK B — inventory Kerberoasting surface and confirm passwords are managed/strong:
Get-ADUser -Filter { ServicePrincipalName -like '*' } -Properties ServicePrincipalName, PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet, ServicePrincipalName

# CHECK C — confirm the gMSA is usable on its host and no longer a Domain Admin:
Test-ADServiceAccount -Identity 'gmsa-web01'                 # expect: True on WebServers
Get-ADGroupMember 'Domain Admins' | Select-Object SamAccountName  # expect: no gmsa/svc account

# CHECK D (detection) — read recent service-ticket requests (Event ID 4769) on the DC.
#   One account requesting many distinct SPNs quickly = a Kerberoasting signal.
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769 } -MaxEvents 50 |
  Select-Object TimeCreated,
                @{N='Account';     E={ $_.Properties[0].Value }},
                @{N='ServiceName'; E={ $_.Properties[2].Value }},
                @{N='EncType';     E={ $_.Properties[5].Value }}   # 0x17=RC4, 0x12=AES256

What it does. The insecure block creates the exact conditions the attacks need. The secure block removes them: a gMSA gives a 120+ char auto-rotated password (weak-password Kerberoasting can no longer succeed), AES-only tickets remove the fast RC4 path, pre-auth stays on (no AS-REP roasting), and least privilege caps the blast radius. The verify block proves it: Check A must return nothing, Check C must show True and no privileged membership, and Check D shows you the detection surface.

Expected output (shape, not exact values). Check A returns an empty result in a healthy domain. Check B lists each service account with its SPN(s) and PasswordLastSet (stale dates on human-managed accounts are a red flag). Check C prints True and a Domain Admins list free of service accounts. Check D prints a small table of recent service-ticket requests including the encryption type.

Edge cases / requirements. Get-ADUser, New-ADServiceAccount, and Test-ADServiceAccount need the RSAT ActiveDirectory module and directory read access. gMSA creation requires the KDS root key to exist first. Get-WinEvent for 4769 requires "Audit Kerberos Service Ticket Operations" to be enabled and must run where those events live (the DC or your SIEM), not the client.

Line by line

Here is the trace of a normal Kerberos logon followed by where each attack would slot in. Follow the ticket as it changes hands.

Now map the attacks onto this trace:

• AS-REP roasting intercepts at step 2 when pre-authentication is off — the KDC returns the AS-REP (encrypted with alice's key) even though step 1's proof was skipped. The attacker cracks alice's password from it offline.
• Kerberoasting abuses step 4: any authenticated user can ask for the db01 service ticket, which is encrypted with the service account's key. Offline cracking recovers a weak service-account password. This is why step 4 logs the encryption type — an RC4 request for an AES-capable service is a tell.
• Pass-the-ticket steals the TGT from step 2 (or the service ticket from step 4) out of a compromised host's memory and replays it.
• Golden Ticket forges step 2 entirely: with the krbtgt key, the attacker mints a TGT for any user with any group memberships — and step 3 will happily accept it because it validates against krbtgt.

The reason the result is "full compromise" in the Golden Ticket case is that the KDC trusts anything that decrypts with the krbtgt key, and the attacker now holds that key. Rotating one user's password fixes one account; rotating krbtgt (twice) is the only thing that invalidates every forged TGT.

Common mistakes

Mistake 1 — "We use Kerberos, so NTLM doesn't matter." WRONG because Windows silently falls back to NTLM for IP-based connections and many legacy apps, leaving pass-the-hash and relay alive. Recognize/prevent: enable NTLM audit logging ("Network Security: Restrict NTLM: Audit") and review which clients/servers still use it before you try to restrict it.

Mistake 2 — Treating Kerberoasting as a crypto-breaking attack. WRONG: the encryption is not broken. The attacker is doing an offline password guess against a ticket. Correct framing: the only thing that makes it work is a weak service-account password (made faster by RC4). The fix is a strong/managed password (gMSA) plus AES, not "better crypto."

Mistake 3 — Rotating krbtgt only once after a suspected Golden Ticket. WRONG: the KDC keeps the current and previous krbtgt key for ticket validation, so one rotation still accepts forged tickets. Correct version: rotate the krbtgt password twice, with a delay between (long enough for AD replication and for legitimate tickets to expire) so both the current and previous keys are new.

Mistake 4 — Giving service accounts Domain Admin "to make it work." WRONG: a Kerberoasted weak password on a Domain Admin service account hands over the domain. Correct version: least privilege for service accounts, and never make them members of highly privileged groups.

Mistake 5 — Disabling pre-authentication for an app's convenience. WRONG: it directly enables AS-REP roasting. Correct version: keep pre-auth enabled; if an app truly needs an exception, isolate that account with an extremely strong password and tight monitoring.

Mistake 6 — "The vulnerability scan passed, so we're secure." WRONG: a clean scan means known signatures did not fire; it does not prove weak service-account passwords, RC4, or NTLM fallback are gone. Nothing is ever "completely secure." Correct version: measure the specific attack surface (SPN accounts, pre-auth flags, encryption types, NTLM usage) and verify each control, as in the code section.

Debugging tips

These are operational/diagnostic issues a learner or admin hits when working with these protocols in a lab.

"Kerberos isn't being used at all — everything is NTLM."

• Cause: connecting by IP address, or a missing/duplicate SPN. Kerberos needs a correctly registered SPN to find the service.
• Steps: check for duplicate SPNs (setspn -X); connect by hostname, not IP; confirm DNS resolves the host.

"Clock skew too great" / random Kerberos failures.

• Cause: client and DC clocks differ by more than the allowed skew (default 5 minutes).
• Steps: sync time (the DC holding the PDC emulator role is the authority); verify the time service is healthy.

"My gMSA creation fails."

• Cause: the KDS root key does not exist yet.
• Steps: create it (Add-KdsRootKey) and, in a lab, allow it to take effect; only then create the gMSA. On the target host, confirm with Test-ADServiceAccount.

No 4769/4768 events appear when hunting Kerberoasting.

• Cause: Kerberos auditing isn't enabled, or you're reading the wrong machine.
• Steps: enable "Audit Kerberos Service Ticket Operations" (and Authentication Service), and read events on the DC (or your SIEM), not the client.

"My detection alerts constantly" (false positives).

• Cause: vulnerability scanners, legitimate SPN-heavy apps (e.g., some monitoring tools), or a user opening many services at logon can all generate bursts of 4769.
• Steps: baseline normal behavior per account, tune the threshold, and prioritize RC4-for-AES-capable and never-before-seen SPN combinations rather than raw count alone.

Questions to ask when something "doesn't authenticate":

1. Is this NTLM or Kerberos? (Check the security event — 4768/4769 = Kerberos.)
2. Is there a valid, unique SPN for the service?
3. Are the clocks in sync?
4. Is the account/ticket expired, disabled, or locked out?
5. Does the account have the privileges the service actually needs?

Memory safety

Security & safety

Authorization & ethics (read first). Everything in this lesson is for defense. Only ever run enumeration, hardening, or detection against a domain you own or are explicitly authorized to test — a local lab, a container-based AD, an intentionally vulnerable practice VM, or an authorized engagement with written scope. Do not attempt any of these techniques against systems you do not control. The named attacks are described so you can prevent and detect them, not perform them; this lesson deliberately contains no working exploit steps.

Authorization checklist (before any lab work):

• Written permission / scope covering the exact domain, hosts, and accounts.
• The environment is isolated (lab network, snapshot/VM you can revert).
• A point of contact and an agreed stop condition.
• Data-handling rules: no real credentials leave the lab; use placeholders like API_KEY=<development-placeholder>.

Threat model (recap).

ASSETS                         ENTRY POINTS                TRUST BOUNDARY
- krbtgt key (domain god)      - any domain user account    [ Domain users ]
- service-account passwords    - a single compromised host      |  request tickets / auth
- user NTLM hashes/tickets     - relayed NTLM auth              v
- Domain Admin credentials                                  [ Domain Controller / KDC ]
                                                                |  holds krbtgt + all keys
                                                                v
                                                            [ FULL DOMAIN ]

The critical boundary: any authenticated domain user can request tickets (by design), so a low-privilege foothold is enough to start Kerberoasting/AS-REP roasting. Your defenses assume the attacker already has a normal user.

Defensive practices (at least as detailed as any attack above):

• Service accounts: prefer gMSA (auto-rotated, 120+ char random passwords). Where gMSA is impossible, use 25+ character random passwords and least privilege — never Domain Admin.
• Encryption types: require AES for Kerberos; disable RC4 where feasible (RC4-encrypted tickets crack faster).
• Pre-authentication: keep it enabled everywhere; audit for exceptions and alert when DoesNotRequirePreAuth is set.
• NTLM: measure usage, then restrict/disable legacy NTLM; enforce SMB signing, LDAP signing, and channel binding (EPA) to defeat relay.
• Credential theft: enable Credential Guard / LSASS protection, deploy LAPS for unique local admin passwords, and adopt a tiered admin model so Domain Admins never log on to ordinary workstations.
• krbtgt: rotate periodically and twice after suspected compromise.

Detection / logging — what to log (never log secrets):

• Log Kerberos 4768 (TGT) and 4769 (service ticket) events with: timestamp, source account/host, target SPN, encryption type, and result. Add a correlation ID so related events can be tied together.
• Alert on one account requesting many distinct SPNs quickly (Kerberoasting) or requests using RC4 for AES-capable accounts.
• Alert on AS-REP requests for accounts that should require pre-auth, and on any account flipped to DoesNotRequirePreAuth.
• Alert on TGTs with abnormally long lifetimes or for nonexistent users (Golden Ticket signs), and on repeated 4771 pre-auth failures (password-spray / roasting probes).

What to NEVER log: passwords, NTLM hashes, Kerberos ticket key material, the krbtgt key, session keys, or unneeded PII. Log metadata (who, when, which SPN, encryption type, result) — never the secret itself.

How false positives arise: vulnerability scanners, SPN-heavy monitoring agents, and users opening many services at logon can all mimic bulk 4769. Baseline per account and weight anomalous encryption type and never-seen SPNs over raw volume.

Mitigation verification (how to test the fix):

• After enabling SMB/LDAP signing + channel binding, confirm relayed authentication no longer validates in your lab and that legitimate clients still connect.
• After moving to gMSA, confirm the service still starts (Test-ADServiceAccount returns True) and that the password is now managed/rotated.
• After re-enabling pre-auth, confirm AS-REP material is no longer returned without proof, and that the dependent app still authenticates.
• Re-run the code section's Check A (no pre-auth-disabled accounts) and Check C (no service account in Domain Admins) — both should stay clean over time.

Lab cleanup / reset: revert the VM snapshot, or remove the practice objects you created (Remove-ADServiceAccount 'gmsa-web01', Remove-ADUser 'svc-web'), and disable any extra auditing you turned on. Never leave intentionally weak accounts (like svc-web above) enabled once the exercise ends.

One correction to keep sharp: decoding a ticket or a token to read its fields is not the same as verifying it — verification means the KDC/service key actually decrypts and validates it. Reading structure proves nothing about authenticity.

Real-world uses

Where this shows up. Every Windows domain — corporate offices, hospitals, universities, manufacturing plants — authenticates day-to-day with Kerberos and falls back to NTLM. Single sign-on to file shares, intranet sites, SQL Servers, and Exchange all ride on Kerberos tickets. Blue teams in security operations centers (SOCs) hunt for the exact 4768/4769 patterns described here, and incident responders rotate krbtgt after a breach. Red teams and penetration testers (under written authorization) test these paths so organizations can close them, then hand over a report with remediation and retest steps.

Professional best-practice habits.

Beginner rules:

• Always know whether a connection is using Kerberos or NTLM before reasoning about its security.
• Give every service account a strong, unique password and the minimum privileges it needs.
• Keep clocks synchronized; keep pre-authentication enabled.
• Never log secrets; log metadata with timestamps and a correlation id.

Advanced rules:

• Standardize on gMSA for service accounts and enforce AES Kerberos encryption.
• Treat the krbtgt account as a crown jewel: monitor it, rotate it on schedule, and rotate twice on suspicion.
• Build detections for Kerberoasting (bulk/anomalous 4769, RC4-for-AES), AS-REP roasting, and Golden/forged tickets, and feed them into your SIEM with tuned alerting and baselines to control false positives.
• Drive down NTLM usage with audit-then-restrict, and enforce signing / channel binding across SMB and LDAP.
• Adopt a tiered administration model and Credential Guard so high-value hashes never sit on low-trust hosts.
• Assume defense-in-depth: no single control makes a domain "completely secure," so layer prevention, detection, and rapid response.

Practice tasks

Work through these in order. They are conceptual/defensive — no attacking third-party systems. Use an authorized lab domain for anything hands-on, and follow the authorization checklist in Security & safety.

Beginner 1 — Label the flow. Objective: prove you can name every step of Kerberos. Requirements: draw the three exchanges (AS, TGS, AP). For each, write who sends what, which ticket results, and which account's key encrypts that ticket. Hint: there are exactly three keys involved across a normal logon — the user's, the service's, and krbtgt. Concepts: Kerberos flow, TGT, TGS, SPN.

Beginner 2 — NTLM vs Kerberos table. Objective: contrast the two protocols. Requirements: build a table comparing them on: credential used, whether a third party (KDC) is involved, what gets sent on the wire, and which two attacks each enables. Hint: one is challenge-response on a hash; the other is ticket-based. Concepts: NTLM, Kerberos, pass-the-hash, Kerberoasting.

Intermediate 1 — Attack-to-root-cause mapping. Objective: connect each attack to the design property it abuses, its primary defense, and its detection. Requirements: for pass-the-hash, NTLM relay, Kerberoasting, AS-REP roasting, and Golden Ticket, write (a) the root cause, (b) one concrete defense, (c) one log/event you would watch. Input/output example: Kerberoasting -> root: TGS encrypted with service-acct hash -> defense: gMSA/long random pw + AES -> watch: bulk 4769 (esp. RC4) from one account. Concepts: all attacks; detection.

Intermediate 2 — Lab inventory and remediation (defensive). Objective: measure attack surface in an authorized lab, then fix one finding and verify it. Requirements: using the lesson's PowerShell, list all SPN-holding service accounts and any accounts with pre-auth disabled. Pick one over-privileged or weak account, harden it (least privilege or gMSA / re-enable pre-auth), then re-run the check to prove the finding is gone. Constraints: read-only enumeration first; make changes only on a lab you own; revert the snapshot when done. Hint: PasswordLastSet and group membership are your risk indicators; Check A/C in the code section are your verification. Concepts: Kerberoasting/AS-REP surface, least privilege, mitigation verification.

Challenge — Design a detection + remediation runbook. Objective: turn understanding into an operational plan. Requirements: write a one-page runbook that (1) lists the events/anomalies that indicate Kerberoasting, AS-REP roasting, and a Golden Ticket; (2) specifies what to log and explicitly what not to log; (3) gives the remediation steps for a suspected krbtgt compromise (including the double-rotation and why); and (4) describes how you would verify each mitigation in the lab, plus how you would tune out false positives. Constraints: defensive only; no exploit instructions; lab-only, with a defensive conclusion (remediate + verify). Hint: structure it as Detect -> Contain -> Remediate -> Verify. Concepts: everything in this lesson.

Summary

• AD authenticates with two protocols: NTLM (challenge-response on a password hash) and Kerberos (ticket-based, via the KDC).
• Kerberos flow: AS exchange -> TGT (encrypted with the krbtgt key); TGS exchange -> service ticket (encrypted with the service account's key); AP exchange -> the service trusts the ticket.
• The unifying idea: attackers almost never break the cryptography. They abuse the fact that hashes and tickets are derived from passwords.
• This single fact explains pass-the-hash and NTLM relay (NTLM), and Kerberoasting, AS-REP roasting, pass-the-ticket, and the Golden Ticket (Kerberos).
• Most important defenses: strong/managed service-account passwords (gMSA), least privilege, AES encryption, keep pre-auth on, restrict NTLM and enforce SMB/LDAP signing + channel binding, protect and rotate krbtgt (twice after compromise), and monitor 4768/4769 events.
• Detection & logging: log who/when/which SPN/encryption type/result with a correlation id; never log passwords, hashes, ticket keys, or the krbtgt key; tune for false positives (scanners, SPN-heavy apps).
• Common mistakes: assuming NTLM is gone, calling Kerberoasting a crypto break, rotating krbtgt only once, giving service accounts Domain Admin, and trusting a clean scan as proof of security.
• Remember: any authenticated domain user can request tickets by design, so harden assuming the attacker already has a foothold — verify every fix, and only ever practice in an authorized lab.

Practice with these exercises

• Constant-time equality
• Which compare is timing-safe?