Comments on LDAP support in heimdal

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Comments on LDAP support in heimdal

Lars Kellogg-Stedman
Howdy,

While setting up Heimdal kerberos with the LDAP backend, I ran into a few
stumbling blocks.  Everything is working now, but I'm curious what other
folks think about these issues:

(1) Problems with LDAP hdb as a dynamic module.

I originally built heimdal with --enable-hdb-openldap-module.  I was using
the following database configuration:

  [kdc]
    database = {
      realm = EXAMPLE.COM
      dbname = ldap:ou=dc=example,dc=com
      mkey_file = /var/heimdal/m-key
    }

Running 'kadmin -l', and then 'init EXAMPLE.COM' simply created a *file*
called "ldap:dc=example,dc=com" in the current working directory.
It didn't look as if any attempt was made to load the LDAP hdb backend.

Building without --enable-hdb-openldap-module fixed this problem.  I've got
two questions:

  (a) Is this (LDAP hdb as a loadable module) currently expected to work?

  (b) wouldn't it make more sense to treat a dbname of ldap:.. as an error
  if we can't load the appropriate hdb module?

(2) Problems with log_file.

When using the LDAP backend, the logic that creates the name of the log
file is arguably sub-optimal -- as in (1), it simply appends ".log" to
dbname and creates the file in the current working directory.  When using
non-file backends, might it make more sense to create the log file under
/var/heimdal?  For example, given dbname=ldap:dc=example,dc=com, maybe
default to /var/heimdal/_ldap_dc=example_dc=com -- that is, replace
"special" characters with "_", and maybe add a leading "_" to indicate a
generated filename.  Or at the very least, exit with an error if
log_file hasn't been given explicitly in the configuration.

-- Lars

--
Lars Kellogg-Stedman <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Howard Chu
While we're on this subject, it might be a better idea to make to treat
the dbname as a URI. Then we could make the path to the socket explicit,
e.g. dbname = ldapi://%2fvar%2fheimdal%2fldap/dc=example,dc=com

Lars Kellogg-Stedman wrote:

> Howdy,
>
> While setting up Heimdal kerberos with the LDAP backend, I ran into a few
> stumbling blocks.  Everything is working now, but I'm curious what other
> folks think about these issues:
>
> (1) Problems with LDAP hdb as a dynamic module.
>
> I originally built heimdal with --enable-hdb-openldap-module.  I was using
> the following database configuration:
>
>   [kdc]
>     database = {
>       realm = EXAMPLE.COM
>       dbname = ldap:ou=dc=example,dc=com
>       mkey_file = /var/heimdal/m-key
>     }


--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Ilia Chipitsine
ldaps also is good idea :-)

> While we're on this subject, it might be a better idea to make to treat the
> dbname as a URI. Then we could make the path to the socket explicit, e.g.
> dbname = ldapi://%2fvar%2fheimdal%2fldap/dc=example,dc=com
>
> Lars Kellogg-Stedman wrote:
>> Howdy,
>>
>> While setting up Heimdal kerberos with the LDAP backend, I ran into a few
>> stumbling blocks.  Everything is working now, but I'm curious what other
>> folks think about these issues:
>>
>> (1) Problems with LDAP hdb as a dynamic module.
>>
>> I originally built heimdal with --enable-hdb-openldap-module.  I was using
>> the following database configuration:
>>
>>   [kdc]
>>     database = {
>>       realm = EXAMPLE.COM
>>       dbname = ldap:ou=dc=example,dc=com
>>       mkey_file = /var/heimdal/m-key
>>     }
>
>
> --
>  -- Howard Chu
>  Chief Architect, Symas Corp.  http://www.symas.com
>  Director, Highland Sun        http://highlandsun.com/hyc
>  OpenLDAP Core Team            http://www.openldap.org/project/
>
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Andrew Bartlett
On Mon, 2005-10-31 at 09:36 +0500, Ilia Chipitsine wrote:
> ldaps also is good idea :-)

The main issue with moving off-host is that heimdal is single-threaded,
and would need to cache connections and handle disconnects much better.
Samba has a lot of experience in this area, and we found it is actually
a lot of work.

