How does keytab work exactly?

Question

i have some questions on using keytab for Authentication hope the kind people here can enlightend me

Say, i have userA who is going to use a service running at port 1010. First, userA will login to Active Directory to authenticate himself.

After login, userA will try to connect to the server to use its service 1010. In order for the server to verify that UserA is who he is, I need to use setspn to register SPN at the Active Directory. eg

setspn -s service1010/mydomain.com serviceaccount1

Then need to generate ktab file at Active directory, eg

ktab -a serviceprincal1010/[email protected] -k mykeytab.keytab

and then bring mykeytab.keytab to the server.

At the server, I would use JAAS with a login config to query the KDC eg

ServicePrincipalLoginContext
{
  com.sun.security.auth.module.Krb5LoginModule required    
  principal=serviceprincal1010/[email protected] 
  doNotPrompt=true useKeyTab=true keyTab=mykeytab.keytab storeKey=true;

};

From this point on, I am confused. How does userA get verified (ie, userA is actually who he is? ).

Answer 1

Your diagram is wrong. You have a basic misunderstanding about how kerberos works. ( It's fairly common by the way). A service that uses kerberos for authentication NEVER talks to the kdc. All it ever does is use it's secret key ( keytab ) to decrypt blobs that are presented by the user.

The only part of kerberos that ever talks to the KDC is the client or user side. When it attempts to access the service at port 1010, it first asks the KDC for a service ticket for that service. This is a blob encrypted with the service's secret key that has the user's identity inside it. ( plus a bunch of other protocol related stuff ).

If you have an GSS based api inside your service on port 1010, all you need to do is tell that API where the keytab is and then ask it what the userid is on the connection. You never need to make any other connections to external services. I am not familiar with the Java API's, but there should only be one or two calls required to verify the user credentials.

While this dialogue doesn't exactly match the version of Kerberos currently in use, it will help you understand the basic principals.

http://web.mit.edu/kerberos/dialogue.html

Answer 2

To understand this, you must understand the basic principles of Kerberos, which is a "trusted third party" security system.

Your server will receive a "token" which the Ticket-Granting Service (TGS; basically, the Windows Domain Controller) has encrypted using the server's secret key, the one which is present in the keytab file. The server, naturally, will need access to that secret key in order to decrypt. If the decryption is successful, this is a guarantee to the server that the token is authentic because the secret key is known only to the TGS and the server—that's the secret these two parties share.

The phrase "trusted 3rd party" refers to the TGS because the server (party 1) allows the user (party 2) to be authenticated because it indirectly trusts the TGS (party 3).