Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so

On Mon, 3 Nov 2014, O. Hartmann wrote:

> On Thu, 30 Oct 2014 16:47:02 -0400 (EDT)
> Benjamin Kaduk <kaduk_at_MIT.EDU> wrote:
>
> > On Thu, 30 Oct 2014, O. Hartmann wrote:
> >
> Indeed, I did, but I was under the impression both suites share
> mutuality. Its long time ago since I had contact to KRB5.

The kerberos v5 protocol is an IETF standard, and a heimdal krb5 client
will interoperate with an MIT (or even Microsoft!) server, and vice versa.
The same cannot be said of the kadmin protocols or the database
administration tools, as those are not part of the core kerberos v5
protocol.

> I also sent notices to heimdal_at_h5l.org (hoping someone is listening at

I'm actually unsure whether that list is active.  I think I'm only on
heimdal-discuss.

> > In my experience, most people getting into administering Kerberos
> > KDCs do so by learning from someone else already doing so (usually in
> > the same organization), so there are not always written
> > documentation.  In my (biased) opinion, the MIT documentation is
> > pretty good; the upstream Heimdal documentation less so.
>
> Well, to make it short and not to start a flame war, I disagree. In
> my/our case, I'm the root or will become such a root to be asked. In
> such a case good software is also measured by its documentation for
> exactly that purpose (apart from reading/understanding the source code,
> if available).

Between us, we still don't have enough data to say anything for sure, so
I'll drop it.

> > (Are you even tied to Heimdal?  If not, you already found the
> > documentation for using LDAP as a backend for an MIT KDC...)
>
> Well, the use of Heimdal has political issues - for the now and
> the future. Following your recommenadations and lookig for the
> documentation of MIT Kerberos, I realized that indeed the docs are
> much more complete - even from the simplest point of view, namelythe
> accesibility of the server(s) providing the documentation. But as I
> said, the decission is a more political one.

Okay.  I can't argue with that.

> >
> > From your later message:
> >
> > > The lack of documentation is simply a mess. I excluded by intention
> > > the port security/heimdal to proof whether FreeBSD is capable of
> > > handling a common and very usual  server task like the mentioned
> > > scenario.
> >
> > I cannot agree that your mentioned scenario is common and very
> > usual.  In my experience the majority of Unix standalone KDC
> > deployments use the default (local) database backend, not an LDAP
> > backend.  (Fancy things like Samba, IPA, and AD are different, but
> > they are also not in the domain of things in the base system!)
>
> Well, FreBSD is supposed to handle larger environments and not
> home-office or toy systems - that is what is always inside the messages
> I get and that what I read "inbetween" the written rows. Logically, I
> conclude that many others utilizing FBSD as a server backend for their
> purposes even in larger or even big environments use RADIUS or LDAP as
> backend in combination with Kerberos/Heimdal.
>
> From what experiences I exchanged with other administrators at the
> departments, the use of OpenLDAP as a backend for kerberos/Heimdal
> isn't that unusual due to the sophisticated replication mechanism,
> which convinced my. I also have some specific schematics were OpenLDAP
> as the backend would come in handy (presuming a etup which respects
> several security issues).

Sure, an LDAP backend has nice features (it might be slower, though).  I
don't think an attempt to bring an OpenLDAP server into the FreeBSD base
system would succeed, though, so heimdal from ports is the only option in
this case.

> > I don't know if you followed the MIT documentation this far, but an
> > MIT KDC needing to authenticate to bind to its LDAP server needs to
> > have configuration for this in kdc.conf.
>
> Well, the last point is making me floating dead in the water - I can
> find some informations for MIT Kerberos V, but I can not find those for
> heimdal and with the Heimdal documentation server down and not mirrored
> the situation is unresovable right now.
>
> I can not even evaluate whether the concept I'm thinking of is possible
> or now (lack of docs!). The OpenLDAP daemon requires TLS-secured access
> with a certain "security strength factor" for all inbound access. Such
> a security concept is defined in the toplevel cn=config structure.  My
> thinking was to have an exception defined by olcAccess rulesets
> nullifying the SSF for the localhost or the unix-domainsocket, but
> olcAccess isn't allowed at that level - so the KDC needs to contact
> its LDAP backend via TLS secured connectsion - and I do not know
> whether this is possible in Heimdal - and how to configure this request
> properly. If it is impossible, I probably have to go with a
> client-based access via SSL certificate which drives the complexity of
> the setup for the whole domain into problematic regions. Then your
> suggestion of falling back to a dedicated LDAP for Kerberos might have
> a reason (at least to me, too).

Well, a quick glance doesn't rule it out.
https://github.com/heimdal/heimdal/blob/master/doc/setup.texi#L1123 allows
ldaps:// urls
https://github.com/heimdal/heimdal/commit/96e90256757c73ccf349d144e410ddf651a74cbc
has some config knobs for a separate file for bind dn and password (as
well as a knob for putting the bind password directly in krb5.conf?).

Note that I did not check whether all of these bits are in a released
version of Heimdal; I gather a 1.6 release has been in preparation for
quite some time.

> > > anything I've missed? Since I can not find any suitable
> > > documentation (www.h5l.org/manual is dead!), I'm floating dead in
> > > the water.
> >
> > I don't know of any documentation for doing this with Heimdal,
> > sorry.  If you were using MIT Kerberos I could be more helpful.
> >
> > -Ben
>
> Thanks for your response, anyway and apologizes for my late response.

No worries about the delay; good luck in your quest to get things working.

-Ben