What Is Kerberos? Authentication Protocol in Computer Networks

Kerberos is a ticket-based network authentication protocol: a trusted Key Distribution Center (KDC) verifies a user’s identity and issues tickets that the user presents to other services, so the password itself is never sent over the network. It is the preferred authentication method in Active Directory, which is why its configuration and protection determine the security of the entire Windows domain.

In the world of cybersecurity, authentication is the first line of defense against unauthorized access to network resources. Among the authentication protocols used in enterprise environments, Kerberos holds an overwhelmingly dominant position — it is the default authentication mechanism in Active Directory and therefore the foundation of security for millions of organizations worldwide. Understanding how Kerberos works, where its weak spots are and how to secure it properly is essential for every IT security professional.

In this article we explain the architecture and inner workings of the Kerberos protocol in detail, compare it with NTLM, walk through the most serious attacks that exploit its weaknesses and present best practices for protecting infrastructure built on this protocol.

What Is Kerberos?

Kerberos is a ticket-based network authentication protocol designed to confirm the identity of users and services securely over an untrusted network. Its defining feature is that the user’s password is never sent across the network — instead, the protocol relies on a system of cryptographic tickets issued by a trusted third party.

The protocol takes its name from Cerberus (Kerberos in Greek mythology), the three-headed dog guarding the gates of Hades. The analogy fits: the protocol guards access to network resources, and the three “heads” stand for the three parties involved in authentication — the client, the server and the Key Distribution Center (KDC).

History and Evolution

Kerberos was developed at the Massachusetts Institute of Technology (MIT) as part of Project Athena in the early 1980s. The goal of the project was to build a secure authentication system for the campus computer network, where thousands of users shared workstations and servers.

• Kerberos v1-v3 (1983-1987) — internal MIT versions, never released publicly.
• Kerberos v4 (1989) — the first publicly released version. It used DES encryption and had limited interoperability between different domains (realms).
• Kerberos v5 (1993, RFC 1510; updated in 2005 as RFC 4120) — the current version. It added support for multiple encryption algorithms, credential delegation, cross-realm authentication and pre-authentication mechanisms. This is the version used in today’s systems.

In 2000 Microsoft implemented Kerberos v5 as the default authentication protocol in Windows 2000 and Active Directory, which made it the de facto standard in enterprise environments. Microsoft’s implementation adds some extensions (such as the PAC — Privilege Attribute Certificate) that go beyond the pure RFC standard.

Kerberos Architecture — Key Components

Understanding the Kerberos architecture requires getting to know several fundamental elements that work together during authentication.

Key Distribution Center (KDC)

The KDC is the central point of trust in a Kerberos infrastructure. In an Active Directory environment, every domain controller acts as a KDC. The KDC consists of two logical components:

• Authentication Server (AS) — handles the initial authentication of the user and issues the TGT. This is where the system checks that the user is who they claim to be.
• Ticket Granting Server (TGS) — issues service tickets based on a valid TGT. Thanks to this, the user does not have to enter the password again when accessing further resources.

The KDC stores a database of all accounts (principals) together with their cryptographic keys. In Active Directory this database is integrated with the NTDS.dit database on the domain controller.

Ticket Granting Ticket (TGT)

The TGT is the ticket obtained after initial authentication. It works like a temporary pass — once the user has confirmed their identity, they receive a TGT that lets them request tickets for specific services without entering the password again. The TGT is encrypted with the key of the KRBTGT account — a special service account in Active Directory whose compromise has catastrophic consequences (more on this in the section on attacks).

The default TGT lifetime in Active Directory is 10 hours, with renewal possible for up to 7 days.

Service Ticket (TGS)

A Service Ticket (often also called a TGS ticket) is issued by the Ticket Granting Server and grants access to a specific service — for example a network share, a database or a web server. The ticket is encrypted with the key of the target server’s service account, so only that server can decrypt and verify it.

Service Principal Name (SPN)

An SPN is a unique name that identifies a service instance in a Kerberos environment. The SPN format is usually:

serviceclass/host:port/servicename

For example:

HTTP/intranet.company.com
MSSQLSvc/sql01.company.com:1433
CIFS/fileserver.company.com

