subversion svn/svnserve SASL with GSSAPI auth not working (for me)

[Henry B. Hotz]

Some other things you can look at are:

1) After it fails, does the cred cache on the client contain a service ticket?

2) If not, does the client even request a ticket?  (Use snoop/tcpdump.)

3) If so, does it request the *right* service ticket?  (Use wireshark.)

You can do these things without needing access to the kdc logs, and they will frequently tell you similar things about what might be wrong in a client configuration.

On Sep 3, 2012, at 9:08 PM, Dan White wrote:

> 'unknown mech-code 0 for mech' appears in several sasl and non-sasl related
> returns with a google search. I guess that it originates from heimdal.
> 
> Check your kdc logs. This could be something as simple as a dns
> disagreement as to what principal the server should be using.
> 
> The order, as I understand it, is:
> 
> The client obtains a TGT from the kdc
> The client initiates a connection with the svn server
> The server returns with a string that contains the supported sasl
> mechanisms
> The client chooses an appropriate mechanism
> If gssapi, then:
>  obtain a service ticket from the kdc
>  complete authentication with the svn server using the service ticket
>  (this step is where things appear to go awry, and points to a possible
>  service name mismatch)
> 
> Make sure that your server contains a matching keytab entry as in your
> svn/<host>@<krb5-realm> output from above. Explicitly provide a hostname
> within your svnserv.conf, for sasl initialization, if it allows for such a
> configuration. If not, verify that 'hostname -f' looks correct on your svn
> server.
> 
> If you restart your svn server, you should see which principal it is
> requesting from your kdc (or at least, the first time it initializes sasl).
> 
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu