Appendices

Dummy UserDetailsService used in samples because we don’t have a real user source.

In any authentication process there are usually a three parties involved.

First is a client which sometimes is a client computer but in most of the scenarios it is the actual user sitting on a computer and trying to access resources. Then there is the resource user is trying to access. In this example it is a web server.

Then there is a Key Distribution Center or KDC. In a case of Windows environment this would be a Domain Controller. KDC is the one which really brings everything together and thus is the most critical component in your environment. Because of this it is also considered as a single point of failure.

Initially when Kerberos environment is setup and domain user principals created into a database, encryption keys are also created. These encryption keys are based on shared secrets(i.e. user password) and actual passwords are never kept in a clear text. Effectively KDC has its own key and other keys for domain users.

Interestingly there is no communication between a resource and a KDC during the authentication process.

When client wants to authenticate itself with a resource it first needs to communicate with a KDC. Client will craft a special package which contains encrypted and unencrypted parts. Unencrypted part contains i.e. information about a user and encrypted part other information which is part of a protocol. Client will encrypt package data with its own key.

When KDC receives this authentication package from a client it checks who this client claims to be from an unencrypted part and based on that information it uses client decryption key it already have in its database. If this decryption is succesfull KDC knows that this client is the one it claims to be.

What KDC returns to a client is a ticket called Ticket Granting Ticket which is signed by a KDC’s own private key. Later when client sends back this ticket it can try to decrypt it and if that operation is succesfull it knows that it was a ticket it itself originally signed and gave to a client.

When client wants to get a ticket which it can use to authenticate with a service, TGT is send to KDC which then signs a service ticket with service’s own key. This a moment when a trust between client and service is created. This service ticket contains data which only service itself is able to decrypt.

When client is authenticating with a service it sends previously received service ticket to a service which then thinks that I don’t know anything about this guy but he have me an authentication ticket. What service can do next is try to decrypt that ticket and if that operation is succesfull it knows that only other party who knows my credentials is the KDC and because I trust him I can also trust that this client is a one he claims to be.

Doing a production setup of Kerberos environment is out of scope of this document but this appendix provides some help to get you started for setting up needed components for development.

This appendix provides generic information about troubleshooting errors and problems.

If you see abore error indicating missing key type, this will happen with two different use cases. Firstly your JVM may not support appropriate encryption type or it is disabled in your krb5.conf file.

Second case is less obvious and hard to track because it will lead into same error. This specific GSSException is throws also if you simply don’t have a required encryption key which then may be caused by a misconfiguration in your kerberos server or a simply typo in your principal.

​

In most system all commands and libraries will search kerberos configuration either from a default locations or special locations like JDKs. It’s easy to get mixed up especially if working from unix systems, which already may have default settings to work with MIT kerberos, towards Windows domains.

This is a specific example what happens with ldapsearch trying to query Windows AD using kerberos authentication.

Well that doesn’t look good and is a simple indication that I don’t have a valid kerberos tickets as shown below.

We already have a keytab file we exported from Windows AD to be used with tomcat running on Linux. Lets try to use that to authenticate with Windows AD.

You can have a dedicated config file which usually can be used with native Linux commands and JVMs via system propertys.

Lets use that config and a keytab to get initial credentials.

Lets see what happens if we now try to do a simple query against Windows AD.

This may be simply because ldapsearch is getting confused and simply using wrong configuration. You can tell ldapsearch to use a different configuration via KRB5_CONFIG env variable just like we did with kinit. You can also use KRB5_TRACE=/dev/stderr to get more verbose output of what native libraries are doing.

Above you can see what happened if query was successful by looking kerberos tickets. Now you can experiment with further query commands i.e. if you working with KerberosLdapContextSource.