Skip to content
stellvia.dev

Kerberos Authentication in Active Directory

Overview

Section titled “Overview”

Kerberos is the ticket-based authentication protocol normally used in Active Directory. Rather than sending a password directly to a service, a client authenticates with a ticket obtained from the KDC (Domain Controller). The client, KDC, and service exchange tickets and session keys based on shared-key cryptography to provide mutual authentication and single sign-on.

Main Participants

Section titled “Main Participants”
  • Client: The user or device authenticating. Its local LSA holds a ticket cache.
  • Service: The server or application being accessed, such as IIS, SMB, or SQL. It decrypts tickets with the key of a service or computer account.
  • KDC: The authentication service on a Domain Controller. It provides the Authentication Service (AS) and Ticket Granting Service (TGS).
  • Key material: Long-term keys derived from the NT hashes of domain user, computer, or service accounts. Session keys in tickets are short-lived.

Ticket and Key Types

Section titled “Ticket and Key Types”
  • TGT (Ticket Granting Ticket): Encrypted with the key of the KDC’s krbtgt account. The client uses it only to obtain TGS tickets.
  • Service ticket: Issued for a specific SPN and encrypted with the corresponding service account’s key.
  • PAC (Privilege Attribute Certificate): User SID, group, and rights information embedded in a ticket. A service verifies the PAC and builds an access token.
  • Session key: A short-lived shared key used between client and KDC or between client and service.
  • Encryption types: Include AES256, AES128, and RC4. AES types are preferred in recent environments.

Authentication Flow

Section titled “Authentication Flow”
  1. AS-REQ: The client sends its username and a timestamp as pre-authentication data to request a TGT. The timestamp is encrypted with the client’s key.
  2. AS-REP: The KDC verifies pre-authentication and returns a TGT and client/KDC session key. The TGT is encrypted with the krbtgt key, so the client cannot read its contents.
  3. TGS-REQ: The client presents its TGT and the SPN it wants to access, requesting a service ticket. The request is protected with the session key obtained from the TGT.
  4. TGS-REP: The KDC decrypts the TGT with the krbtgt key and returns a service ticket for the SPN and a client/service session key.
  5. AP-REQ: The client sends the service ticket and an Authenticator, containing a timestamp and username encrypted with the session key, to the service.
  6. AP-REP (for mutual authentication): The service decrypts the service ticket with its key and the Authenticator with the session key, then checks the timestamp. On success it responds, and client and service share the same session key.
  7. Access token creation: The service verifies the PAC. On Windows, the LSA converts it into a local token used for access-control (ACL) decisions.

Sequence Diagram (AS/TGS/AP)

Section titled “Sequence Diagram (AS/TGS/AP)”

What a TGT Is and How to Handle It

Section titled “What a TGT Is and How to Handle It”
  • A TGT is an identity credential for the KDC. It is not sent to services; it is used only in TGS-REQ.
  • Lifetime: Approximately ten hours by default, with a separate renewal period.
  • Check the Key Version Number (kvno) for each KDC. The kvno must match so a ticket can be decrypted with the key from the relevant password version.
  • Cache: On Windows, klist can inspect or clear it. A local reboot clears the cache; it does not carry over with a roaming profile.

SPN (Service Principal Name)

Section titled “SPN (Service Principal Name)”
  • Format: <ServiceClass>/<Hostname>:<Port>/<ServiceName>. Examples: HTTP/web.contoso.com, MSSQLSvc/sql.contoso.com:1433, and HOST/file01.
  • Types and classes: SMB uses CIFS or HOST, IIS uses HTTP, and SQL Server uses MSSQLSvc. HOST is a general class registered automatically by many services.
  • Registering account: Computer accounts register HOST and CIFS automatically. For a service running under a service account, register its SPN manually with setspn -S to avoid duplicates.
  • Effect of duplicates or omissions: Duplicate SPNs can prevent ticket issuance. An unregistered SPN can cause Kerberos failure and NTLM fallback.
  • Special SPN krbtgt/<REALM>: Associated with the krbtgt account whose key the KDC uses to encrypt TGTs. The DC normally manages it automatically, so no manual change is needed. Accidental deletion or modification can break all TGT issuance or validation; leave it untouched.

krbtgt Password Rotation and kvno

