Re: OpenLDAP (v1.2.11), Kerberos (MIT Krb5, v1.2.1) and client software

["Booker C. Bense" <bbense@networking.stanford.edu>]

On 25 Jan 2001, Turbo Fredriksson wrote:

> I've  been having OpenLDAP/PAM  authentication for  about a  year now,
> with  very little trouble  (every now  and then  the server  dies, and
> replication isn't so auto magic I'd hoped for).
>
> I am now on the verge of the next big step, KERBEROS!
>
>
> What   i   would   like,  in   the   end,   is   to  have   all   this
> (OpenLDAP/Kerberos/QmailLDAP etc) as one.  That is, not two passwords,
> but one...
>
> Kerberos  between  the  OpenLDAP  master/replicas, kerberos  from  the
> client  machines (using pam_ldap)  to the  OpenLDAP database,  and the
> possibility to  have a 'single-sign-on' kind'a  system (using Kerberos
> tickets).
>
>
> That  is, _ALL_  communication  to the  OpenLDAP  database should  use
> Kerberos.    That    include    QmailLDAP/Controls   doing    kerberos
> authentication/encrypted communication to the OpenLDAP server.
>

- I have no idea how the Qmail stuff works, but I did do this
with sendmail and the older version of kerberos 4 authentication.
If you don't design it in from the beginning, you'll have
problems. There's some stuff that you need to put around the ldap
api to get a kerberos authentication that is workable. At a
minimum you need to tell it where the tgt cache is, you can do
this via env variables. That might alot more workable in the Qmail
way of doing things than in the sendmail way.

> Preferably the 'kerberosSecurityObject' objectclass (with the attribute
> 'krbName') should somehow be used in all this to...
>

- My understanding of how this works is that the ldap server
  takes the principal in the kerberos service ticket and compares it
  to the principals listed in krbName. This is a low budget way
  to create authority groups, multiple krbNames mapped to a
  single ldap DN. However, this knowledge is based on the older
  UMich kerberos code. It may not work the same with the newer
  SASL based code.

>
> * First question: IF I recompile OpenLDAP '--with-kerberos', how is the
>   kerberos authentication/encryption done? Is it up to the client software
>   to do the kerberos init?

- Yes, you have to have a valid kerberos tgt before any of the ldap
  GSSAPI sasl calls will work. For deamons this means that you need
  to have something that will manage the tgt. My approach has been to
  put the minimum possible(i.e. where is my tgt?) in the deamon and
  use an external deamon to manage keeping the tgt up to date.

>
> * Second question: How do I combine OpenLDAP with (MIT) Kerberos?
>

- What you really should be asking is

	How do I combine OpenLdap with Cyrus SASL?

  Once you do that the kerberos bit comes automagically if you've
  configured cyrus sasl correctly.

> * Third question: How do I make my client machines (from/via PAM I suppose)
>   to use kerberos to the LDAP database?

- If you have kerberos and PAM, you don't need to use ldap to
login. Kerberos alone will handle the authentication[1] part. You
may want to use ldap for authorization[2], but it's not needed
for authentication.

>
> * Fourth question: Since I'm doing round-robin to the LDAP database
>   (currently only one master, and one replica but more replicas are planned),
>   would that somehow disturb the 'Kerberos ticketing stuff' (sorry for the
>   use of a bad word, but I'm just starting to learn about 'this Kerberos stuff'
>   :).
>

- If I understand you correctly, no. Kerberos ticketing stuff
  should not cause any problems in replication. If you want to
  use kerberos for securing the replication, there's a fair bit
  of stuff you need to twiddle to keep tgt's and such active.
  I'm not sure how complete OpenLdaps's support for doing this
  is.

>
> Anything else that I might have overlooked, or should study closer? Is there
> some kind of (mini/micro) HOWTO/FAQ that I can take a look at to understand
> the issue(s) better?
>

- No, documentation for all this stuff is very minimal. I would
suggest that you start at the Cyrus SASL documentation and the
docs that come with MIT kerberos. The Ldap V3 spec is remarkly
vague about how SASL is supposed to work in ldap. I think there
have been a couple followup RFC's that attempt to put some
specifics in. You should check those as well.

- Booker C. Bense

[1]- Authentication is "Who are you?"

[2]- Authorization is "What can you do?"