[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAPv3: The OpenLDAP/Kerberos/SASL soup (was Kerberos and DIGEST-MD5)

Jose Gonzalez Gomez wrote:
Ok, I think I have done my homework reading a lot of past posts in the mailing list, and this is what I have found... I hope this helps to anyone interested in this. In addition I would like to hear your comments about some of the points:

    * There is something called LDAPv3 that may be achieved to some
      extent combining LDAP, Kerberos and SASL.

Kerberos has nothing to do with LDAPv3. SASL/Digest-MD5 is a mandatory authentication mechanism for LDAPv3.

    * Regarding Kerberos, Heimdal is preferred against MIT due basically
      to the ability of Heimdal to store its KDC database in LDAP and to
      some annoying threading issues with MIT. Heimdal uses
      krb5-kdc.schema for the schema definition, krb5KDCEntry as the
      objectclass for KDC entries, and stores the password in the
      encrypted attribute krb5Key (is this correct?). I have a doubt
      here... krb5KDCEntry is an auxiliary class, so either Heimdal uses
      an structural class (which one?) in addition to krb5KDCEntry when
      creating an entry or OpenLDAP will complain about this...

This is a question for the Heimdal mailing list. In the latest releases, the objectclass Heimdal uses is configurable. Ordinarily it is a non-issue; when using the KDC with LDAP you should create the complete user entry in LDAP, including the Krb5 objectclass and required attributes.

    * Taking into accout the last point I assume a sensible
      implementation of a Heimdal/OpenLDAP directory would combine
      common attributes (inetOrgPerson) and security attributes
      (krb5KDCEntry) in the same directory object under
      ou=people,dc=whatever,dc=com... am I right?


Yes.

    * Let's talk now about non kerberized applications (by the way, is
      this a verb? :o) ). If you want to provide simple bind
      functionality you have to store some kind of password in the
      userPassword field. Here you have several options:
          o Use {KERBEROS}user@REALM. This is deprecated, as it seems
            the code is unmantained and being phased out. Any way you
            still may access this using an environment variable while
            compiling.

In OpenLDAP 2.2 this code has been moved to a loadable module in the contrib directory. There is no mechanism for building it in the main configure script or Makefiles any more.

          o Use {SASL}user@REALM. You must compile OpenLDAP with
            --enable-spasswd for this to work. This makes use of the
            SASL authentication mechanisms to check the provided
            password against the backend of choice. It is not
            recommended to use Kerberos for this, as this makes the
            whole operation quite inefficient, and would slow down the
            machine in heavy load scenarios (basically you have a lot of
            unused tickets floating around).


The same is true for the {KERBEROS} method, lots of unused tickets.

          o Use {KRB5KEY} (????). I have found some mails that mention
            something about setting an encrypted password using
            {KRB5KEY}, but I haven't been able to find more information
            about this... must Heimdal be configured to set userPassword
            to this? Is this information taken/copied from krb5Key?

The idea was for Heimdal to use this instead of the krb5Key attribute. The idea never gained any support. We (Symas) provided it in our CDS suite for a while, but not any more.

          o Of course, make use of TLS/SSL if you are planning to
            provide simple bind authentication. You don't want to blow
            out your whole Kerberos security having those passwords
            floating around your network, do you?

This is a strong argument against supporting Simple Binds at all, when using Kerberos.

    * About DIGEST-MD5... it seems this is a mandatory SASL mechanism to
      offer if you want to have a shining LDAPv3 compliant service...
      *but* (I hate this word) you need to have clear text password (a
      shared secret) stored somewhere. This may be OpenLDAP, or the
      sasldb2 database (in case you are using Cyrus SASL... I don't know
      of any other open source implementation of SASL anyway). For
      comments on having this stored in LDAP, see previous point... a
      bit tricky. In case you store them in the sasldb2 database, you
      will have to mantain duplicated entries in Kerberos/LDAP and
      sasldb2.

For OpenLDAP it's generally preferred to store secrets in LDAP, not in sasldb2.

Anyway, OpenLDAP doesn't completely implement the whole
      LDAPv3 standard, so maybe we won't miss DIGEST-MD5 that much until
      there is an easier way of doing it...

Since LDAPv3 is an extensible protocol, I'm not sure what this statement means.

I hope this helps to anyone trying to setup a Kerberos/OpenLDAP/SASL server.

    TIA, best regards
    Jose



--
  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support