Skip to main content

Kerberos

https://web.mit.edu/kerberos/

SSO (single sign-on):​

  • Less time spent managing credentials with a single sign-in.
  • Only one master password instead of multiple credentials vulnerable to password attacks.
  • Easy access to apps needed for work.

Kerberos provides SSO capabilities tailored for authentication across networked applications and services.​

Kerberos​

kerberos-02.jpg

In a Kerberos system, once you log in, you get a special ticket that lets you go into different places without entering your password each time.

Components of a Kerberos​

  • Kerberos Principal:
    A Kerberos principal is a unique identity to which Kerberos can assign tickets. Principals can have an arbitrary number of components. Each component is separated by a component separator, generally /. The last component is the realm, separated from the rest of the principal by the realm separator, generally @. If there is no realm component in the principal, then it will be assumed that the principal is in the default realm for the context in which it is being used.

    Traditionally, a principal is divided into three parts: the primary, the instance, and the realm. The format of a typical Kerberos V5 principal is primary/instance@REALM.

    • The primary is the first part of the principal. In the case of a user, it's the same as your username. For a host, the primary is the word host.
    • The instance is an optional string that qualifies the primary. The instance is separated from the primary by a slash (/). In the case of a user, the instance is usually null, but a user might also have an additional principal, with an instance called admin, which he/she uses to administrate a database. The principal jennifer@ATHENA.MIT.EDU is completely separate from the principal jennifer/admin@ATHENA.MIT.EDU, with a separate password, and separate permissions. In the case of a host, the instance is the fully qualified hostname, e.g., daffodil.mit.edu.
    • The realm is your Kerberos realm. In most cases, your Kerberos realm is your domain name, in upper-case letters. For example, the machine daffodil.example.com would be in the realm EXAMPLE.COM.

  • User and Service Principal names:
    In Kerberos, user and service principal names follow the format of username@REALM or service/instance@REALM, where REALM is the Kerberos realm or domain name, and username or service/instance is the user or service identifier.

    • User Principal Name (UPN): Kerberos uses UPNs to identify users, which are in the format username@REALM.
    • Service Principal Name (SPN): SPNs identify services and follow the format service/instance@REALM.
    • Realm: The realm is the domain or Kerberos domain that the user or service belongs to.
    • Examples:
      • User: jdoe@SALES.WIDGET.COM
      • Service: WAS/test.austin.ibm.com@AUSTIN.IBM.COM

  • Key Distribution Center (KDC): The KDC acts as a trusted third party, managing authentication services using symmetric-key cryptography. All network members, including clients and servers, are registered with the KDC, which securely maintains their secret keys.

  • Ticket: A ticket serves as an encrypted message providing evidence that a subject is authorized to access a specific object. Also known as a service ticket (ST), users request tickets to access files or other objects. Tickets have set lifetimes and usage parameters, requiring renewal or reissuing once expired. Your Kerberos credentials, or “tickets”, are a set of electronic information that can be used to verify your identity. Your Kerberos tickets may be stored in a file, or they may exist only in memory.

    The first ticket you obtain is a ticket-granting ticket (TGT), which permits you to obtain additional tickets. These additional tickets give you permission for specific services. The requesting and granting of these additional tickets happens transparently.

    A good analogy for the ticket-granting ticket is a three-day ski pass that is good at four different resorts. You show the pass at whichever resort you decide to go to (until it expires), and you receive a lift ticket for that resort. Once you have the lift ticket, you can ski all you want at that resort. If you go to another resort the next day, you once again show your pass, and you get an additional lift ticket for the new resort. The difference is that the Kerberos V5 programs notice that you have the weekend ski pass, and get the lift ticket for you, so you don't have to perform the transactions yourself.

  • Base Master Key Name
    The master key is the foundation of Kerberos security, used to encrypt and decrypt the KDC database, which stores the keys of all principals in the realm.

    In Kerberos, the "base master key name" or "master key principal" is typically formatted as K/M@REALM, where K/M represents the KDC (Key Distribution Center) and @REALM specifies the Kerberos realm.

    To reset the Kerberos principal database (typically located in /var/lib/krb5kdc/principal), you'll need to use the kdb5_util tool to destroy and recreate the database.

  • Ticket-Granting Ticket (TGT): The TGT offers proof that a subject has authenticated through the KDC and is authorized to request tickets for accessing various objects. Encrypted and containing a symmetric key, expiration time, and user’s IP address, the TGT is presented when requesting tickets for object access.

  • krbtgt: KRBTGT stands for "Kerberos Ticket-Granting Ticket". The krbtgt account is used by the KDC to encrypt and sign Kerberos tickets, specifically Ticket Granting Tickets (TGTs), which are used for initial authentication.

  • Kerberos Authentication Server: The authentication server encompasses the functions of the KDC, housing both a ticket-granting service (TGS) and an authentication service (AS).

  • Ticket Granting Service (TGS):

    • To start the authentication process, the client sends a request to the authentication server for a specific user principal. This request is sent without encryption. No secure information is included in the request, so it is not necessary to use encryption.
    • When the request is received by the authentication service, the principal name of the user is looked up in the KDC database. If a principal matches the entry in the database, the authentication service obtains the private key for that principal. The authentication service then generates a session key to be used by the client and the ticket-granting service (call it Session key 1) and a ticket for the ticket-granting service (Ticket 1). This ticket is also known as the ticket-granting ticket (TGT). Both the session key and the ticket are encrypted by using the user's private key, and the information is sent back to the client.
    • The client uses this information to decrypt Session Key 1 and Ticket 1, by using the private key for the user principal. Because the private key should only be known by the user and the KDC database, the information in the packet should be safe. The client stores the information in the credentials cache.

  • Kerberos Realm: In Kerberos terminology, a realm is a logically controlled area, like a domain or network, governed by Kerberos. Principals within the realm can request tickets from Kerberos, and the system can issue tickets to these principals within the defined realm.

  • Keytab name: FILE:/etc/krb5.keytab. This is the system keytab file, which is the default file for all keys that might be needed for services on this host, and we can list them with klist -k.