The SPN is essential for Kerberos to work correctly — the client must know the service’s SPN to request the right ticket from the TGS. Misconfigured SPNs are one of the most common causes of Kerberos authentication problems.

Realm

A realm (in Active Directory the equivalent is a domain) is an administrative boundary within which a single KDC operates. Kerberos allows authentication between different realms (cross-realm authentication) through trust relationships. In Active Directory the equivalent is trust relationships between domains and forests.

How Does Kerberos Authentication Work?

The Kerberos authentication process consists of three main phases, which can be described as an exchange of six messages.

Phase 1: Authentication Service Exchange (AS Exchange)

The user signs in at a workstation with a login and password. The workstation does not send the password to the KDC — instead, it performs the following steps:

1. AS-REQ (Authentication Service Request) — the client sends the AS a request containing its name (principal), the requested ticket lifetime and a timestamp encrypted with a key computed from the user’s password. This encrypted timestamp is the pre-authentication mechanism (PA-ENC-TIMESTAMP), which prevents offline attacks against the KDC database.

2. AS-REP (Authentication Service Reply) — the AS checks the data against the KDC database. If pre-authentication is correct, the AS responds with two elements:

   • TGT encrypted with the KRBTGT account key (the client cannot decrypt it — it is meant only for the TGS).
   • Session Key encrypted with the user’s key — the client decrypts it with the key derived from the password and uses it for further communication with the TGS.

After this phase the client holds the TGT and the session key. The user’s password is removed from the workstation’s memory — it is no longer needed for further authentication.

Phase 2: Ticket Granting Service Exchange (TGS Exchange)

When the user wants to access a specific service (for example open a network share), the client performs the following steps:

3. TGS-REQ (Ticket Granting Service Request) — the client sends the TGS a request containing:

   • the TGT obtained in phase 1
   • the SPN of the service it wants to access
   • an authenticator — a timestamp encrypted with the session key (proof that the client knows the session key)

4. TGS-REP (Ticket Granting Service Reply) — the TGS decrypts the TGT with the KRBTGT key, verifies the authenticator and then responds with:

   • a Service Ticket encrypted with the key of the target server’s service account
   • a new session key for client-server communication, encrypted with the session key from phase 1

Phase 3: Client/Server Exchange (AP Exchange)

5. AP-REQ (Application Request) — the client presents the Service Ticket to the target server together with a new authenticator (encrypted with the client-server session key).

6. AP-REP (Application Reply) — the server decrypts the Service Ticket with its own key, verifies the authenticator and — if everything is correct — grants access to the service. Optionally, the server can reply with an encrypted timestamp, confirming its own identity to the client (mutual authentication).

The whole process is transparent to the user — after a single sign-in they gain access to many services without entering the password again. This is the Single Sign-On (SSO) mechanism built into Kerberos.

Kerberos vs NTLM — Protocol Comparison

In Windows environments Kerberos coexists with the older NTLM protocol. Understanding the differences between them is key to assessing infrastructure security.

Aspect	Kerberos	NTLM
Mechanism	Cryptographic tickets	Challenge-response with the password hash
Password on the network	Never sent	Password hash used in the response
Mutual authentication	Yes (mutual authentication)	No — the client does not verify the server
Delegation	Yes (constrained/unconstrained delegation)	Limited (NTLM relay)
Requirements	Domain controller, time synchronization, DNS	Works without a domain
Performance	Better — tickets cached locally	Every access requires communication with the DC
Attacks	Kerberoasting, Golden/Silver Ticket, AS-REP Roasting	Pass-the-Hash, NTLM Relay, Brute-force
Standard	Open (RFC 4120)	Proprietary (Microsoft)

NTLM is still present in many environments for several reasons: backward compatibility with older applications, scenarios outside a domain (workgroups) and situations in which Kerberos cannot be used (access by IP address instead of a DNS name). From a security perspective, minimizing NTLM use and moving to Kerberos is one of the priorities when hardening Active Directory.

Attacks on the Kerberos Protocol

