Windows Server for beginners. Part 6: Kerberos from the inside: how the protocol works
All parts of the series “Windows Server for beginners”Kerberos was invented at MIT in the 1980s for Project Athena: thousands of workstations, dozens of servers, and none of them could be trusted with a user's password. The solution was a trusted third party that knows the keys of all participants and issues them tickets: encrypted credentials with a limited lifetime that can be presented to a service instead of a password. Version 5 of the protocol is described in RFC 4120; Microsoft adopted it in Windows 2000 as the main domain authentication and added its own extensions, described in MS-KILE and MS-PAC. Since then every domain logon, every opening of a network folder and every LDAP request to a controller starts with Kerberos.
In the previous part we saw in Wireshark how an LDAP connection became unreadable after the SASL bind. Today we'll take apart exactly what happened there: message by message, field by field and key by key.
Participants and keys
A principal is any participant that has a key. A user is written as alice@CORP.EXAMPLE.COM, a service as cifs/srv1.corp.example.com@CORP.EXAMPLE.COM. The part after @ is the realm, the Kerberos domain; in Active Directory the realm equals the domain's DNS name in uppercase.
The KDC (Key Distribution Center) is a service on every domain controller: the lsass.exe process, the Kdc service. Inside there are two logical parts: the AS (Authentication Server) issues the initial ticket, the TGS (Ticket-Granting Server) issues tickets for services. The KDC takes all principals' keys from the directory: for each account they're stored in attributes that can't be read over LDAP with any rights and are only replicated between controllers.
A principal's long-term key is derived from its password. For a user, from what they type; for a computer, from a random 120-character password the machine changes by itself every 30 days; for a service, from the password of the account it runs under. The derivation depends on the encryption type:
- RC4-HMAC (type 23): the key is the NT hash of the password, MD4 of the UTF-16 string. No salt: two users with the same password have the same key. The key is equivalent to the password, and the whole pass-the-hash family of attacks relies on that.
- AES128-CTS-HMAC-SHA1-96 (type 17) and AES256-CTS-HMAC-SHA1-96 (type 18): the key is PBKDF2 of the password with 4096 iterations and the salt
REALM + name(CORP.EXAMPLE.COMalice). Identical passwords produce different keys, and brute-forcing is thousands of times slower.
Which types an account allows is stored in the msDS-SupportedEncryptionTypes attribute — a bit field (0x4 RC4, 0x8 AES128, 0x10 AES256, 0x18 both AES); for users it's usually empty, and the KDC takes the domain default. Microsoft has declared RC4 deprecated, and in modern domains it's worth disabling, after first making sure from audit events that nobody uses it; how — at the end of the part.
krbtgt is an account created when the domain is installed (part 4), always disabled, with RID 502. Its key is the domain's master key: the KDC encrypts every TGT it issues with it. Any controller knowing this key can decrypt a TGT issued by another controller and serve the client; nobody else can decrypt a TGT. Two facts. The krbtgt password never changes automatically, and in a domain created in 2008 it may still be the same one — which means that someone who once got hold of its hash can still forge any tickets they like (the golden ticket attack). That's why it's changed by hand, and twice: the KDC keeps the current and the previous key and accepts tickets encrypted with either, so that valid TGTs don't all expire at once; the second change, no earlier than one TGT lifetime later (10 hours, better a day), finally retires the old key. Replication to all controllers must complete between the changes.
Three exchanges
ws1 (alice) dc1 (KDC: AS + TGS) srv1 (cifs/srv1)
│ │ │
│ 1. AS-REQ: alice, krbtgt/CORP, │ │
│ etypes, nonce, │ │
│ PA-ENC-TIMESTAMP {time}K_alice ────►│ │
│ │ decrypt the time with alice's key: │
│ │ succeeded, time is fresh → it's alice│
│◄── 2. AS-REP: TGT {…}K_krbtgt, │ │
│ {session key S1, lifetime}K_alice │ │
│ │ │
│ 3. TGS-REQ: TGT, cifs/srv1, │ │
│ Authenticator {alice, time}S1 ─────►│ │
│ │ decrypt the TGT with the krbtgt key, │
│ │ extract S1, check the Authenticator │
│◄── 4. TGS-REP: ticket {…, S2}K_srv1$, │ │
│ {S2, lifetime}S1 │ │
│ │ │
│ 5. AP-REQ inside SMB: ticket, Authenticator {alice, time}S2 ─────────────────►│
│ │ decrypt the ticket with own key, │
│ │ extract S2, check Authenticator │
│◄── 6. AP-REP: {time}S2 ────────────────────────────────────────────────────────┤
AS-REQ / AS-REP: getting a TGT. At logon the client sends the KDC its name, the service name krbtgt/CORP.EXAMPLE.COM, the list of supported encryption types, a random nonce and pre-authentication — the current time encrypted with the user's key (PA-ENC-TIMESTAMP). The KDC decrypts the time with the key it stores for alice: if the result is a meaningful time within five minutes of its own, the client knows the password. If the client sent a request without pre-authentication, the KDC answers with a KDC_ERR_PREAUTH_REQUIRED error with a hint about which encryption types and which salt to use, and the client repeats the request; this is the normal course of events, and the first AS-REQ in any traffic capture always gets this error.
Why pre-authentication: without it the KDC would issue an AS-REP to anyone by name alone, and the response contains a block encrypted with the user's key that can be brute-forced offline. The DONT_REQ_PREAUTH flag in userAccountControl disables the requirement for a specific account, and accounts with this flag are the first thing an attacker looks for (AS-REP roasting).
The AS-REP has two parts. The TGT is a ticket encrypted with the krbtgt key; the client can't read it and stores it as is. And a block encrypted with the user's key: the session key S1 (the same one that's inside the TGT), the lifetime and the nonce from the request (replay protection). The client decrypts the block with the password, and from that moment on it doesn't need the password: all further operations use S1. Windows keeps the password in lsass memory to renew the TGT, but it never goes over the network again in any form.
TGS-REQ / TGS-REP: getting a service ticket. To open \\srv1\share, the client needs a ticket for cifs/srv1.corp.example.com. It sends the TGS the TGT, the service name and an authenticator — its name and the current time, encrypted with S1. The KDC decrypts the TGT with the krbtgt key, extracts S1 and the client name from it, and decrypts the authenticator with S1: the name matches and the time is fresh, so the request is genuine. Next the KDC finds in the directory the account on which the SPN cifs/srv1.corp.example.com is registered (that's SRV1$), generates a session key S2 and responds with a service ticket encrypted with the SRV1$ key (containing S2, the client name, the lifetime and the PAC) and a block with S2 encrypted with S1.
AP-REQ / AP-REP: presenting the ticket. The client opens an SMB connection to srv1 and passes an AP-REQ in the negotiation message: the service ticket and an authenticator encrypted with S2. The server decrypts the ticket with its own key — the one derived from its computer account password — extracts S2, checks the authenticator and learns from the ticket who has come and which groups they belong to. The controller doesn't take part in this step: the server verified the client by itself, and this works even when the controller is unavailable, as long as the ticket hasn't expired. If the client asked for mutual authentication (in Windows it always does), the server replies with an AP-REP containing the time from the authenticator encrypted with S2: this is how the client makes sure the server really knows the SRV1$ key, that is, it's the real srv1.
An AP-REQ almost never travels as a separate packet. It's wrapped in GSS-API and SPNEGO (a negotiation mechanism: "I can do Kerberos and NTLM, pick one") and embedded in the application protocol: in an LDAP SASL bind, in an SMB Session Setup, in an HTTP Authorization: Negotiate header, in an RPC bind. That's why in Wireshark Kerberos is visible on port 88 (AS and TGS) and inside other protocols (AP).
What's inside a ticket
Ticket
├─ tkt-vno: 5
├─ realm: CORP.EXAMPLE.COM
├─ sname: cifs/srv1.corp.example.com
└─ enc-part (encrypted with the service's long-term key)
├─ flags: forwardable, renewable, pre_authent, …
├─ key: session key S2
├─ crealm, cname: CORP.EXAMPLE.COM, alice
├─ transited: which realms it passed through (for trusts)
├─ authtime: when the client authenticated (the AS-REQ time)
├─ starttime, endtime, renew-till
├─ caddr: client addresses (Windows leaves it empty)
└─ authorization-data
└─ AD-IF-RELEVANT → AD-WIN2K-PAC → PAC
The only cleartext part is the service name and the realm: from them the server knows which key to decrypt with. Everything else is sealed with the service's key, and the client passing the ticket along can neither read nor change its contents.
The PAC (Privilege Attribute Certificate) is the Microsoft extension that makes Kerberos usable for Windows. A standard ticket only says "this is alice". Windows needs to know the SID of the user and of all their groups to build an access token and check ACLs without contacting the controller for every file. The PAC contains:
- Logon Info — the user's SID, the primary group RID, the list of domain group RIDs, the list of SIDs of groups from other domains and built-in ones (
Extra SIDs), the name, profile, logon time, account flags; - Client Info — name and time for verification;
- UPN and DNS Info — the UPN and the domain name;
- Signatures — a signature with the service's key (so the service would notice tampering) and a signature with the
krbtgtkey (so the service can ask the controller to verify the PAC but can't forge it itself), and since 2022, two more signatures protecting against name spoofing and against moving a PAC between tickets.
Two consequences for an administrator. A user's groups are fixed at the moment the TGT is issued: add a user to a group, and they won't see it until they get a new TGT, that is, sign out and back in (or run klist purge, after which Windows will get a new TGT on the next access). And the PAC has a size: a user in a thousand groups gets a ticket of tens of kilobytes that may not fit into an HTTP header or an old application's buffer; since 2012 the MaxTokenSize limit is 48,000 bytes, and that's a Windows limit, not a Kerberos one.
Ticket flags shown by klist:
| Flag | Meaning |
|---|---|
initial |
obtained via AS-REQ rather than from another ticket; only TGTs have it |
pre_authent |
the client passed pre-authentication |
renewable |
can be renewed without the password until renew-till |
forwardable |
this TGT can be used to get a TGT for another host; needed for unconstrained delegation |
forwarded |
this is such a forwarded TGT |
ok_as_delegate |
the KDC tells the client that the service is allowed to delegate |
name_canonicalize |
the KDC may have returned the canonical principal name instead of the requested one |
enc_pa_rep |
the response contained an encrypted copy of the pre-authentication data (protection against reply tampering) |
Lifetimes are set by the Kerberos policy in the Default Domain Policy and default to: service ticket — 10 hours, TGT — 10 hours, TGT renewal — 7 days, maximum clock skew — 5 minutes. The client renews the TGT by itself (a TGS-REQ with the renew option) until renew-till expires, after which the password is needed — in Windows this is invisible, because lsass remembers it. About the five minutes: an authenticator carries a time, and the KDC or the service rejects it if it differs from their clock by more than the tolerance. This protects against replaying intercepted messages, and it's also why a machine whose clock has drifted can't sign in to the domain — we'll come back to that in the part about time.
SPN
When requesting a ticket, the client names the service — the SPN (service principal name): class/host[:port][/name]. The class is cifs, ldap, HTTP, MSSQLSvc, host, RestrictedKrbHost, TERMSRV, WSMAN or any other string the client and server agree on; the host is the fully qualified DNS name. The KDC looks for an account that has this value in its multi-valued servicePrincipalName attribute and encrypts the ticket with that account's key.
From the moment it joins the domain, a computer account has HOST/srv1 and HOST/srv1.corp.example.com. HOST is a generic class: in the CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration object, the sPNMappings attribute lists which classes count as aliases of HOST — cifs, ldap, http, rpcss, wsman, termsrv and about thirty more. That's why nothing needs to be registered on the server for SMB, WinRM and RDP. Registration is needed when a service runs under another account — SQL Server under CORP\svc-sql needs MSSQLSvc/sql1.corp.example.com:1433 on svc-sql, a web application in IIS under CORP\svc-web needs HTTP/web.corp.example.com on svc-web — or when the server is accessed by another name: a CNAME intranet.corp.example.com pointing to srv1 needs HTTP/intranet.corp.example.com on SRV1$, because the client builds the SPN from the name it typed, not from the one it resolved to.
PS C:\> setspn -L srv1
Registered ServicePrincipalNames for CN=SRV1,CN=Computers,DC=corp,DC=example,DC=com:
WSMAN/srv1
WSMAN/srv1.corp.example.com
TERMSRV/SRV1
TERMSRV/srv1.corp.example.com
RestrictedKrbHost/SRV1
HOST/SRV1
RestrictedKrbHost/srv1.corp.example.com
HOST/srv1.corp.example.com
PS C:\> setspn -S MSSQLSvc/sql1.corp.example.com:1433 svc-sql
Checking domain DC=corp,DC=example,DC=com
Registering ServicePrincipalNames for CN=svc-sql,OU=Service Accounts,DC=corp,DC=example,DC=com
MSSQLSvc/sql1.corp.example.com:1433
Updated object
PS C:\> setspn -X
Checking domain DC=corp,DC=example,DC=com
Processing entry 0
found 0 groups of duplicate SPNs.
-S, unlike the old -A, checks that the SPN doesn't exist yet; -X looks for duplicates across the whole forest. The same in PowerShell: Set-ADUser svc-sql -ServicePrincipalNames @{Add='MSSQLSvc/sql1.corp.example.com:1433'}.
Two SPN errors that occur more often than all others combined:
SPN not found. The KDC answers KDC_ERR_S_PRINCIPAL_UNKNOWN, and the client, if it uses SPNEGO, silently falls back to NTLM. Everything works, but over NTLM: without mutual authentication, with the check passed to the controller on every connection, and without delegation. This happens when accessing by IP address (nobody has an SPN like cifs/192.168.1.20 unless a separate setting is enabled), by a CNAME without an SPN, or a service running under an account without an SPN. You can spot it from events 4776 on the controller or from klist, where there's no ticket for this service.
SPN on the wrong account, or a duplicate. The ticket is encrypted with the key of account A, but the service runs under B and can't decrypt it. The client gets KRB_AP_ERR_MODIFIED, and depending on the protocol it looks like "The target principal name is incorrect", "Cannot generate SSPI context" in SQL Server, or a Kerberos event with code 4 in the client's System log: "The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server srv1$. The target name used was MSSQLSvc/sql1…". The fix is to move the SPN to the right account.
Delegation
A web application on web1 accesses SQL Server on sql1 on behalf of the user who opened the page. web1 has the user's ticket for HTTP/web1, but that ticket is good only for web1: it can't be presented to sql1, because it's encrypted with web1's key. This is the double hop problem, and Kerberos solves it with three kinds of delegation.
Unconstrained: the TRUSTED_FOR_DELEGATION flag on the web1 account. The KDC issues tickets for HTTP/web1 with the ok_as_delegate flag; seeing it, the client requests a forwarded TGT and sends it to web1 along with the ticket. web1 gets a full-fledged TGT of the user and can get a ticket for anything on their behalf. Convenient and dangerous: a compromised web1 acts as any user who has connected to it, including a domain administrator. Domain controllers have this flag out of necessity; member servers aren't given it.
Constrained (Windows Server 2003): the msDS-AllowedToDelegateTo attribute on web1 lists the SPNs it may access on behalf of clients — MSSQLSvc/sql1.corp.example.com:1433. The mechanism is two protocol extensions: S4U2Proxy lets web1 present to the KDC the user's ticket for itself and get a ticket for sql1 on the user's behalf; S4U2Self lets it get a ticket for itself on behalf of any user without their involvement ("protocol transition", when the user authenticated not with Kerberos but, say, through a form on a website). It's configured on the account's Delegation tab or with Set-ADComputer web1 -Add @{'msDS-AllowedToDelegateTo'='MSSQLSvc/sql1.corp.example.com:1433'}.
Resource-based constrained (Windows Server 2012): the same constrained delegation, but the permission is set not by the administrator of web1 but by the owner of sql1 — the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on sql1 lists who may come to it on someone else's behalf. It works across forest trusts and doesn't require domain administrator rights: Set-ADComputer sql1 -PrincipalsAllowedToDelegateToAccount (Get-ADComputer web1).
The double hop problem also comes up in PowerShell Remoting — when, connected to a server, you try to access a network folder from it — and we'll see its solutions, from delegation to CredSSP, in the part about WinRM.
Errors
Codes from RFC 4120 that show up in logs and captures:
| Code | Name | What it means in practice |
|---|---|---|
| 6 | KDC_ERR_C_PRINCIPAL_UNKNOWN |
no such user (or the client contacted another realm) |
| 7 | KDC_ERR_S_PRINCIPAL_UNKNOWN |
no account with this SPN; the client will fall back to NTLM |
| 12 | KDC_ERR_POLICY |
forbidden by policy: logon at this time, on this computer, protocol transition |
| 13 | KDC_ERR_BADOPTION |
usually delegation isn't allowed for the requested service |
| 14 | KDC_ERR_ETYPE_NOSUPP |
no common encryption type: the client has only RC4 and the service only AES, or vice versa |
| 18 | KDC_ERR_CLIENT_REVOKED |
the account is disabled, locked out or expired |
| 23 | KDC_ERR_KEY_EXPIRED |
the password has expired; the client will offer to change it |
| 24 | KDC_ERR_PREAUTH_FAILED |
wrong password |
| 25 | KDC_ERR_PREAUTH_REQUIRED |
the normal first response to an AS-REQ without pre-authentication |
| 32 | KRB_AP_ERR_TKT_EXPIRED |
the ticket has expired; the client will request a new one |
| 37 | KRB_AP_ERR_SKEW |
the clocks differ by more than 5 minutes |
| 41 | KRB_AP_ERR_MODIFIED |
the service couldn't decrypt the ticket: the SPN is on another account or duplicated, or the service password is stale |
| 52 | KRB_ERR_RESPONSE_TOO_BIG |
the response doesn't fit into UDP; the client will retry over TCP. Windows uses TCP right away if the response is larger than 1465 bytes |
| 68 | KDC_ERR_WRONG_REALM |
the client contacted the wrong realm; the KDC points to the right one (used with trusts) |
On a controller, every request to the KDC is written to the Security log if Kerberos auditing is enabled (it is enabled in the Default Domain Controllers Policy):
| Event | What |
|---|---|
| 4768 | a TGT was issued (AS-REP) or refused — the error code is in the Result Code field |
| 4769 | a service ticket was issued (TGS-REP) or refused; the Ticket Encryption Type field shows 0x12 (AES256), 0x11 (AES128) or 0x17 (RC4) |
| 4770 | a TGT was renewed |
| 4771 | pre-authentication failed: wrong password, Failure Code 0x18 |
| 4776 | the controller validated credentials via NTLM; each such event is a connection that didn't become Kerberos |
A hands-on look
klist on a workstation, field by field:
PS C:\> klist
Current LogonId is 0:0x3e7a1
Cached Tickets: (2)
#0> Client: alice @ CORP.EXAMPLE.COM
Server: krbtgt/CORP.EXAMPLE.COM @ CORP.EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 10/15/2026 9:02:11 (local)
End Time: 10/15/2026 19:02:11 (local)
Renew Time: 10/22/2026 9:02:11 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: dc1.corp.example.com
#1> Client: alice @ CORP.EXAMPLE.COM
Server: cifs/srv1.corp.example.com @ CORP.EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 10/15/2026 9:05:40 (local)
End Time: 10/15/2026 19:02:11 (local)
Renew Time: 10/22/2026 9:02:11 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: dc1.corp.example.com
LogonId is the logon session; each session has its own ticket cache (a service and a user on the same machine don't share them). KerbTicket Encryption Type is what the ticket itself is encrypted with, that is, the type of the service's key: for the TGT it's the krbtgt key, for #1 the SRV1$ key. Session Key Type is the session key type; if a modern client shows 0x17 here, it's worth asking who requested RC4. The service ticket's End Time matches the TGT's: a service ticket can't outlive the TGT it was obtained from. Kdc Called is the controller that answered.
Useful subcommands: klist purge — clear the cache (get a new TGT with a new set of groups without signing out), klist get cifs/srv1.corp.example.com — request a ticket now and see the error if there is one, klist tgt — TGT details, klist sessions — all logon sessions on the machine, klist -li 0x3e7 — the tickets of the SYSTEM account (the computer), to see how the computer itself authenticates to the domain.
The exchange in packets. Capture with pktmon filtered on port 88, run klist purge and dir \\srv1\c$, open in Wireshark:
No. Source Destination Protocol Info
1 192.168.1.100 192.168.1.10 KRB5 AS-REQ
2 192.168.1.10 192.168.1.100 KRB5 KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
3 192.168.1.100 192.168.1.10 KRB5 AS-REQ
4 192.168.1.10 192.168.1.100 KRB5 AS-REP
5 192.168.1.100 192.168.1.10 KRB5 TGS-REQ
6 192.168.1.10 192.168.1.100 KRB5 TGS-REP
In the third packet, expanding padata shows PA-ENC-TIMESTAMP with etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18) and an encrypted block; in req-body there's cname: alice, sname: krbtgt/CORP.EXAMPLE.COM, till, nonce and the client's etype list. In the AS-REP there's a ticket with a cleartext sname and enc-part, and a separate enc-part for the client. In the TGS-REQ there's padata of type PA-TGS-REQ with an AP-REQ inside (the TGT plus an authenticator) and sname: cifs/srv1.corp.example.com. The AP-REQ to srv1 itself has to be looked for in this capture on port 445, inside the SMB2 Session Setup, in the Security Blob field — SPNEGO with a krb5_blob inside.
What the directory knows about its keys:
PS C:\> Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber, msDS-SupportedEncryptionTypes | Select-Object PasswordLastSet, msDS-KeyVersionNumber, msDS-SupportedEncryptionTypes
PasswordLastSet msDS-KeyVersionNumber msDS-SupportedEncryptionTypes
--------------- --------------------- -----------------------------
01.10.2026 11:58:02 2
PS C:\> Get-ADComputer srv1 -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, servicePrincipalName | Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
Name PasswordLastSet msDS-SupportedEncryptionTypes
---- --------------- -----------------------------
SRV1 10.10.2026 8:14:33 28
msDS-KeyVersionNumber is the key version number (kvno): tickets carry it in the header, and the service uses it to know which of its keys to decrypt with. For krbtgt, kvno 2 means the password hasn't changed since installation (the first version at creation, the second at promotion). For the computer, 28 = 0x1C — RC4 plus AES128 plus AES256: this is the default for computer accounts, and it's how the KDC decides that srv1 supports AES.
Who in the domain still uses RC4, before disabling it:
PS C:\> Get-WinEvent -ComputerName dc1 -FilterHashtable @{LogName='Security'; Id=4769; StartTime=(Get-Date).AddDays(-7)} |
Where-Object { $_.Properties[5].Value -eq '0x17' } |
Group-Object { $_.Properties[0].Value }, { $_.Properties[2].Value } |
Select-Object Count, Name | Sort-Object Count -Descending
Count Name
----- ----
42 CORP\scanner$, MSSQLSvc/sql1.corp.example.com:1433
Property 5 of event 4769 is the ticket encryption type, 0 is the client name, 2 is the service. Here RC4 is requested by an old network scanner, and until it's replaced or updated, the svc-sql account will have to keep RC4 in msDS-SupportedEncryptionTypes. When the list is empty, RC4 is disabled domain-wide with the "Network security: Configure encryption types allowed for Kerberos" policy in the Default Domain Policy and msDS-SupportedEncryptionTypes = 24 on service accounts.
And finally. The Kerberos log on a client is almost empty by default; a registry value turns it on:
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name LogLevel -Value 1 -Type DWord
Get-WinEvent -LogName System -FilterHashtable @{ProviderName='Microsoft-Windows-Security-Kerberos'} -MaxEvents 10
After that, every KDC error lands in the System log with a code from the table above and the name of the service the client was contacting. It's the first thing you turn on when "it won't connect and nobody knows why", and the first thing you turn off afterwards, because the log quickly fills up with error 25s that aren't errors.
Kerberos relies on two external things: the client must find the KDC and name the service correctly — that's DNS — and the clocks of all participants must agree to within five minutes. The next parts are about the first and the second.
Next — Part 7: DNS in the domain. Directory-integrated zones and their replication scopes; secure dynamic updates and who has the right to change a record; forwarders, conditional forwarders and stub zones; reverse zones; scavenging stale records; and how to keep an internal copy of a public zone without breaking the website.
Only registered users can leave a comment.
Sign in or register to leave a comment.