Thank you for those that responded. Alec Kloss (off-list and almost immediately), Phil Pennock, Dan White, Henry Hotz. Problem solved. I was getting the service ticket on the client. I had used the env variable KRB5_KTNAME to set a different keytab. I spelled the env variable wrong, therefore the server did not find the keytab. I did a bit of poking into the code to figure that out, though a careful read of the setup would have spotted it. Sorry to top post. I responded to Alec earlier but didn't realize that the list was not on the Cc. Curtis In message <0CCA6493-5E7A-41F4-A7C7-178B65C5C652@xxxxxxxxxxxx> "Henry B. Hotz" writes: > 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