Despite its solid cryptographic foundations, Kerberos is vulnerable to a number of attacks that exploit weaknesses in implementation, configuration or the design of the protocol itself. Knowing these attacks is essential to protecting infrastructure effectively.

Kerberoasting

Kerberoasting is one of the most common attacks on Kerberos in Active Directory environments. It works because TGS tickets are encrypted with a key derived from the service account’s password — if the password is weak, the ticket can be cracked offline.

How the attack works:

1. The attacker has any valid domain account (no administrator rights are needed).
2. They query Active Directory for accounts with registered SPNs (Get-ADUser -Filter {ServicePrincipalName -ne "$null"}).
3. They request TGS tickets for those accounts — the KDC issues them without question, because this is a normal Kerberos operation.
4. They run an offline brute-force attack against the exported tickets (for example with Hashcat or John the Ripper).
5. If the service account password is weak, it is cracked within minutes or hours.

Tools such as Rubeus, Impacket (GetUserSPNs.py) and PowerSploit modules automate this process.

Defense: random passwords of at least 25 characters for service accounts, migration to Group Managed Service Accounts (gMSA), for which Windows generates random 240-byte passwords and changes them every 30 days by default, and monitoring for bulk TGS requests (Event ID 4769).

Golden Ticket

A Golden Ticket is a forged TGT that gives the attacker practically unlimited access to the entire Active Directory domain. It is one of the most dangerous attacks because it allows long-term persistence.

How the attack works:

1. The attacker gains access to a domain controller and extracts the password hash of the KRBTGT account (for example with Mimikatz: lsadump::dcsync /domain:company.com /user:krbtgt).
2. Using that hash, they create a forged TGT with arbitrary data — they can pose as any user, including a domain administrator.
3. The forged TGT is accepted by the TGS because it is correctly encrypted with the KRBTGT key.
4. The attacker can obtain service tickets for any resource in the domain.

What makes it particularly dangerous is that a Golden Ticket keeps working even after the password of the impersonated user is changed — because the ticket is validated with the KRBTGT key, not the user’s key. The default lifetime of a Golden Ticket is 10 years.

Defense: changing the KRBTGT account password twice (because of AD password history this has to be done twice, at least 10 hours apart), regular monitoring of KRBTGT account use, deploying Privileged Access Management (PAM) and segmenting domain controllers into a separate, highly protected network zone (Tier 0).

Silver Ticket

A Silver Ticket is a forged Service Ticket which — unlike a Golden Ticket — grants access to a specific service rather than the entire domain. The attacker needs the password hash of a service account (not KRBTGT).

How the attack works:

1. The attacker obtains the password hash of a computer or service account (for example through Kerberoasting or by compromising a server).
2. They create a forged Service Ticket for a service running under that account.
3. They present the forged ticket directly to the target server — no communication with the KDC is needed.

A Silver Ticket is harder to detect than a Golden Ticket because it generates no logs on the domain controller — the whole interaction takes place directly between the attacker and the target server.

Defense: PAC (Privilege Attribute Certificate) validation on target servers, monitoring for anomalies in service access logs, and regular rotation of computer and service account passwords.

AS-REP Roasting

AS-REP Roasting targets accounts with pre-authentication disabled (the “Do not require Kerberos pre-authentication” flag in AD). When pre-authentication is disabled, the KDC answers an AS-REQ without verifying the requester’s identity — the attacker receives an AS-REP encrypted with the user’s key, which they can crack offline.

Defense: making sure pre-authentication is enabled for all accounts (do not set the “Do not require Kerberos pre-authentication” flag) and regularly auditing account configuration in AD.

Pass-the-Ticket (PtT)

Pass-the-Ticket involves stealing Kerberos tickets (TGT or Service Ticket) from the memory of a signed-in user and using them on another machine. Unlike Pass-the-Hash attacks (specific to NTLM), PtT operates on Kerberos tickets.

Tools such as Mimikatz (sekurlsa::tickets /export) can export tickets from the memory of the LSASS process and load them on another machine. The attacker takes over the user’s identity for the lifetime of the ticket.

Defense: protecting the LSASS process (Credential Guard in Windows 10/11), restricting administrative privileges, shorter ticket lifetimes and monitoring for anomalous sign-ins.

