that interop mess: ldap, samba, kerberos

[Turbo Fredriksson]

Quoting Dennis Davis <D.H.Davis at bath.ac.uk>:

> On Tue, 22 Nov 2005, Sam Hartman wrote:
>
>> From: Sam Hartman <hartmans at mit.edu>
>> To: Turbo Fredriksson <turbo at bayour.com>
>> Cc: kerberos at mit.edu
>> Date: Tue, 22 Nov 2005 05:38:58 -0500
>> Subject: Re: that interop mess: ldap, samba, kerberos
>> 
>> >>>>> "Turbo" == Turbo Fredriksson <turbo at bayour.com> writes:
>> 
>>     Turbo> Eh... What? From what I know, slapd don't have any means of
>>     Turbo> specifying a keytab so even if you create one, slapd won't
>>     Turbo> use it...
>> 
>> Well, slapd may be buggy.  I'd like to think that saslauthd isn't
>> buggy in this way.
>> Cmu folks?
>
> saslauthd certainly isn't buggy in this way.  The Zanarotti, or
> screensaver, attack is avoided.  We make extensive use of saslauthd
> here and the KerberosV logs clearly show a ticket-granting ticket
> (krbtgt/BATH.AC.UK at BATH.AC.UK) being acquired and then used to
> acquire host/{hostname}@BATH.AC.UK credentials.  The saslauthd code
> caters for both the Heimdal and MIT Kerberos libraries.

That's not a keytab, that's a (service) principal, right!?
Two different but related things... ?

A '{host,ldap}/<FQDN>@<REALM>' (service) principal IS created and
explained in my book, so are we talking about the same thing, but
using different 'language'?

Am I missing something obvious here?

> But I suspect that it may well be using saslauthd.

If you're using {SASL}, then yes - you're using saslauthd. The old
(now unsupported/depricated) way of doing things was using {KERBEROS}.
And that used some internal magic that I'm not sure/don't remember
how exactly it worked.

>From what I know, the only way to tie OpenLDAP to kerberos is by
using '{SASL}<principal>@<REALM>' in the userPassword attribute...