Introduction of Kerberos server¶

Kerberos is a secure authentication protocol that enables users and services to authenticate without transmitting passwords over the network. It is built around a trusted third-party authentication system, using tickets and encryption keys to ensure authentication.

The Kerberos server knows "secrets" (encrypted passwords) for all clients and servers under its control. These "secrets" are used to encrypt all the messages exchanged during authentication.

1. Key components and terms of Kerberos¶

Below is a list of important components and terms of Kerberos: - Key Distribution Center(KDC): is responsible for checking user credentials and issuing Tickets - Realm: defines a administrative domain to restrict a security scope. It includes a KDC and a list of Clients(e.g. users, hosts, services) - Principal: is a unique identity in the Kerberos system, which can be a user, host, or service. - Ticket: a credential issued by KDC. - Keytab: A file that includes one or more principals and their keys.

1.1 Key Distribution Center(KDC)¶

Key Distribution Center, or KDC is the heart of the Kerberos authentication system. At a high level, it has three parts:

A database: of the users, hosts and services (known as principals) that it knows about and their respective Kerberos passwords
An authentication server (AS): which performs the initial authentication and issues a Ticket Granting Ticket (TGT)
A Ticket Granting Server (TGS): that issues subsequent service tickets based on the initial TGT for accessing specific hosts or services

The KDC is typically hosted on a Domain Controller (DC) in Active Directory (AD) or a Kerberos server in MIT/Heimdal implementations.

1.2 Realm¶

A Kerberos realm defines the administrative domain. It includes a KDC and a list of Clients(e.g. users, hosts, services) The realm name usually matches the organization’s domain name, written in uppercase. For example, if the organization domain name is casd.eu, the realm name should be CASD.EU.

A realm can trust another realm (cross-realm authentication) for authentication across different domains.

1.3 Principal¶

A Principal is a unique identity in the Kerberos system, which can be:

a user (e.g., user@CASD.EU).
a host (e.g., host/server01.casd.eu@CASD.EU).
a service (e.g., hdfs/namenode.casd.eu@CASD.EU).

We must distinguish the difference between an account in AD/Ldap and a principal in Kerberos. An account in AD can be associated with multiple principals in Kerberos.

1.3.1 Naming convention of the principal¶

In theory, A principal in Kerberos 5 is of the following type: component1/component2/.../componentN@REALM

But, in practice a maximum of two components are used. So we recommend the below naming convention for principals.

Principal for users, we use the uid of the user and roles of the user to build the principal. In below example, user1 has two principals, user1@CASD.EU has normal privileges, user1/admin@CASD.EU has admin privileges

# general form for user principal
<uid>/<role>@REALM

# examples
user1@CASD.EU
user1/admin@CASD.EU

Principal for hosts(servers), we use the keyword host to indicate this principal provides a special service which give generic access to the machine (e.g. telnet, rsh, ssh). The second component is the complete hostname (FQDN) of the machine.

# general form for host principal, 
host/<host-fqdn>@REALM

# examples
host/server.casd.eu@CASD.EU

It is important that the host-fqdn exactly matches (in lower case letters) the DNS reverse resolution of the application server's IP address

# general form for service principal
<service-name>/<host-fqdn>@REALM

# examples
imap/mbox.casd.eu@CASD.EU
yarn/deb11_h01.casd.eu@CASD.EU

1.4 Ticket¶

A kerberos ticket is something a client presents to an application server to demonstrate the authenticity of its identity. Tickets are issued by the authentication server and are encrypted using the secret key of the service they are intended for. Since this key is a secret shared only between the authentication server and the server providing the service, not even the client which requested the ticket can know it or change its contents. The main information contained in a ticket includes: - The requesting user's principal (generally the username); - The principal of the service it is intended for; - The IP address of the client machine from which the ticket can be used. In Kerberos 5 this field is optional and may also be multiple to be able to run clients under NAT or multi-home. - The date and time (in timestamp format) when the tickets validity commences; - The ticket's maximum lifetime - The session key (this has a fundamental role which is described below);

1.4.1 Ticket's maximum lifetime¶