While it is rarely a problem in the single-host setup, if your remote
ldap server goes down, Heimdal currently returns 'user does not exist'
messages to the client, which then doesn't try any other possible KDCs.

However, if Heimdal is to update the LDAP backend with logon counts, bad
password lockout and the rest, it will have to handle referrals and
ldaps etc.  Use of transport-layer authentication (SASL EXTERNAL) might
avoid some of the issues with password storage.  (Samba uses
secrets.tdb).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
Authentication Developer, Samba Team           http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Howard Chu
Andrew Bartlett wrote:

> On Mon, 2005-10-31 at 09:36 +0500, Ilia Chipitsine wrote:
>> ldaps also is good idea :-)
>
> The main issue with moving off-host is that heimdal is single-threaded,
> and would need to cache connections and handle disconnects much better.
> Samba has a lot of experience in this area, and we found it is actually
> a lot of work.
>
> While it is rarely a problem in the single-host setup, if your remote
> ldap server goes down, Heimdal currently returns 'user does not exist'
> messages to the client, which then doesn't try any other possible KDCs.

In this respect I suggest leaving Heimdal using ldapi exclusively. If
you want to access a remote LDAP server, then run a slapd with back-ldap
to cross that gap. It already does connection caching and retries. Maybe
one day when we get the time to redesign the LDAP API we'll make it
simple enough for any application to get these features, but for now it
makes sense to conserve effort and just leave this issue to slapd where
it has already been solved.

Of course, it's probably still a good idea to use a temporary failure
code for those LDAP_UNAVAILABLE or LDAP_SERVER_DOWN cases.

> However, if Heimdal is to update the LDAP backend with logon counts, bad
> password lockout and the rest, it will have to handle referrals and
> ldaps etc.  Use of transport-layer authentication (SASL EXTERNAL) might
> avoid some of the issues with password storage.  (Samba uses
> secrets.tdb).

While I do prefer the use of SASL EXTERNAL, the fact is that the issue
of secret storage remains the same - a cert's private key must still be
available after all.

But I question the need to talk to a remote LDAP server in the first
place. How many KDCs do you usually deploy in a network? I think the
right answer in any given domain/realm is One, plus a backup. When you
have geographically diverse users, you usually split the realm and
create a local KDC for that purpose... As a general rule, you don't want
to have to look Very Far Away to get an answer to an authentication
question.

--
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc
   OpenLDAP Core Team            http://www.openldap.org/project/
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Ilia Chipitsine
In reply to this post by Andrew Bartlett
> On Mon, 2005-10-31 at 09:36 +0500, Ilia Chipitsine wrote:
>> ldaps also is good idea :-)
>
> The main issue with moving off-host is that heimdal is single-threaded,
> and would need to cache connections and handle disconnects much better.
> Samba has a lot of experience in this area, and we found it is actually
> a lot of work.

I meant ldap+ssl, not just "multiple ldap servers"

>
> While it is rarely a problem in the single-host setup, if your remote
> ldap server goes down, Heimdal currently returns 'user does not exist'
> messages to the client, which then doesn't try any other possible KDCs.
>
> However, if Heimdal is to update the LDAP backend with logon counts, bad
> password lockout and the rest, it will have to handle referrals and
> ldaps etc.  Use of transport-layer authentication (SASL EXTERNAL) might
> avoid some of the issues with password storage.  (Samba uses
> secrets.tdb).
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Samba Developer, SuSE Labs, Novell Inc.        http://suse.de
> Authentication Developer, Samba Team           http://samba.org
> Student Network Administrator, Hawker College  http://hawkerc.net
>
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Lars Kellogg-Stedman
In reply to this post by Howard Chu
> While we're on this subject, it might be a better idea to make to treat
> the dbname as a URI...

