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

On Thu, 30 Oct 2014 16:47:02 -0400 (EDT)
Benjamin Kaduk <kaduk_at_MIT.EDU> wrote:

> [stripping -questions; please don't cross-post]
> 
> Disclaimer: I am part of the group that develops MIT Kerberos
> 
> On Thu, 30 Oct 2014, O. Hartmann wrote:
> 
> > Searching for suitable manuals, I found some HowTos describing how
> > to setup MIT Kerberos V with an OpenLDAP backend and I started
> > following the instructions there. Despite the fact that
> > http://www.h5l.org/manual
> 
> I am not sure why.  I guess you already discovered this, but the MIT
> KDC and the Heimdal KDC are very different beasts to administer.  The
> instructions for one have no bearing on the other.

Indeed, I did, but I was under the impression both suites share
mutuality. Its long time ago since I had contact to KRB5.

> 
> > is dead(!) and no usefull documentation or any kind of a hint where
> > to
> 
> That was reported to their mailing list independently just today
> (http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.general/7836)

I also sent notices to heimdal_at_h5l.org (hoping someone is listening at
the backend there). A of today, the site is still unresponsive
regarding documentation. The links are dead, 404 ERROR.

> 
> > find useful documentation for Heimdal can be found, many of the MIT
> > Kerberos V setup instructions seem to be a dead end when using
> > Heimdal on FreeBSD. Most of the links on that heimdal site ends up
> > in ERROR 404!
> >
> > Well, I think my objective isn't that exotic in an more advanced
> > server environment and I think since FreeBSD is supposed to be used
> > in advanced server environments this task should be well known - but
> > little information/documentation is available.
> 
> 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).

> 
> > Nevertheless, I use the base system's heimdal implementation and I
> > run into a very frustrating error when trying to run "kamdin -l":
> >
> > kadmin: error trying to load dynamic module /usr/lib/hdb_ldap.so:
> > Cannot open "/usr/lib/hdb_ldap.so"
> >
> > The setup for the stanza [kdc] is
> >
> > [...]
> > [kdc]
> >         database =    {
> >                 dbname=ldap:ou=kerberos,dc=server,dc=gdr
> >                 #hdb-ldap-structural-object     = inetOrgPerson
> > 		mkey_file = /var/heimdal/m-key
> > 		acl_file = /var/heimdal/kadmind.acl
> > }
> >
> > instructions taken from  http://www.padl.com/Research/Heimdal.html.
> >
> > Well, it seems that FreeBSD ships with a crippled heimdal
> > implementation. Where is /usr/lib/hdb_ldap.so?
> 
> You keep using this word "crippled", and I fail to understand why.
> It is functioning as intended.  The FreeBSD base system ships with a
> limited set of tools, which allow many common server tasks to be
> performed, but certainly not all, and are not intended to fulfil all
> advanced server setups.  The bundled Heimdal is there to provide the
> libraries and client utilities, which can be indispensable in many
> environments, and the KDC implementation is included because it can
> be useful in simple, small setups.  If you need a more complicated
> Kerberos setup, you should be installing a KDC from ports, or
> arguably even building from source!  The KDC in base functions
> suitably for the role it is intended to play; that is hardly
> "crippled".

Yes, I was in that case a bit fast with my statement (which I still
hold with respect to a "roundish and complete system") but when I
thought about how FreeBSD would implement kerberized services, I was
remembered that at least the basic libraries need to be present.

I regret that important pieces like Kerberos/Heimdal (specially the
last) and OpenLDAP are not part of the base system but in this case, we
tend to have a philosophical dicussion and end up in the way the Linux
distributions are handled. I have an insight in the unfortune logic of
mine, my apologizes.

> 
> You probably noted that the base system now has dma, and sendmail is
> on its way out.  Sendmail is a pretty big hammer, bigger than what is
> needed for use by the base system, and dma is more appropriate.  The
> tools in the base system have a purpose, and they are not always
> suitable for everything in their appropriate area.
> 
> > I'm toying around this issue for several days now and it gets more
> > and more frustrating, also with the perspective of having no
> > running samba 4.1 server for the windows domain.
> >
> > Can someone give me a hint where to find suitable FreeBSD docs for a
> > task like this? I guess since FreeBSD is considered a server OS more
> > than a desktop/toy OS, there must be a solution for this. FreeBSD
> > ships with heimdal in the base, but it seems this heimdal is broken.
> 
> Again, don't use the heimdal from base if you need fancy features.
> 
> (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.
  
> 
> 
> 
> 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).


> 
> > I overcame this problem by installing the port security/heimdal, but
> > now I run into the next problem which is highly intransparent:
> >
> > kadmin> init MY.REALM
> > kadmin: hdb_open: ldap_sasl_bind_s: Confidentiality required
> >
> > My LDAP server expects TLS authentication. I would expect a LDAP
> > aware client to llok for the proper informations
> > at /usr/local/openldap/ldap.conf. Obviously, Heimdal doesn't. Is
> > there
> 
> I'm not sure that I would.  The LDAP database holding KDB information
> may not be the default LDAP database for the rest of the system
> (e.g., for nsswitch), and contains sensitive key data; having to
> specify additional configuration for it seems reasonable to me.
> 
> 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).

> 
> > 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.

Oliver