Skeleton Key Attack

Skeleton Key is an advanced attack in which malware is injected into the LSASS process on a domain controller. Once injected, the attacker can authenticate to any account with a single universal password (master password), while the users’ original passwords keep working. The attack does not survive a domain controller restart.

Defense: protecting domain controllers from unauthorized access, monitoring the integrity of the LSASS process, restarting domain controllers regularly and deploying Windows Defender Credential Guard.

Kerberos in Active Directory

In an Active Directory environment Kerberos is tightly integrated with many components and processes. Understanding this integration is key for security administrators.

The KRBTGT Account

The KRBTGT account is created automatically when Active Directory Domain Services is installed. Its password is used to encrypt every TGT in the domain. The account cannot be deleted, cannot sign in interactively and should not be modified manually. A compromised KRBTGT password means a compromised domain — which makes it one of the most valuable targets for attackers.

The KRBTGT account password should be changed regularly and, if compromise is suspected, changed twice immediately.

Kerberos Delegation

Kerberos delegation allows a service to act on behalf of a user when accessing other services. There are three types of delegation:

• Unconstrained Delegation — the service can use the user’s credentials to access any other service. This mechanism is extremely dangerous — compromising a server with unconstrained delegation gives the attacker access to the TGTs of all users who authenticate to it.

• Constrained Delegation — the service can act on behalf of the user only towards a defined list of services (set in the msDS-AllowedToDelegateTo attribute). Much safer than unconstrained delegation.

• Resource-Based Constrained Delegation (RBCD) — introduced in Windows Server 2012. Instead of being configured on the service account, delegation rights are defined on the target resource (the msDS-AllowedToActOnBehalfOfOtherIdentity attribute). This gives more flexibility and better control.

From a security perspective, the recommendation is to disable unconstrained delegation wherever possible and migrate to constrained delegation or RBCD.

Kerberos and Group Policy

Group Policy in Active Directory allows central management of Kerberos protocol settings:

• Maximum lifetime for user ticket — 10 hours by default
• Maximum lifetime for service ticket — 600 minutes by default
• Maximum lifetime for user ticket renewal — 7 days by default
• Maximum tolerance for computer clock synchronization — 5 minutes by default
• Enforce user logon restrictions — enforces logon policy checks when tickets are issued

These settings are located in: Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Kerberos Policy.

Time Synchronization

Kerberos requires time synchronization between the client and the KDC, with a default tolerance of 5 minutes. A larger time difference than allowed causes tickets to be rejected (the KRB_AP_ERR_SKEW error). In Active Directory, domain controllers also act as NTP servers, and the PDC emulator (Primary Domain Controller Emulator) is the time source for the whole domain.

Attackers may try to manipulate the client clock to extend the validity of stolen tickets or to force a fallback to NTLM — so monitoring time synchronization is an important part of security.

Best Practices for Securing Kerberos

Correct configuration and monitoring of the Kerberos protocol is a key element of Active Directory hardening. Below are the most important recommendations.

The starting point is knowing which service accounts have registered SPNs and weak passwords, where delegation is configured, which encryption types the domain allows and when the KRBTGT password was last changed. An Active Directory security audit answers these questions and shows the attack paths — from Kerberoasting to delegation abuse — before an attacker uses them.

Service Account Management

• Use Group Managed Service Accounts (gMSA) — random 240-byte passwords, which Windows changes every 30 days by default, eliminate the risk of Kerberoasting.
• For accounts that cannot be gMSA — use random passwords of at least 25 characters and change them regularly.
• Audit accounts with SPNs — regularly check which accounts have registered SPNs and whether that is justified (Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName).
• Do not register SPNs on user accounts — where possible, use computer accounts or gMSA.

Protecting the KRBTGT Account

• Change the password regularly — and immediately (twice) if compromise is suspected.
• Monitor use of the KRBTGT account — any anomalous logs concerning this account should trigger top-priority alerts.
• Deploy Managed Service Accounts with automatic key rotation.

Protocol Configuration