Setup Kerberos on a local Ubuntu machine​

1. Install Kerberos Packages​

sudo apt update
sudo apt install krb5-kdc krb5-admin-server krb5-user -y

2. Configure Kerberos Realms​

Edit the Kerberos configuration file /etc/krb5.conf to define the realms and the servers that will be used for authentication:

sudo nano /etc/krb5.conf

Under the [realms] section, specify your domain:

[realms]
 YOURDOMAIN.COM = {
  kdc = your.server.com
  admin_server = your.server.com
 }

Replace YOURDOMAIN.COM with your desired domain name (e.g., EXAMPLE.COM) and your.server.com with the hostname of your Kerberos server (or localhost if running locally).
In our case:

[realms]
 JREACT.EXAMPLE.COM = {
  kdc = localhost
  admin_server = localhost
 }
  • This package contains the administrative tools required to run the Kerberos master server.
  • Installing this package does not automatically set up a Kerberos realm. This can be done later by running the "krb5_newrealm" command
  • Please also read the /usr/share/doc/krb5-kdc/README.KDC file and the administration guide found in the krb5-doc package

3. Create the Kerberos Database​

Initialize the Kerberos database with the following command:

sudo krb5_newrealm
krb5_newrealm
This script should be run on the master KDC/admin server to initialize
a Kerberos realm.  It will ask you to type in a master key password.
This password will be used to generate a key that is stored in
/etc/krb5kdc/stash.  You should try to remember this password, but it
is much more important that it be a strong password than that it be
remembered.  However, if you lose the password and /etc/krb5kdc/stash,
you cannot decrypt your Kerberos database.
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 'JREACT.EXAMPLE.COM',
master key name 'K/M@JREACT.EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:

Enter a secure password when prompted; this will be the master password for the Kerberos database.

Initializing database '/var/lib/krb5kdc/principal' for realm 'JREACT.EXAMPLE.COM',
master key name 'K/M@JREACT.EXAMPLE.COM'

4. Create a Keytab File​

A keytab (short for “key table”) stores long-term keys for one or more principals.
A keytab can be displayed using the klist command with the -k option.
Keytabs can be created or appended to by extracting keys from the KDC database using the kadmin ktadd command. Keytabs can be manipulated using the ktutil and k5srvutil commands.

Use the kadmin​

kadmin.local
kadmin.local: ktadd -k /etc/krb5/admin.keytab -norandkey admin/admin@JREACT.EXAMPLE.COM
kadmin.local: exit
kinit -k -t  /etc/krb5/admin.keytab admin/admin@JREACT.EXAMPLE.COM
klist

Output:​

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/admin@JREACT.EXAMPLE.COM

Valid starting       Expires              Service principal
04/10/2025 10:23:20  04/10/2025 20:23:20  krbtgt/JREACT.EXAMPLE.COM@JREACT.EXAMPLE.COM
renew until 04/11/2025 10:23:19

see: Viewing Your Tickets with klist

5. Modify Access Controls​

To allow your admin principal to manage the Kerberos database, edit /etc/krb5kdc/kadm5.acl:

