SASL

[Brendan Kearney]

On Wed, 2015-04-22 at 20:46 +0100, Arran Cudbard-Bell wrote:
> > On 22 Apr 2015, at 18:56, Brendan Kearney <bpk678 at gmail.com> wrote:
> > 
> > i see that in 3.0.7 SASL binds were introduced and that non-interactive
> > methods are available.  does this mean kerberos5 or gssapi methods can
> > be used?  does this mean that the keytab i have for the krb5 module can
> > be used by the ldap module to bind to the directory?
> 
> No. 3.1.x may. But the krb5 module would have to be modified to have an option to keep user's TGT in the keytab once authentication had completed. It doesn't currently, as that was causing slowdowns in 2.2.x.
> 
> Not sure though, might be weirdness with two versions of the kerberos library accessing the same keytab. Locks aren't visible to the process that created them.
> 
> Is there any kind of keytab daemon that could act as an arbiter for keytab access?
> 
> -Arran
> 
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS development team
> 
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

why would two different kerberos libraries be used?  my understanding
was that the gssapi library was meant to simplify all of that, but you
are already out of my depth...

as far as i know about TGTs and keeping tickets, the keytab is not
written to when a TGT is retrieved from the KDC.  the keytab is a
glorified passoword file, with some additional stuff.  the "KRB_CC" or
credential cache (maintainted in /tmp/krb5cc_<uid#>_<random#>
or /tmp/krb5ccmachine_<KDC_REALM> for the host) is where the TGT and all
other tickets are housed once the keytab is used to obtain the TGT.  i
believe if you know where the cc is, you can point gssapi at it, and
solve for the krb module and ldap module needing to use tickets.

k5start might be an arbiter that you seek.  it supposedly assists with
ldap starting up and using kerberos tickets for replication.