• Enforce pre-authentication — make sure no account has the pre-authentication flag disabled.
• Disable DES and RC4 — enforce AES256 encryption (etype 18) for Kerberos tickets. RC4 (etype 23) is vulnerable to attacks and should be disabled wherever compatibility allows.
• Shorten ticket lifetimes — consider reducing the default 10-hour TGT lifetime in higher-risk environments.
• Disable unconstrained delegation — migrate to constrained delegation or RBCD.
• Add privileged accounts to the Protected Users group — its members cannot authenticate with NTLM, use DES or RC4 in pre-authentication or be delegated (constrained delegation included), and their TGTs are not renewed beyond the first 4 hours.

Monitoring and Detection

Effective monitoring of Kerberos activity requires collecting and analyzing the following Windows events:

• Event ID 4768 (TGT Request) — watch for unusual requests, especially those with a pre-authentication failure flag.
• Event ID 4769 (TGS Request) — detect bulk ticket requests for many services within a short time (an indicator of Kerberoasting).
• Event ID 4770 (TGT Renewal) — monitor ticket renewals, especially from unusual IP addresses.
• Event ID 4771 (Pre-authentication failure) — the Kerberos counterpart of 4625, signals brute-force attempts.
• Event ID 4773 (Ticket request failed) — failed ticket requests can point to attacks.

Integrating these logs with a SIEM system makes it possible to build correlation rules that detect complex attack scenarios, such as the sequence Kerberoasting → lateral movement → privilege escalation.

Segmentation and Tier 0 Protection

Domain controllers (and therefore the KDC) are among an organization’s most valuable assets (Tier 0). Recommended safeguards include:

• Physical and logical isolation of domain controllers in a dedicated network segment.
• Administrative access only from dedicated workstations (Privileged Access Workstations — PAW).
• Deploying Windows Defender Credential Guard on all workstations where privileged users sign in.
• Regular Active Directory penetration testing with a focus on Kerberos attacks.

Kerberos Beyond Active Directory

Although Active Directory is the most widespread environment that uses Kerberos, the protocol is widely used outside the Microsoft ecosystem.

MIT Kerberos and Heimdal

Linux and Unix systems have two main implementations: MIT Kerberos (the reference implementation) and Heimdal (developed in Sweden and used, among others, in macOS and FreeBSD). Both implementations make it possible to build independent Kerberos realms or to integrate Linux machines with an Active Directory domain using tools such as SSSD (System Security Services Daemon) or Winbind.

Kerberos in Applications

Many systems and applications support Kerberos authentication natively:

• Databases — Microsoft SQL Server, PostgreSQL (GSSAPI), Oracle Database
• Web servers — Apache (mod_auth_kerb/mod_auth_gssapi), Nginx, IIS
• File systems — NFS v4 with Kerberos, SMB/CIFS
• Web browsers — SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) enables transparent Kerberos authentication in browsers (Internet Explorer, Chrome, Firefox)

Kerberos in the Cloud

In cloud environments Kerberos plays a smaller role than protocols such as SAML and OIDC. However, in hybrid architectures — where an organization keeps an on-premises Active Directory synchronized with Azure AD (Entra ID) — Kerberos remains the authentication protocol for on-premises resources, and Azure AD Kerberos enables access to cloud resources without direct communication with a domain controller.

Troubleshooting Kerberos

Kerberos authentication problems can be hard to diagnose. The most common causes are:

• Time desynchronization — the KRB_AP_ERR_SKEW error. Check NTP synchronization: w32tm /query /status on Windows, chronyc tracking on Linux.
• Missing or duplicate SPNs — use setspn -X to find duplicates and setspn -L <account> to list SPNs.
• DNS name resolution — Kerberos requires working DNS. Using an IP address instead of a DNS name causes a fallback to NTLM.
• Delegation problems — check the msDS-AllowedToDelegateTo and TrustedForDelegation attributes on the relevant accounts.

Diagnostic tools: klist (shows the tickets in the client cache), klist purge (clears the ticket cache), Wireshark with the kerberos filter, and Kerberos event logging in Windows.

Frequently Asked Questions (FAQ)

What is the difference between Kerberos and NTLM?