sudo nano /etc/krb5kdc/kadm5.acl

Add the following line, replacing youradminusername with your actual admin username:

*/admin@JREACT.EXAMPLE.COM    *

6. Start and Enable Kerberos Services​

sudo systemctl enable krb5-kdc krb5-admin-server
sudo systemctl start krb5-kdc krb5-admin-server

7. Test​

klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin/admin@JREACT.EXAMPLE.COM

Valid starting       Expires              Service principal
04/10/2025 10:23:20  04/10/2025 20:23:20  krbtgt/JREACT.EXAMPLE.COM@JREACT.EXAMPLE.COM
	renew until 04/11/2025 10:23:19

Ticket Management​

https://web.mit.edu/kerberos/krb5-1.12/doc/user/tkt_mgmt.html

Selected Commands and Utils​

kdb5_util​

kdb5_util is a Kerberos utility used for managing the KDC database, allowing tasks like creating, destroying, dumping, and loading databases, as well as managing the Kerberos master key.

Key Functions and Commands:

  • Creating a Database: Use the kdb5_util create command to initialize a new KDC database.
  • Creating a Stash File: Use kdb5_util create -s to create a stash file, which stores the master key password securely, preventing the need to enter it every time the KDC starts.
  • Destroying a Database: Use kdb5_util destroy to delete the KDC database.
  • Dumping and Loading Databases: Use kdb5_util dump to export the database to a file and kdb5_util load to import it.
  • Stashing and Unstashing the Master Key: Use kdb5_util stash to create or update the master key stash file, and kdb5_util unstash to remove it.
  • Master Key Rollover: Use kdb5_util use_mkey to start using a new master key version and kdb5_util update_princ_encryption to re-encrypt all keys in the new master key.
  • Purging Old Master Keys: Use kdb5_util purge_mkeys to clean up old master keys.

ktutil​

https://web.mit.edu/kerberos/krb5-1.12/doc/admin/admin_commands/ktutil.html

The ktutil command invokes a command interface from which an administrator can read, write, or edit entries in a keytab. (Kerberos V4 srvtab files are no longer supported.)

keytab​

In Kerberos, a keytab file is a file containing encrypted credentials (keys) for specific Kerberos principals, enabling systems to authenticate without requiring password input, often used for service-to-service or automated authentication.

Example:​


ktutil:  add_entry -password -p datanode/localhost@JREACT.EXAMPLE.COM -k 1 -e arcfour-hmac-md5
ktutil:  add_entry -password -p datanode/localhost@JREACT.EXAMPLE.COM -k 1 -e arcfour-hmac
ktutil:  add_entry -password -p datanode/localhost@JREACT.EXAMPLE.COM -k 1 -e arcfour-hmac-exp
ktutil:  write_kt /etc/krb5kdc/kadm5.keytab
kinit -k -t /etc/krb5kdc/kadm5.keytab datanode/localhost@JREACT.EXAMPLE.COM
kadmin.local: list_principals
klist  -kte /etc/krb5kdc/kadm5.keytab

A keytab file is a file that stores long-term keys for one or more Kerberos principals.

It allows Kerberos clients (services or applications) to authenticate to a Kerberos Key Distribution Center (KDC) without needing to interactively enter a password

Each entry in a keytab file typically contains:

  • A Kerberos principal name (e.g., a service account or user account).
  • An encrypted key derived from the principal's password.

klist​

Viewing Your Tickets with klist

klist lists the Kerberos principal and Kerberos tickets held in a credentials cache, or the keys held in a keytab file.
klist shows the validity of your Kerberos ticket and when it will expire along with ticket cache and principal. When you first obtain tickets, you will have only the ticket-granting ticket. The listing would look like this:

Tickets in cache:

klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting     Expires            Service principal
06/07/04 19:49:21  06/08/04 05:49:19  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU

If jennifer connected to the machine daffodil.mit.edu, and then typed klist again, she would have gotten the following result:

klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting     Expires            Service principal
06/07/04 19:49:21  06/08/04 05:49:19  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
06/07/04 20:22:30  06/08/04 05:49:19  host/daffodil.mit.edu@ATHENA.MIT.EDU

Suppose your Kerberos tickets allow you to log into a host in another domain, such as trillium.example.com, which is also in another Kerberos realm, EXAMPLE.COM. If you telnet to this host, you will receive a ticket-granting ticket for the realm EXAMPLE.COM, plus the new host ticket for trillium.example.com. klist will now show:

klist
Ticket cache: /tmp/krb5cc_ttypa
Default principal: jennifer@ATHENA.MIT.EDU