That would be a great idea, and I had considered adding that to my
original email...but I refrained from mentioning it because I didn't
want to distract anyone (alas, I've failed) from the questions in my
email:

(1) Is LDAP hdb as a dynamic module supposed to work?

(2) Shouldn't a dbname with an hdb-schema prefix like ldap: generate
an error if an appropriate hdb module isn't available?

(3) Should the logic used to create log files from dbnames be
different?  Or should non-file backends *require* an explicit log_file
path?

Cheers,

  -- Lars

--
Lars Kellogg-Stedman <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Love Hörnquist Åstrand
In reply to this post by Lars Kellogg-Stedman

Lars Kellogg-Stedman <[hidden email]> writes:

> Howdy,
>
> While setting up Heimdal kerberos with the LDAP backend, I ran into a few
> stumbling blocks.  Everything is working now, but I'm curious what other
> folks think about these issues:
>
> (1) Problems with LDAP hdb as a dynamic module.
>
> I originally built heimdal with --enable-hdb-openldap-module.  I was using
> the following database configuration:
>
>   [kdc]
>     database = {
>       realm = EXAMPLE.COM
>       dbname = ldap:ou=dc=example,dc=com
>       mkey_file = /var/heimdal/m-key
>     }
>
> Running 'kadmin -l', and then 'init EXAMPLE.COM' simply created a *file*
> called "ldap:dc=example,dc=com" in the current working directory.
> It didn't look as if any attempt was made to load the LDAP hdb backend.
>
> Building without --enable-hdb-openldap-module fixed this problem.  I've got
> two questions:
>
>   (a) Is this (LDAP hdb as a loadable module) currently expected to work?
Yes, but as the code works now, it will only work where here are no db
support compiled in.

>   (b) wouldn't it make more sense to treat a dbname of ldap:.. as an error
>   if we can't load the appropriate hdb module?

Yes, it would, but there is backward compatiblity code in there to make it
work with older configurations. How about this patch ?

--- lib/hdb/hdb.c 19 Oct 2005 15:51:40 +0200 1.56
+++ lib/hdb/hdb.c 01 Nov 2005 10:25:05 +0100
@@ -55,11 +55,9 @@
     {"ldap:", hdb_ldap_create},
 #endif
 #if HAVE_DB1 || HAVE_DB3
-    {"", hdb_db_create},
+    {"/", hdb_db_create},
 #elif defined(HAVE_NDBM)
-    {"", hdb_ndbm_create},
-#elif defined(OPENLDAP) && !defined(OPENLDAP_MODULE)
-    {"", hdb_ldap_create},
+    {"/", hdb_ndbm_create},
 #endif
     {NULL, NULL}
 };


> (2) Problems with log_file.
>
> When using the LDAP backend, the logic that creates the name of the log
> file is arguably sub-optimal -- as in (1), it simply appends ".log" to
> dbname and creates the file in the current working directory.  When using
> non-file backends, might it make more sense to create the log file under
> /var/heimdal?  For example, given dbname=ldap:dc=example,dc=com, maybe
> default to /var/heimdal/_ldap_dc=example_dc=com -- that is, replace
> "special" characters with "_", and maybe add a leading "_" to indicate a
> generated filename.  Or at the very least, exit with an error if
> log_file hasn't been given explicitly in the configuration.
Its true that the HDB_DB_DIR should probably be prefixed, and / replaced
with something else.

How about this for now ?

--- lib/kadm5/context_s.c 17 Jun 2005 07:13:26 +0200 1.18
+++ lib/kadm5/context_s.c 01 Nov 2005 10:30:35 +0100
@@ -76,9 +76,10 @@
     else {
  p = strrchr(dbname, '.');
  if(p == NULL)
-    asprintf(variable, "%s.%s", dbname, ext);
+    asprintf(variable, "%s/%s.%s", HDB_DB_DIR, dbname, ext);
  else
-    asprintf(variable, "%.*s.%s", (int)(p - dbname), dbname, ext);
+    asprintf(variable, "%s/%.*s.%s",
+     HDB_DB_DIR, (int)(p - dbname), dbname, ext);
     }
 }


Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Lars Kellogg-Stedman
> Yes, it would, but there is backward compatiblity code in there to make it
> work with older configurations. How about this patch ?

Looks like it would solve the immediate problem.  I'll give it a shot
tomorrow sometime.

> How about this for now ?
>
>         p = strrchr(dbname, '.');
>         if(p == NULL)
>           asprintf(variable, "%s/%s.%s", HDB_DB_DIR, dbname, ext);
>         else
>           asprintf(variable, "%s/%.*s.%s",
>                    HDB_DB_DIR, (int)(p - dbname), dbname, ext);