Each ticket has an expiration (generally 10 hours). This is essential since the authentication server no longer has any control over an already issued ticket. Even though the realm administrator can prevent the issuing of new tickets for a certain user at any time, it cannot prevent users from using the tickets they already possess. This is the reason for limiting the lifetime of the tickets to limit any abuse over time.

1.4.2 Ticket Granting Ticket(TGT) VS Service Ticket(ST)¶

Kerberos provides two types of tickets: - Ticket Granting Ticket(TGT): A ticket that proves the user identity to request other tickets; issued once per login session. - Service Ticket(ST): A ticket that grants access to a specific service; issued per service request.

A user principal requests authentication from the AS. The AS returns a TGT that is encrypted using the user principal's Kerberos password, which is known only to the user principal and the AS. The user principal decrypts the TGT locally using its Kerberos password, and from that point forward, until the ticket expires, the user principal can use the TGT to get service tickets(ST) from the TGS.

Ticket Granting Ticket (TGT)¶

Issued by the Authentication Service (AS) after a successful login.
Encrypted with the user’s password.
Allows the user to request service tickets without entering credentials again.
Has a validity period (e.g., 10 hours) and may be renewable.

Service Ticket (ST)¶

Issued by the Ticket Granting Service (TGS) upon request.
Allows access to a specific service (e.g., HDFS, Spark, SSH).
Each service requires its own ticket.
In general, the validity period of ST should be less than TGT

Difference Between a Ticket Granting Ticket (TGT) and a Service Ticket (ST)¶

Feature	Ticket Granting Ticket (TGT)	Service Ticket (ST)
Purpose	Proves the user’s identity and allows them to request service tickets	Grants access to a specific service (e.g., HDFS, Spark, SSH)
Issued By	Authentication Service (AS) within the KDC	Ticket Granting Service (TGS) within the KDC
Used For	Requesting service tickets (STs) from the KDC	Accessing a specific service
Validity Period	Typically valid for several hours (e.g., 10 hours)	Shorter lifespan (usually same as or shorter than TGT)
Encrypted With	KDC’s secret key	Service’s secret key
Stored In	User’s credential cache (klist command shows it)	Also stored in the credential cache but used for service authentication
Authentication Flow	First step in Kerberos authentication	Second step after obtaining a TGT

Below is an example of viewing tickets in linux

# example of viewing TGT and ST
klist

# example output
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: user@CASD.EU

Valid starting     Expires            Service principal
03/25/25 12:00:00  03/25/25 22:00:00  krbtgt/CASD.EU@CASD.EU  (TGT)
03/25/25 12:05:00  03/25/25 22:00:00  hdfs/namenode.casd.eu@CASD.EU (Service Ticket)

By default, in linux all krb tickets of a user are stored in a file /tmp/krb5cc_1000, where 1000 is the uid number of the user.

Below is an example of viewing tickets in windows

# example of viewing TGT and ST
klist

# example output
Credential cache: C:\Users\user\krb5cc_user
Default principal: user@CASD.EU

Valid starting     Expires            Service principal
03/25/25 12:00:00  03/25/25 22:00:00  krbtgt/CASD.EU@CASD.EU  (TGT)
03/25/25 12:05:00  03/25/25 22:00:00  hdfs/namenode.casd.eu@CASD.EU (Service Ticket)

By default, in windows, all krb tickets of a user are stored in a file C:\Users\user\krb5cc_user.

The user principal is user@CASD.EU
The first ticket with service principal (krbtgt/CASD.EU@CASD.EU) is the TGT.
The second ticket with service principal (hdfs/namenode.casd.eu@CASD.EU) is the Service Ticket for accessing HDFS.

1.5 Keytab¶

A .keytab file stores the encrypted credentials for non-interactive authentication.

It's often used by services and automated scripts to authenticate to Kerberos and request a ticket without user intervention.

A .keytab file can contain one or more encryption keys linked to a Kerberos principal.

1.6 Encryption algos and keys¶

As we explained before, Kerberos uses symmetric encryption algorithms to secure authentication (e.g. tickets and keytabs). It supports many algorithms to fits different hardware and OS requirements. Below are some supported algo - AES256-CTS-HMAC-SHA1-96 (Strongest, preferred) - AES128-CTS-HMAC-SHA1-96 - RC4-HMAC (Weaker, legacy)

