Configuring Kerberos Authentication Protocol

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 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 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.

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

  • If 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 be failed, as Kerberos tickets have 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


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

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

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

Configuring Kerberos authentication protocol

To configure 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 (
    • 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. 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 principal names with 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 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
      /princService principal name (SPN) in the following format: @
      /mapuserMaps the name of the Kerberos principal, which is specified by the princ parameter, to the specified domain account.
      /passSpecifies a password for the principal user name.
      /ptypeSpecifies the principal type. Use KRB5_NT_PRINCIPAL.
      /cryptoSpecifies the keys that are generated in the keytab file.
      /outAssign a directory and a name for the output *.keytab file.
      -setupnDoesn’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/ /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 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 a required service and click OK.
  4. Install and configure 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 parameterImportant: Do not leave any comments tagged with the “#” sign in the config file.

        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
            DOMAIN.COM = {
            kdc            =   # domain specific parameter (domain controller name)
            admin_server   =   # domain specific parameter (domain controller name)
            default_domain =       DOMAIN.COM         # domain specific parameter (full domain name)
   = DOMAIN.COM  # domain specific parameter (domain name for dns names)
   = DOMAIN.COM   # domain specific parameter (domain name for dns names)
            pam = {
            ticket_lifetime         = 1d
            renew_lifetime          = 1d
            forwardable             = true
            proxiable               = false
            retain_after_close      = false
            minimum_uid             = 0
            debug                   = false

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

Proxy address has to match registered SPN of MSSQLSvc service. Use SetSPN tool to register two required SPN’s for the account of the computer, for which you have allowed delegation: setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

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

setspn -L proxy-host

To delete SPN proxy, perform the following:

setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

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

select auth_scheme from sys.dm_exec_connections where session_id=@@spid

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

In case you get an error “Cannot generate SSPI context”, refer to Microsoft support instructions of how to fix the issue with 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.

Download free 30 days Trial