Section titled “krbtgt Password Rotation and kvno”
  • kvno (Key Version Number): A key generation number embedded in a ticket. A KDC or service selects the corresponding key when decrypting that ticket.
  • Purpose of krbtgt rotation: Renew the DC authentication key and invalidate Golden Tickets forged with an old krbtgt key. As with an ordinary password change, the kvno increments.
  • A Windows DC can retain the two most recent generations of krbtgt keys, so two rotations are recommended. The first introduces a new kvno. After ticket lifetimes and replication have had time to pass, the second advances the kvno again and retires the old key.
  • Timing guideline: Account for the domain’s maximum TGT lifetime (ten hours by default), renewal period (seven days by default), and DC replication time when scheduling the interval between rotations.
  • Operational cautions:
    • Run Set-ADAccountPassword -Identity krbtgt on the PDC emulator and wait for sufficient replication.
    • Long-running sessions may have to reauthenticate during rotation. Plan downtime or notify users of maintenance for critical systems.
    • If a kvno mismatch prevents TGT decryption, AS-REP or TGS-REP can fail. Check whether replication has reached DCs still holding an old kvno.
    • Trusted domains and forests have corresponding trust keys, so allow replication and time to avoid disrupting cross-forest authentication.

Why Clock Synchronization Is Essential

Section titled “Why Clock Synchronization Is Essential”
  • Tickets and Authenticators contain timestamps to prevent replay attacks. The default allowed skew is plus or minus five minutes (MaxSkew); exceeding it causes KRB_AP_ERR_SKEW.
  • Pre-authentication timestamp validation also depends on time. Skew can make AS-REQ fail, leading to NTLM fallback or failed logon.
  • Synchronize KDCs, clients, and services through NTP or W32Time. The same applies across forest trusts.

Using Tickets After Issuance

Section titled “Using Tickets After Issuance”
  • Establishing a session: After AP-REQ and AP-REP, client and service use the session key for message signing or encryption, such as SMB signing or LDAP Signing.
  • Cache reuse: Access to the same SPN reuses a cached service ticket without sending another TGS-REQ.
  • Ticket renewal: A TGT can be renewed automatically within its renewal period as its lifetime nears expiry. Service tickets are generally requested again.
  • Logon session: A token built from PAC information belongs to a process. Group changes require a new logon.
Section titled “Delegation and Related Features”
  • Unconstrained Delegation: A service can cache a received TGT and use it for TGS-REQ to a backend. This carries high risk.
  • Constrained Delegation (Kerberos Only): Delegation is limited to previously allowed SPNs. The TGS has a forwardable flag.
  • Resource-Based Constrained Delegation (RBCD): The backend service controls which accounts may delegate to it through msDS-AllowedToActOnBehalfOfOtherIdentity.
  • S4U (Service for User): S4U2self gets a service ticket on a user’s behalf, and S4U2proxy gets one for a delegation target. IIS, SSO, and print services are examples of use.

Delegation Sequence (S4U2self/S4U2proxy)

Section titled “Delegation Sequence (S4U2self/S4U2proxy)”

Basic klist and setspn Operations

Section titled “Basic klist and setspn Operations”
  • klist: Inspect or clear the ticket cache.
    • klist (without arguments): List acquired TGTs and service tickets.
    • klist tickets / klist tgt: Inspect only service tickets or only the TGT.
    • klist purge: Delete all tickets; consider the impact because reauthentication will be required.
    • klist get <SPN>: Fetch a service ticket for the specified SPN in advance (prefetch), useful for validation or testing before connecting.
    • Typical output: 
      Current LogonId is 0:0x3e7
      Service Name           : krbtgt/CONTOSO.COM
        Ticket Flags         : 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time           : 9/1/2024 10:00:00 (local)
        End Time             : 9/1/2024 20:00:00 (local)
        Renew Time           : 9/8/2024 10:00:00 (local)
  • setspn: Inspect, register, or find duplicate SPNs.
    • setspn -L <Account>: List SPNs for the specified service or computer account.
    • setspn -S <SPN> <Account>: Register an SPN while checking for duplicates. It stops with an error if one exists.
    • setspn -D <SPN> <Account>: Delete an SPN.
    • setspn -Q <SPN>: Find an SPN’s owner, useful for investigating duplicates or misregistration.
    • setspn -X: Search for all duplicate SPNs, useful for regular health checks.

Operations and Troubleshooting

Section titled “Operations and Troubleshooting”
  • DNS dependence: Kerberos uses FQDNs and SPNs. Name resolution failure can directly cause NTLM fallback or KRB_AP_ERR_MODIFIED.
  • Event logs: Track authentication in a DC’s System and Security logs (4768 AS, 4769 TGS, 4771 failure, and 4776 NTLM).
  • Tools: klist, setspn, nltest /dsgetdc, and w32tm /query /status are basic tools. A kerberos filter in Wireshark makes the flow easier to inspect.
  • Security considerations: Disable RC4, prefer AES, rotate the krbtgt password regularly, remove unnecessary delegation, and check for duplicate SPNs.