This document was contributed by Ken Hornstein.
A couple of people have asked me privately, "Hey, how did you get the GSSAPI mechanism to work? I tried, but the sample apps kept failing". (The short answer: I'm a tenacious bastard).
I figured that it couldn't hurt to give a quick explanation as to how you get GSSAPI working with the sample apps, since it wasn't obvious to me, and I consider myself not completely ignorant of GSSAPI and Kerberos.
./sample-server -s host -p ../plugins/.libs
In this example, I am using "host", which already exists on my machine, but only root can read it, so I an running this as root. If you want to use an alternate service name, you will need to create that service in Kerberos, place it in a keytab readable by you, _and_ point your Kerberos library at it (In MIT Kerberos, you can change this by the KRB5_KTNAME environment variable or the configuration file; I believe Heimdal has something similar).
You should get a response similar to:
Generating client mechanism list... Sending list of 3 mechanism(s) S: R1NTQVBJIFBMQUlOIEFOT05ZTU9VUw==
Note that later on (assuming everything works) you might need to paste in lines that are longer than canonical input processing buffer on your system. You can get around that by messing around with stty; while the details vary from system to system, on Solaris you can do something like:
( stty -icanon min 1 time 0 ; ./sample-server -s host -p ../plugins/.libs )
./sample-client -s host -n your.fqdn.here -u kenh -p ../plugins/.libs
You should get a response similar to this:
Waiting for mechanism list from server...
S: R1NTQVBJIFBMQUlOIEFOT05ZTU9VUw== Choosing best mechanism from: GSSAPI PLAIN ANONYMOUS Using mechanism GSSAPI Preparing initial. Sending initial response... C: <.... lots of base 64 data ...> Waiting for server reply...
If GSSAPI isn't selected as the mechanism, there is a few things that might have gone wrong:
You can turn on a healthy amount of debugging information by changing the definition in config.h of the VL macro to (and recompiling libsasl):
#define VL(foo) printf foo;
There is a possibility you might get an error that looks like this:
sample-client: Starting SASL negotiation: generic failure
This can mean that you didn't provide all of the required information to the sample-client (did you provide a service name with -s, the hostname of the service with -n, and a username with -u ?), or that GSSAPI has failed (unfortunately, on the client you cannot find out the internal GSSAPI error; you will need to break out the debugger for that).
One common thing that happens is that on your server you might see the error:
sample-server: Performing SASL negotiation: authentication failure (Requested identity not authenticated identity)
This comes from not having a requested identity (the -u option) that matches the identity that you were authenticated to via the GSSAPI. This is of course mechanism specific, but if for example you're using Kerberos, the Cyrus SASL library strips out the @REALM from your identity if you are in the same realm as the server. So if your Kerberos identity is user@SOME.REALM and the server is in SOME.REALM, you need to specify "user" to the -u flag of the client. If you're accessing a server in a foreign realm, you need to pass the full principal name via the -u option to make this work correctly.
If you complete the negotiation successfully, you should see something that looks like (on both the client and server):
Negotiation complete Username: kenh sample-server: realm: can't request info until later in exchange SSF: 56
If you get to that, then you've done it, and GSSAPI works successfully! If you have questions about any of this, feel free to drop me a line.