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 effectively deals with severe security threat, 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 host name 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.
- User enters login and password. Cleartext user ID goes to Authentication Server (AS) with request of services on behalf of the user.
- 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).
- User decodes the first message but can’t decode the second one, because 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).
- 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 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).
- 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).
- 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 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, client can trust the server and start working with it.
Kerberos and DataSunrise
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 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:
- Delegation for Active Directory Users and Computers must be enabled.
- Go to Active Directory Users and Computers.
- Find the computer account on which the firewall is installed.
- Go to Delegation tab and switch to “Trust this computer for delegation to any service” state.
- 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.
- In case you get an error “Cannot generate SSPI context”, refer to instructions of Microsoft support.