Valid starting     Expires            Service principal
06/07/04 19:49:21  06/08/04 05:49:19  krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
06/07/04 20:22:30  06/08/04 05:49:19  host/daffodil.mit.edu@ATHENA.MIT.EDU
06/07/04 20:24:18  06/08/04 05:49:19  krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
06/07/04 20:24:18  06/08/04 05:49:19  host/trillium.example.com@ATHENA.MIT.EDU

Tickets in keytab file:

# Example:
klist  -kte /etc/krb5/admin.keytab

Output:

KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 04/10/2025 18:03:59 admin/admin@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   1 04/10/2025 18:03:59 admin/admin@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

Adding to Database or Modifying Principals​

https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Adding-or-Modifying-Principals.html

To add a principal to the database, use the kadmin add_principal command, which requires the “add” administrative privilege.

Adding Principals to Keytabs​

https://web.mit.edu/kerberos/krb5-1.4/krb5-1.4.4/doc/krb5-admin/Adding-Principals-to-Keytabs.html

To generate a keytab, or to add a principal to an existing keytab, use the ktadd command from kadmin.

Delete a principal from a keytab​

https://web.mit.edu/kerberos//krb5-1.19/doc/admin/enctypes.html

ktremove​

  • q - run in quiet mode.
  • all - remove all entries for the specified principal
klist  -kte /etc/krb5kdc/kadm5.keytab
Keytab name: FILE:/etc/krb5kdc/kadm5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 04/11/2025 11:35:11 hdfs/localhost@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 04/11/2025 11:35:11 hdfs/localhost@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 04/11/2025 11:36:02 host/localhost@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 04/11/2025 11:36:02 host/localhost@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 04/11/2025 11:36:42 hbase/localhost@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 04/11/2025 11:36:42 hbase/localhost@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

kadmin.local:  ktremove -k /etc/krb5kdc/kadm5.keytab -q hdfs/localhost@JREACT.EXAMPLE.COM # all

Output:​

klist  -kte /etc/krb5kdc/kadm5.keytab
Keytab name: FILE:/etc/krb5kdc/kadm5.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   2 04/11/2025 11:36:02 host/localhost@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 04/11/2025 11:36:02 host/localhost@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
   2 04/11/2025 11:36:42 hbase/localhost@JREACT.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
   2 04/11/2025 11:36:42 hbase/localhost@JREACT.EXAMPLE.COM (aes128-cts-hmac-sha1-96)

kinit​

https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kinit.html

If you do not have a ticket or is expired, you can get it using the kinit command. Kinit will get and cache the ticket for a principal.

enctypes​

https://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Supported-Encryption-Types.html#Supported-Encryption-Types

https://web.mit.edu/kerberos//krb5-1.19/doc/admin/enctypes.html

Any tag in the configuration files which requires a list of encryption types can be set to some combination of the following strings.

des-cbc-crc
    DES cbc mode with CRC-32
des-cbc-md4
    DES cbc mode with RSA-MD4
des-cbc-md5
    DES cbc mode with RSA-MD5
des3-cbc-sha1
des3-hmac-sha1
des3-cbc-sha1-kd
    triple DES cbc mode with HMAC/sha1
des-hmac-sha1
    DES with HMAC/sha1
aes256-cts-hmac-sha1-96
aes256-cts
    AES-256 CTS mode with 96-bit SHA-1 HMAC
aes128-cts-hmac-sha1-96
aes128-cts
    AES-128 CTS mode with 96-bit SHA-1 HMAC
arcfour-hmac
rc4-hmac
arcfour-hmac-md5
    RC4 with HMAC/MD5
arcfour-hmac-exp
rc4-hmac-exp
arcfour-hmac-md5-exp
    exportable RC4 with HMAC/MD5

destroy​

When you are logging out of the system or switching to some other user and want to destroy your active Kerberos ticket by deleting the credential cache, use kdestoy.

kdestroy

krb5-config --all​

In order to get the details on installed Kerberos libraries, use krb5-config command.

krb5-config --all

Kerberos Uninstall from Ubuntu​

  • Check which Kerberos packages are installed:

    dpkg -l | grep krb5

  • Uninstall the Kerberos packages:

    sudo apt remove --purge krb5-user krb5-config libkrb5-3 libkrb5support0

    Adjust based on the actual packages installed.

  • Clean up residual config files and dependencies:

    sudo apt autoremove --purge
    sudo apt clean

  • Optional: Delete Kerberos config files manually (if still present):

    sudo rm -rf /etc/krb5.conf /etc/krb5.keytab /etc/krb5kdc /var/lib/krb5kdc