From owner-freebsd-current@FreeBSD.ORG Mon Nov 3 15:23:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05FF4570 for ; Mon, 3 Nov 2014 15:23:51 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E05AE50 for ; Mon, 3 Nov 2014 15:23:50 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XlJTq-0006hz-Hv>; Mon, 03 Nov 2014 16:23:42 +0100 Received: from p578a69f9.dip0.t-ipconnect.de ([87.138.105.249] helo=prometheus) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XlJTq-001mtN-DU>; Mon, 03 Nov 2014 16:23:42 +0100 Date: Mon, 3 Nov 2014 16:23:00 +0100 From: "O. Hartmann" To: Benjamin Kaduk Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so Message-ID: <20141103162300.66b25285@prometheus> In-Reply-To: References: <20141030092039.47802349@prometheus> Organization: FU Berlin X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Originating-IP: 87.138.105.249 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 15:23:51 -0000 On Thu, 30 Oct 2014 16:47:02 -0400 (EDT) Benjamin Kaduk wrote: > [stripping -questions; please don't cross-post] >=20 > Disclaimer: I am part of the group that develops MIT Kerberos >=20 > On Thu, 30 Oct 2014, O. Hartmann wrote: >=20 > > 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 >=20 > 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. >=20 > > is dead(!) and no usefull documentation or any kind of a hint where > > to >=20 > That was reported to their mailing list independently just today > (http://permalink.gmane.org/gmane.comp.encryption.kerberos.heimdal.genera= l/7836) I also sent notices to heimdal@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. >=20 > > 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. >=20 > 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). >=20 > > 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 =3D { > > dbname=3Dldap:ou=3Dkerberos,dc=3Dserver,dc=3Dgdr > > #hdb-ldap-structural-object =3D inetOrgPerson > > mkey_file =3D /var/heimdal/m-key > > acl_file =3D /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? >=20 > 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. >=20 > 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. >=20 > > 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. >=20 > Again, don't use the heimdal from base if you need fancy features. >=20 > (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. =20 >=20 >=20 >=20 > From your later message: >=20 > > 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. >=20 > 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. =46rom 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). >=20 > > 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 >=20 > 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. >=20 > 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.=20 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=3Dconfig 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). >=20 > > 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. >=20 > I don't know of any documentation for doing this with Heimdal, > sorry. If you were using MIT Kerberos I could be more helpful. >=20 > -Ben Thanks for your response, anyway and apologizes for my late response. Oliver