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

[Alec Kloss]

My bad.  I certainly thought I replied on-list, but mistakes are
sometimes made.  It was a happy coincidence that I happened to be
feeling chatty shortly after the question was sent.

On 2012-09-05 16:07, Curtis Villamizar wrote:
> 
> 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 at jpl.nasa.gov>
> "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 at jpl.nasa.gov, or hbhotz at oxy.edu

-- 
Alec Kloss                              Email/Jabber IM:  alec at SetFilePointer.com
PGP key:             http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x891C04E5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20120905/beee463b/attachment.bin