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

"Henry B. Hotz" <[email protected]>
Newsgroups gmane.comp.security.cyrus.sasl
Message-ID <[email protected]>
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.
[email protected], or [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.