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@xxxxxxxxxxxx, or hbhotz@xxxxxxx
