Using Kerberos Authentication Relay

Kerberos authentication is a computer authentication protocol that works on the basis of tickets (i.e., credentials). It provides several authentication choices, allowing nodes communicating over a non-secure network to verify each others' identity securely via a Key Distribution Center (KDC) and Service Tickets (STs). It is primarily used for client-server authentication model and provides mutual authentication by which both the client and the server verify each others' identity.

Kerberos authentication is built upon symmetric key cryptography and requires a trusted third party, and may also resort to the use of public-key cryptography in certain phases of the authentication process. By default, Kerberos Authentication Relay uses UDP port 88.

The Kerberos authentication consists of the following logical components:

Client
Authentication Server (AS)
Ticket Granting Server (TGS)
Service Server (SS)

Often, the AS and TGS are located on the same physical server, i.e., the KDC.

Authentication Workflow

The following paragraphs highlight the workflow of Kerberos authentication.

Step 1: Client authentication

The client sends a cleartext (i.e., unencrypted) message of the user ID to the Authentication Server (AS ) requesting services that the user wants to use. The client does not send either the secret key or the password to the AS. The AS generates the secret key by hashing the password of the user found at the database, e.g., Active Directory in Windows Server. The AS then checks to see if the client is in its database. If it is in the database, the AS sends back the following two messages to the client:

Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
Message B: Ticket Granting Ticket (TGT) which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

Once the client receives Messages A and B, it attempts to decrypt Message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key, the client decrypts Message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. Note that the client cannot decrypt Message B, as it is encrypted using TGS's secret key. At this point, the client has enough information to authenticate itself to the TGS.

Step 2: Client service authorization

When requesting services, the client sends the following messages to the TGS:

Message C: Composed of the TGT from Message B and the ID of the requested service.
Message D: Authenticator, which is composed of the client ID and the time-stamp, encrypted using the Client/TGS Session Key.

Upon receiving Messages C and D, the TGS retrieves Message B out of Message C. It decrypts Message B using the TGS secret key. This gives the TGS the "client/TGS session key". Using this key, the TGS decrypts Message D (Authenticator) and sends the following two messages to the client:

Message E: Client-to-server ticket, which includes the client ID, client network address, validity period, and Client/Server Session Key, encrypted using the service's secret key.
Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Step 3: Client service request

Upon receiving Messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:

Message E: From the previous step (the client-to-server ticket, encrypted using service's secret key).
Message G: A new Authenticator, which includes the client ID and time-stamp encrypted using the Client/Server Session Key.

The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, the SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:

Message H: The time-stamp found in client's Authenticator, plus 1 in version 4, but not necessary in version 5[2][3]), encrypted using the Client/Server Session Key.

The client decrypts the confirmation using the Client/Server Session Key and checks whether the time-stamp is correct. If it is correct, then the client can trust the server and start issuing service requests to the server.

The server provides the requested services to the client.

FortiADC Kerberos authentication implementation

Implementation of Kerberos authentication involves the following configurations in FortiADC:

Authentication Relay. See the following pragraph.
User Group. See Configuring user groups.
Authentication Policy. See Configuring authentication policies
Virtual Server. See Configuring virtual servers

Configure Authentication Relay (Kerberos)

Use the following steps to configure Kerberos authentication:

Click User Authentication > Authentication Relay.
Click Create New to open the configuration editor dialog.
Make the desired entries or selections as described in Kerberos authentication configuration.
Click Save when done.

Kerberos authentication configuration
Settings	Guidelines
Name	Specify the name of the configuration.
Delegation Type	Kerberos (Be sure to select this option.) HTTP Basic
KDC IP	Enter the IP address of the KDC.
KDC Port	88
Realm	Specify the realm in all upper-case characters.
Delegator Account	Specify the delegator account. Required.
Delegator Password	Specify the delegator password. Required.
Authorization	HTTP Error 404 Always
Delegated SPN	Specify the delegated SPN. Required.
Add Default Domain	Disabled by default. When selected, specify the default domain below.
Default Domain	Enter the default domain.

Kerberos Connectivity Test

After creating a Kerberos Authentication relay, the Test function will appear:

Click on the Test symbol, and it will open the User Principle dialogue. Set a user name.

If you do the Kerberos relay configuration and the user principle was corrected, you will get this response.

If it failed, you will get an error prompt.