Definately better, but there's the (rare?) potentional for name conflicts
(e.g., dbname=ldap:o=company.com and dbname=ldap:o=company.org would map to
the same filenames, since this code would treat the final domain component
as an extension and strip it off).

One could simply stop stripping off the final extension (so if
dbname=/var/heimdal/mydomain.db, then log_file would default to
/var/heimdal/mydomain.db.log).  The default filename would always be:

          asprintf(variable, "%s/%s.%s", HDB_DB_DIR, dbname, ext);

Would this break anything?  It seems simpler.

-- Lars

Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Lars Kellogg-Stedman
In reply to this post by Love Hörnquist Åstrand
Love,

I've produced a couple of patches against Heimdal along the lines of
what we've just been discussing.  They're attached to this email.

(1) Changes to HDB driver loading semantics

The first patch changes hdb.c such that the application will exit with
an error if the specified HDB driver cannot be found.  The logic looks
like this:

  IF a driver has not been specified explicitly using driver: THEN
    driver = HDB_DEFAULT_DRIVER
  END IF

  IF we find a matching driver in our builtin list THEN
    use that driver
  ELSE IF we are able to load an appropriate dynamic module THEN
    use that driver
  ELSE
    exit with an error
  END IF

I think the semantics are a little more sane (we no longer need to
"guess" which hdb to use), and it still works just fine with
unqualified (no "driver:") dbnames. I'm not 100% positive about the
nomenclature you folks are using, so you may need to make some name
changes.

Let me know if this would break backwards compatability somewhere.

(2) Changes to default db-related paths

Patched lib/kadm5/context_s.c as discussed in my earlier email.

-- Lars

heimdal-lks-hdb.patch (6K) Download Attachment
heimdal-lks-default-filename.patch (938 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Love Hörnquist Åstrand
In reply to this post by Howard Chu

Howard Chu <[hidden email]> writes:

> While we're on this subject, it might be a better idea to make to
> treat the dbname as a URI. Then we could make the path to the socket
> explicit, e.g. dbname =
> ldapi://%2fvar%2fheimdal%2fldap/dc=example,dc=com

Indeed, next time I get a ldap-setup, I'll try my patch that implements
this behavior.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Love Hörnquist Åstrand
In reply to this post by Lars Kellogg-Stedman

Lars Kellogg-Stedman <[hidden email]> writes:

> Love,
>
> I've produced a couple of patches against Heimdal along the lines of
> what we've just been discussing.  They're attached to this email.
[...]
> Let me know if this would break backwards compatability somewhere.

I'm think I'm fine with the changing of the hdb driver semantics, not too
happy about large #ifdef thingy, but other then that, itseems clean enouth.

Changing the name of the logfile will break existing installations
today. Changing the directory is fine with me, it will "only" break ldap
installations but I can live with that.

I'll look at the patch again when its not late in the evening.

Love


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Lars Kellogg-Stedman
> I'm think I'm fine with the changing of the hdb driver semantics, not too
> happy about large #ifdef thingy, but other then that, itseems clean enouth.

It's really just about the same as what you've currently got inside
the builtin list in hdb.c.  The external ifdef is really there just so
that one could add a '--with-default-hdb-driver=xxx' to configure if
you wanted to allow it to be set explicitly.

-- Lars

Reply | Threaded
Open this post in threaded view
|

Re: Comments on LDAP support in heimdal

Henry B. Hotz
In reply to this post by Howard Chu
Realm names tend to be driven by org charts.

Replication tends to be driven by geography (network geography,  
including firewall locations).

If and only if they are very similar, then you can maybe get away with  
just two servers.  Geographic (physical, network and power) diversity  
is good for reliability.

On Oct 30, 2005, at 9:51 PM, Howard Chu wrote:

> But I question the need to talk to a remote LDAP server in the first  
> place. How many KDCs do you usually deploy in a network? I think the  
> right answer in any given domain/realm is One, plus a backup. When you  
> have geographically diverse users, you usually split the realm and  
> create a local KDC for that purpose... As a general rule, you don't  
> want to have to look Very Far Away to get an answer to an  
> authentication question.

I would think you would want one ldap server/kerberos server.  
Otherwise you don't have the reliability/diversity that the number of  
kdc's would imply.
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[hidden email], or [hidden email]