Firewall Configuration with Kerberos Authentication Protocol

Named after 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 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 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 if 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)

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 the firewall to work with Kerberos authentication protocol

DataSunrise database firewall supports Kerberos authentication protocol. Some setting changes must be implemented to allow Kerberos operations, they may vary according to used RDBMS product. Within this article, we will show how to customize Kerberos on MS SQL Server.

While working in Active Directory user authorization is performed through Security Support Provider Interface (SSPI). There are two protocols that can be used: NTLM and Kerberos. NTLM is a slower and less secure protocol, thus we will contemplate customization of Kerberos only. In order to enable Kerberos, several conditions should be met:

1. Delegation for Active Directory Users and Computers must be enabled.
   • Go to Active Directory Users and Computers.
   • Find the computer account where DataSunrise is installed.
   • Go to Delegation tab and switch to “Trust this computer for delegation to any service” state.
2. Proxy address has to match registered SPN of MSSQLSvc service. Use SetSPN tool to register two required SPN’s for 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.

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