Configuring Kerberos Authentication Protocol

Named after a three-headed hound guarding the gates of Hades in Ancient Greek myths, Kerberos protocol provides secure authentication service for computer networks. It performs mutual authentication between the user and the server with the help of a trusted third-party Key Distribution Center (KDC) that provides authentication and ticket-granting service. All major operating systems, including Microsoft Windows, Linux, Apple OS X and FreeBSD, support the Kerberos protocol.

Kerberos protocol messages are protected against replay attacks and eavesdropping by means of shared secret cryptography. The main purpose of Kerberos is to avoid transmission of encrypted passwords across the network. It eliminates the threat of packet sniffers and enhances overall network security.

Why Kerberos Authentication Matters

Kerberos authentication is a foundational protocol for secure, centralized user verification across enterprise networks. It enables mutual trust between users and services without sending passwords over the network, reducing exposure to credential theft and man-in-the-middle attacks.

Today, Kerberos is widely used in Active Directory domains, enterprise single sign-on systems, and secure cloud environments. Its ticket-based model ensures scalable and efficient authentication, especially in complex, multi-tier infrastructures.

Tools like DataSunrise support Kerberos authentication by acting as a secure proxy, enforcing Active Directory policies while managing access to critical data assets—on-premises or in the cloud.

Although Kerberos security support provider effectively deals with severe security threats, it may be difficult to implement due to a variety of limitations:

• If the Kerberos server is down, users can’t log in. The problem can be solved by using fallback authentication mechanisms and multiple Kerberos servers.
• Clocks of the involved hosts must be synchronized. Otherwise, authentication will failed, as Kerberos tickets have a certain availability period.
• Kerberos cannot be used when users want to connect to services from untrusted systems.
• In case symmetric cryptography is used, compromise of authentication infrastructure will allow an attacker to impersonate any user.
• Each network service that requires a different hostname will need its own set of Kerberos keys.

How Kerberos Authentication Works

A Key Distribution Center consists of an Authentication Server (AS) and Ticket Granting Server (TGS). TGT is a Ticket Granting Ticket.

1. The user enters the login and password. The cleartext user ID goes to the Authentication Server (AS) with a request for services on behalf of the user.
2. AS checks if the user login is in the database. If there is information about that user, then AS can generate a client secret key according to the user’s ID and password. AS sends to the user:
   • The client/TSG session key (encrypted with the client secret key);
   • TGT including the user ID, network address and ticket validity period + Client/TGS session key (encrypted with the TGS secret key).
3. The user decodes the first message but can’t decode the second one, because the user doesn’t have the TSG secret key. The client sends message to the TGS:
   • The TGT received from AS + Server ID + TGS/Client secret key (encrypted with the TGS secret key);
   • The authenticator including the client ID and timestamp (encrypted with the Client/TSG session key).
4. The TGS decrypts the first message, gets the TGT + TGS/Client session key, with which it decrypts the second message. The TGS checks if the user ID from the first message matches the ID from the second message and if the timestamp doesn’t exceed the ticket validity period. In case everything is right, the TSG sends to the user:
   • The used ID, network address, ticket validation period + Client/Server session key (encrypted with the Server secret key);
   • The client/server session key (encrypted with the Client/TGS secret key).
5. The client sends the following to the Server which it tries to get access to:
   • The used ID, network address, ticket validation period + Client/Server session key (encrypted with encrypted with Server secret key);
   • The authenticator including the ID and timestamp (encrypted with the Client/Server session key).
6. The targeted server decrypts user’s messages, checks if the User ID from the both messages have the same value and if the validity period is not exceeded, then sends to the client the following parameter to confirm its identity:
   • Timestamp + 1 (encrypted with the Client/Server session key).

The client checks if the timestamp value is timestamp + 1, which shows the true identity of the server. If it is so, the client can trust the server and start working with it.

Modern Kerberos Applications

Kerberos remains vital in today’s enterprise environments. Cloud providers integrate Kerberos with their identity services. Multi-factor authentication enhances Kerberos security posture. Single sign-on solutions leverage Kerberos for seamless access. Many containerized applications support Kerberos authentication. DevOps pipelines use Kerberos for secure CI/CD workflows. Mobile device management systems incorporate Kerberos principles. Zero Trust architectures often build upon Kerberos foundations. Federated identity solutions extend Kerberos across organizational boundaries. Automated certificate management simplifies Kerberos maintenance. Modern implementations address many traditional Kerberos limitations.

Configuring Kerberos authentication protocol

To configure the Kerberos protocol, you need to do the following:

1. Create an Active Directory user (you can use an existing one instead).
   • Log into the domain controller server, click Start → Administrative Tools, and launch Active Directory Users and Computers.
   • If it is not already selected, click the node for your domain (domain.com).
   • Right-click Users, point to New, and then click User.
   • In the New Object → User dialog box specify the parameters of the new user. It could be a regular user, it is not required to provide the user with some additional privileges. The user account should be active (The Account is disabled check box unchecked), and the password for the account should be perpetual (The Password never expires check-box checked).
2. Assign the principal names with the encrypted keys on the domain controller machine. For machines on Linux, create a keytab file containing pairs of Kerberos principals and encrypted keys. A keytab file is used to authenticate to various remote systems using Kerberos without entering a password.
   • Create a keytab with the first entry using the ktpass tool: ktpass /princ user1_backend@DOMAIN.COM /mapuser user1_backend /pass /crypto all /ptype KRB5_NT_PRINCIPAL /out C:\Users\user1\Desktop \datasunrise.keytab -setupn
     

     /princ	The service principal name (SPN) in the following format: @
     /mapuser	Maps the name of the Kerberos principal, which is specified by the princ parameter, to the specified domain account.
     /pass	Specifies the password for the principal user name.
     /ptype	Specifies the principal type. Use KRB5_NT_PRINCIPAL.
     /crypto	Specifies the keys that are generated in the keytab file.
     /out	Assign a directory and a name for the output *.keytab file.
     -setupn	Doesn’t set the user principal name along with the service principal name.

   • Create a second entry in the keytab file for connecting to the database using the AD user. The example is given for creating keytab entries for connecting to Vertica database using the AD user. For other databases or GUI authentication, perform the same command with corresponding service name in the /princ parameter. ktpass /out ./datasunrise.keytab /princ vertica/user1.domain.com@DOMAIN.COM /mapuser user1 /mapop set /pass /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT
   • You will need to transfer the keytab file to the Linux machine.
3. Configure Active Directory delegation.
   • On the domain controller machine, go to Active Directory Users and Computers, locate the account of the machine that you want to configure Kerberos to.
   • In the Properties section, go to the Delegation tab and select Trust this computer for delegation to specified services only and click Add.
   • In the Users and Computers window, specify the user account that has been used to launch the database or the name of the server where the RDBMS is installed.
   • Optionally, you can use Check names to check if a specified user or computer exists and click OK, then select the required service and click OK.
4. Install and configure the Kerberos client on your machine. sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config

   Edit the /etc/krb5.conf file to add the full domain name, domain controller name and the realm parameter

   Important: Do not leave any comments tagged with the “#” sign in the config file.

   [libdefaults]
       default_realm       =           DOMAIN.COM    # domain specific parameter (full domain name)
       clockskew           =           300
       ticket_lifetime     =           1d
       forwardable         =           true
       proxiable           =           true
       dns_lookup_realm    =           true
       dns_lookup_kdc      =           true
      
    
      [realms]
           DOMAIN.COM = {
           kdc            =       hostname.domain.com   # domain specific parameter (domain controller name)
           admin_server   =       hostname.domain.com   # domain specific parameter (domain controller name)
           default_domain =       DOMAIN.COM         # domain specific parameter (full domain name)
           }
    
   [domain_realm]
           .domain.com = DOMAIN.COM  # domain specific parameter (domain name for dns names)
           domain.com = DOMAIN.COM   # domain specific parameter (domain name for dns names)
    
   [appdefaults]
           pam = {
           ticket_lifetime         = 1d
           renew_lifetime          = 1d
           forwardable             = true
           proxiable               = false
           retain_after_close      = false
           minimum_uid             = 0
           debug                   = false
           }
   

For machines on the Windows OS, you don’t need to install and configure the Kerberos protocol but it must be in the Active Directory domain. Also, to set the service principal names the setspn command is used. Below is an example of configuring a Windows machine to connect to the MS SQL Server database using the AD user credentials.

The proxy address has to match the registered SPN of MSSQLSvc service. Use the SetSPN tool to register the two required SPN’s for the account of the computer, for which you have allowed delegation:

The list of all the registered SPN’s can be obtained by the following command:

To delete the SPN proxy, do the following:

For the testing authorization scheme execute the following command after connecting to the server:

The result will be corresponding to the authentication scheme which has been used by the server: SQL, NTLM or KERBEROS.

In case you get the error “Cannot generate SSPI context”, refer to the Microsoft support instructions on how to fix the issue with the security support provider interface.

DataSunrise can function as an authentication proxy for cloud and on-premises databases to minimize the risks of unauthorized user access maintaining the authentication policies of Microsoft Active Directory and Kerberos protocol.

Does your database or cloud-based storage contain sensitive information that requires protection? Do you need to comply with GDPR, SOX, or HIPAA regulations? Discover DataSunrise’s cutting-edge solutions for database auditing, security, and data masking. Try our software for free or schedule an online demo today.