IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Kerberos & NTLM — how Windows sign-in works
In a Windows domain, Priya types her password once in the morning. Then she opens a dozen file shares and apps without typing it again. The protocol behind this is Kerberos (RFC 4120). Her password never crosses the network. Your goal: explain the ticket steps, and match each classic domain attack to its defense.
- You prove your password once. After that, you show tickets.
- First you get a TGT. Then you trade it for one ticket per service.
- Most domain attacks steal or guess a key, then reuse it.
- Clocks must match within 5 minutes, or Kerberos fails.
Why not send the password?
A cinema with many screens. At the main box office, you show your ID once and get a day pass. The pass opens no screen. At a screen's counter, you show the pass and get a ticket for that one screen. The door staff check only that ticket. They never see your ID.
In Kerberos: box office = AS, day pass = TGT, screen counter = TGS, screen ticket = service ticket, door staff = the file server.
If you sent your password to every service, every service would see your secret. Kerberos avoids that. Your password proves who you are to one central authority, once. After that, you show short-lived tickets. This is like an identity provider on the web.
The central authority is the KDC (Key Distribution Center). In Active Directory it runs on every domain controller. It has two parts: the Authentication Service (AS) and the Ticket-Granting Service (TGS).
The two-step ticket dance
1 · Get a TGT (the AS exchange)
At logon, Priya's computer proves it knows her password. This is pre-authentication. It sends a timestamp that only her password can encrypt. The AS answers with a ticket-granting ticket (TGT). It is a master ticket that says "this is Priya." Only the KDC can read it.
2 · Trade it for a service ticket (the TGS exchange)
Priya wants the file server. Her computer shows the TGT to the TGS and asks for a ticket for that one service. The TGS returns a service ticket that works only for that service. She shows it to the file server and gets in. The server never sees her password.
One special account sits under everything: krbtgt. The KDC uses its key to protect every TGT. If an attacker gets that key, every ticket is in doubt.
How domains get attacked
Most attacks steal or guess a credential, then reuse it. We describe them only so you can spot and stop them.
| Attack | Why it works | The defense |
|---|---|---|
| Pass-the-hash | NTLM accepts a password hash as proof, so a stolen hash works at once. | Never reuse admin passwords across machines. Use Credential Guard. Restrict NTLM. |
| Kerberoasting | Any user can ask for a service ticket. It is locked with a key made from the service account's password. The attacker guesses that password offline, so no lockout trips. The old RC4 cipher makes guessing faster. | Give service accounts long random passwords, or use managed service accounts. Use AES, not RC4. |
| AS-REP roasting | An account with pre-authentication off hands out password-based data to anyone. It is guessed offline too. | Keep pre-authentication on. Check for accounts that have it off. |
| Golden ticket | An attacker who has the krbtgt key can forge a TGT for any account. | Protect domain controllers as Tier 0. After a compromise, reset the krbtgt password twice. |
Two defenses help against all of these. With admin tiering (see the privileged-access lesson), a domain-admin credential stays off ordinary workstations. Also move service accounts to gMSA. Windows then makes and rotates a long random password, so Kerberoasting has nothing to guess.
Then watch the logs (see "What to watch in the logs" below). After a golden-ticket scare, reset krbtgt twice. One reset is not enough, because the account remembers its last two passwords.
Kerberos needs matching clocks and working DNS. If a clock is more than 5 minutes off, Kerberos fails. Apps then quietly drop to NTLM, the weaker path.
Go deeper: What to watch in the logs
Domain controllers log every ticket they issue. Look for one account asking for tickets to many services, tickets issued with RC4, and accounts with pre-authentication off. Send the logs to your SIEM and alert on them. Prevention and detection work as a pair.
Go deeper: Ticket lifetimes and clocks
Tickets are short-lived on purpose. Microsoft's default maximum life for a user ticket is 10 hours. Kerberos also needs matching clocks, to stop replay. The default allowed difference between a client and the domain controller is 5 minutes. Outside that, sign-in fails. Many "Kerberos is broken" tickets turn out to be "the clock is wrong."
Go deeper: NTLM and Microsoft's plan to turn it off
NTLM: the older protocol still around
Before Kerberos, Windows used NTLM. It is a challenge-response method. The server sends a random challenge. The client answers with a calculation based on a hash of the password. The password itself is not sent. But NTLM has real weaknesses:
- The client never checks the server. There is no mutual authentication.
- The answer is not tied to the server you meant. An attacker in the middle can relay it to another server.
- Its hashing is weak by today's standards.
- Worst for defenders: the password hash itself works like a login. Whoever holds the hash can sign in, with no cracking.
Microsoft declared NTLM deprecated in June 2024. That means it gets no new development. NTLMv1 is already removed from Windows 11 24H2 and Windows Server 2025. You cannot remove NTLM overnight. But you can measure and shrink it. Prefer Negotiate. It tries Kerberos first and uses NTLM only when it must. Then find where NTLM is still used, and restrict it.
Microsoft describes three phases. Phase 1 is better NTLM auditing. It is already in Windows Server 2025 and Windows 11 24H2. Phase 2 adds tools that remove common reasons for falling back to NTLM: IAKerb and a local KDC. These are planned for the second half of 2026. Phase 3 turns network NTLM off by default in the next major Windows Server release. Even then, NTLM stays in the system. An admin can turn it back on with a policy.
Microsoft warns that dates can change. This is the picture as of October 2026. Check Microsoft's current guidance. Source: Microsoft Windows IT Pro Blog, "Advancing Windows security: Disabling NTLM by default".
Go deeper: AES over RC4, and the double krbtgt reset
AES over RC4. RC4 is what makes Kerberoasted tickets quick to crack. So Microsoft is retiring it as a default. The plan has three steps. Audit events start with the January 2026 updates. From the April 2026 updates, domain controllers assume AES-only for accounts with no explicit setting. From the July 2026 updates, the temporary rollback switch is gone. Microsoft's own pages differ a little on exact timing. Check the phase for your systems. Windows Server 2025 domain controllers do not issue RC4 TGTs at all. AES slows guessing, but a weak password can still be guessed. So long random service passwords still matter. MITRE says to use 25 characters or more. gMSA passwords change every 30 days by default.
Reset krbtgt twice. If the krbtgt key may have leaked, one reset is not enough. Microsoft says to reset it twice and wait between the resets. The wait is 10 hours by default, the same as the ticket life. Two resets clear the history and cancel every old ticket, forged or real. Everyone then signs in again.
🧪 Interactive lab — enable JavaScript to play with this one.
On a domain-joined Windows computer, run klist (docs) to see your real tickets. No domain? The MIT Kerberos klist manual covers Linux.