MIT Kerberos v5 client to Windows KDC

  • Last Post 26 March 2018
robertsingers posted this 22 March 2018

Hi there,              I'm currently looking at implementing Kerberos authentication for an application that uses the MIT Kerberos v5 client on its authentication server.  The configuration calls for having the IP address of the KDC and Admin server in the realm section.
In testing it we haven't seen any traffic from the authentication server to the KDC.  All authentication seems to be carried out by comparing the ticket from the Windows client to the keytab.
Can anyone tell me what is meant to happen on the application server to KDC leg and how often it is meant to happen?
Robert Singerse:  rsmsingers@xxxxxxxxxxxxxxxx 

Order By: Standard | Newest | Votes
Parzival posted this 26 March 2018


You stated it is an application in that case you would indeed not see an outgoing call from the application server to the KDC.

When a client connects to your application, the client will connect to the KDC to get a session ticket. This ticket consists out of 2 parts. One part is encoded with the session key of the application server and

the 2nd part is encoded with the client secret key. (The secret key between the KDC and the applicationID and KDC and client).

<replace Azure AD above with your application and AzureADSSO$ with your applicationID in the above image.. I used it for something else but it explains the same>

Now when your client gives the token to your application, your application only has to decrypt its part of the ticket and it will read a session key. Your client can do the same and so, two sides have a common

secret key upon which they can (mutually) authenticate. The actual authentication is a challenge/response encrypted with the SessionKey and a timestamp encrypted with the SessionKey for the mutual authentication.

In some cases your application can go to the KDC to validate the ticket. This is called PAC validation, but its not a common implementation in MITK5 -

Session Tickets (from AD) are by default valid for about 8 hours.. so if the client already has a ticket, it wont have to go to the KDC again.

Hope this clarifies?


robertsingers posted this 26 March 2018

Thanks Roelf.  i figured as much.  Having to put the IP addresses in the config is obviously purely vestigial. 


Parzival posted this 26 March 2018


The IP address on the application (towards the KdC) needs to be there to setup the initial trust between the applicationID and the KDC. This is to ensure the KDC and the applicationID have a key between them so the KDC can encrypt

session tickets with it. 

In Windows this is based on the computer password which changes every 30 days by default. Some implementations do not change the password at all and thus the key in your Linux store is always valid. 

If you change your key, the application needs to talk to the KDC to update it there too. 

If you use constraint delegation your application will talk to the KDC to get a ticket from the KDC on behalf of the user... meaning in that case it will also initiate traffic.