# to check the encryption algo of a ticket, you can use -e option
klist -e

The algo AES256-CTS-HMAC-SHA1-96 can be break down into three parts: - AES256: symmetric encryption algorithm which encrypts the shared secrets between user and KDC - CTS(Ciphertext Stealing): helps encrypt data of any size without an anomaly. Because encryption works on fixed blocks of data (e.g., 16 bytes at a time) - HMAC-SHA1-96: ensures the integrity of the ticket or credentials in the keytab file. HMAC (Hash-Based Message Authentication Code)

1.7 Summary¶

Below is a summary of import terms in Kerberos

Term	Description
Key Distribution Center(KDC)	checking user credentials and issuing Tickets
Realm	The administrative domain that includes a KDC and a number of Clients.
Principal	The unique name of a user or service that authenticates against the KDC
Ticket Granting Ticket(TGT)	A ticket that proves the user identity to request other tickets
Service Ticket(ST)	A ticket that grants access to a specific service
Keytab	A file that includes one or more principals and their associated keys.

2. Introduction to Kerberos Authentication protocol¶

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. It has the following characteristics:

It is secure: it never sends a password unless it is encrypted.
Only a single login is required per session. Credentials defined at login are then passed between resources without the need for additional logins.
The concept depends on a trusted third party a Key Distribution Center (KDC). The KDC is aware of all systems in the network and is trusted by all of them.
It performs mutual authentication, where a client proves its identity to a server, and a server proves its identity to the client.

Kerberos introduces the concept of a Ticket-Granting Server (TGS). A client that wishes to use a service has to receive a ticket a time-limited cryptographic message giving it access to the server. Kerberos also requires an Authentication Server (AS) to verify clients. The two servers combined make up a KDC.

The following figure shows the sequence of events required for a client to gain access to a service using Kerberos authentication. Each step is shown with the Kerberos message associated with it, as defined in RFC 4120 “The Kerberos Network Authorization Service (V5)”.

Step 1: The user logs on to the workstation and requests service on the host. The workstation sends a message to the Authorization Server requesting a ticket granting ticket (TGT).
Step 2: The Authorization Server verifies the user’s access rights in the user database and creates a TGT and session key. The Authorization Sever encrypts the results using a key derived from the user’s password and sends a message back to the user workstation. The workstation prompts the user for a password and uses the password to decrypt the incoming message. When decryption succeeds, the user will be able to use the TGT to request a service ticket.
Step 3: When the user wants access to a service, the workstation client application sends a request to the Ticket Granting Service containing the client name, realm name and a timestamp. The user proves his identity by sending an authenticator encrypted with the session key received in Step 2.
Step 4: The TGS decrypts the ticket and authenticator, verifies the request, and creates a ticket for the requested server. The ticket contains the client name and optionally the client IP address. It also contains the realm name and ticket lifespan. The TGS returns the ticket to the user workstation. The returned message contains two copies of a server session key one encrypted with the client password, and one encrypted by the service password.
Step 5: The client application now sends a service request to the server containing the ticket received in Step 4 and an authenticator. The service authenticates the request by decrypting the session key. The server verifies that the ticket and authenticator match, and then grants access to the service. This step as described does not include the authorization performed by the Intel AMT device, as described later.
Step 6: If mutual authentication is required, then the server will reply with a server authentication message.

3. Time synchronization¶

To prevent replay attacks, Kerberos uses timestamps as part of its protocol definition. For timestamps to work properly, the clocks of the client and the server need to be in synch as much as possible. Since the clocks of two computers are often out of synch, administrators can establish a policy to establish the maximum acceptable difference to Kerberos between a client's clock and server's clock. If the difference between a client's clock and the server's clock is less than the maximum time difference specified in this policy, any timestamp used in a session between the two computers will be considered authentic. The maximum difference is usually set to five minutes.

Note that if a client application wishes to use a service that is "Kerberized" (the service is configured to perform Kerberos authentication), the client must also be Kerberized so that it expects to support the necessary message responses.

Reference¶

https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fintroductiontokerberosauthentication.htm
http://web.mit.edu/kerberos/www/.