Kerberos is the more modern protocol, built on tickets and symmetric encryption, and it never sends passwords over the network. NTLM relies on a challenge-response mechanism and password hashes, which leaves it exposed to relay and pass-the-hash attacks. Microsoft recommends Kerberos as the default authentication protocol in Active Directory.

What is Kerberoasting and how do you prevent it?

Kerberoasting means requesting TGS tickets for service accounts with registered SPNs and then cracking the passwords from the encrypted tickets offline. The defense is long, random passwords (at least 25 characters) for service accounts, the use of gMSA (Group Managed Service Accounts) and monitoring for bulk TGS requests.

Does Kerberos only work in Windows environments?

No. Kerberos is an open standard (RFC 4120) that runs on many platforms. Implementations exist for Linux (MIT Kerberos, Heimdal) and macOS, and the protocol is also used by database systems and web applications. In Linux environments, machines can join an AD domain and authenticate through Kerberos using SSSD or Winbind.

What is a Golden Ticket and why is it so dangerous?

A Golden Ticket is a forged TGT created with the stolen key of the KRBTGT account. It gives the attacker unrestricted access to every resource in the Active Directory domain, lets them impersonate any user and keeps that access alive even after user passwords are changed. The only remedy is changing the KRBTGT account password twice.

How can I check whether my organization uses Kerberos or NTLM?

In Active Directory you can verify this by analyzing the Windows event logs on the domain controller. Events 4768 and 4769 relate to Kerberos authentication, while 4776 relates to NTLM. Tools such as PingCastle or Purple Knight generate reports on which authentication protocols are used in the domain.

What is a Kerberos ticket?

A Kerberos ticket is an encrypted, time-limited credential issued by the KDC. After signing in, the client receives a ticket-granting ticket (TGT), which it uses to request tickets for specific services from the KDC without entering the password again. The client hands the service ticket directly to the server, which decrypts it with its own key and reads the client’s identity and the session key from it.

What is the KDC in Kerberos?

The KDC (Key Distribution Center) is the trusted third party of the Kerberos protocol that authenticates clients and issues their tickets. Logically it consists of the authentication service (AS), which issues the TGT, and the ticket-granting service (TGS), which issues service tickets. In Active Directory the KDC runs on domain controllers and uses the AD DS database as its account database.

What ports does Kerberos use?

Clients talk to the KDC over port 88, on both TCP and UDP. In Active Directory, Kerberos authentication also depends on DNS (port 53), which lets the client find domain controllers, and on LDAP (port 389, or 636 for encrypted LDAPS connections), which is used to read directory data.

Can Kerberos work across different domains?

Yes. Kerberos supports authentication between realms (cross-realm authentication) — two realms share an inter-realm key, which lets the KDC of one realm refer the client, ticket in hand, to the KDC of the other. In Active Directory the equivalent is trust relationships between domains and forests, so a user in one domain can use resources in another.

Is Kerberos still secure in 2026?

The protocol itself remains sound — Microsoft still names Kerberos v5 as the preferred authentication method in Active Directory. What decides its security is the deployment, though — AES encryption instead of RC4, constrained delegation, PAC validation and monitoring for known attacks such as Golden Ticket or Kerberoasting. The weakest link is usually misconfiguration and weak service account passwords, not the protocol.

Summary

For more than four decades Kerberos has been the foundation of secure authentication in computer networks. Its architecture, built on cryptographic tickets and a trusted third party (the KDC), is far more secure than older mechanisms such as NTLM. However, the mere presence of Kerberos in the infrastructure does not guarantee security — what matters is configuring the protocol correctly, protecting its critical components (above all the KRBTGT account and the domain controllers) and continuously monitoring for attacks such as Kerberoasting or Golden Ticket.

Organizations that take Kerberos security seriously should regularly audit their Active Directory configuration, migrate to modern mechanisms (gMSA, AES256, constrained delegation) and integrate authentication logs with a SIEM system. In an era of advanced attacks on Active Directory, knowledge of the Kerberos protocol — both its strengths and its weaknesses — is an indispensable part of every security team’s arsenal.

---

Related services and products

• Antimalware Effectiveness Testing
• Threat Intelligence