From owner-freebsd-current@FreeBSD.ORG Mon Nov 3 20:24:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F7F93B5 for ; Mon, 3 Nov 2014 20:24:53 +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 E24D2627 for ; Mon, 3 Nov 2014 20:24:52 +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 <1XlOBG-001XBy-OM>; Mon, 03 Nov 2014 21:24:50 +0100 Received: from g226063058.adsl.alicedsl.de ([92.226.63.58] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XlOBG-002Mr5-KR>; Mon, 03 Nov 2014 21:24:50 +0100 Date: Mon, 3 Nov 2014 21:24:42 +0100 From: "O. Hartmann" To: Benjamin Kaduk Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so Message-ID: <20141103212442.028a2d44.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20141030092039.47802349@prometheus> <20141103162300.66b25285@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: multipart/signed; micalg=pgp-sha1; boundary="Sig_/qCq1t8rzleTOi0NhGzVqEkr"; protocol="application/pgp-signature" X-Originating-IP: 92.226.63.58 X-ZEDAT-Hint: A 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 20:24:53 -0000 --Sig_/qCq1t8rzleTOi0NhGzVqEkr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 3 Nov 2014 12:12:03 -0500 (EST) Benjamin Kaduk schrieb: > On Mon, 3 Nov 2014, O. Hartmann wrote: >=20 > > On Thu, 30 Oct 2014 16:47:02 -0400 (EDT) > > Benjamin Kaduk 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. >=20 > 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. >=20 > > I also sent notices to heimdal@h5l.org (hoping someone is listening at >=20 > I'm actually unsure whether that list is active. I think I'm only on > heimdal-discuss. >=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 > Between us, we still don't have enough data to say anything for sure, so > I'll drop it. >=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 > Okay. I can't argue with that. >=20 > > > > > > 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). >=20 > 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. >=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. > > > > 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 > 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/96e90256757c73ccf349d144e410ddf= 651a74cbc > 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?). >=20 > 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. The FreeBSD contribution in crypto/heimdal/lib/hdb doesn't show those addit= ional knobs, the same with the port security/heimdal, which is at revision 1.5.2 as far = as I can recall. But anyway, thank you very much for this hint, very much appreciated! >=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. > > > > > > 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. >=20 > No worries about the delay; good luck in your quest to get things working. >=20 > -Ben --Sig_/qCq1t8rzleTOi0NhGzVqEkr Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUV+SRAAoJEOgBcD7A/5N8ABMH/0fGspC3hnd5dOBJp571zo0L TQcmbjfwSOfPApW2fyy2SX2RmM7keOLRXQEfnJyWaVvyUlYbw/3SJyihu/7vohN8 G2+pHAq2CM0tWrYvybprfGfXCkJfEy8AQ/ZdsA6jC/RnqHWOeoxboAoz2AdKLept PjGaxOwmO4JxLtJgOzMxumGWD7YgEIuIxgYIPtV9idNS0ngSOFRyBTiEsyCyPFJI LenYt/TRcJcEGRq0c0g7Z7USFTUCE2/XO2IVCUSYnt54O5ILLmvTsc7JFov/w5ji +afrnEFH8JDLf0tPEfS3jBFRmDJvPWvLaODQuMXvqOr3UoMlXoYCmh5eQSfCNPM= =g7ma -----END PGP SIGNATURE----- --Sig_/qCq1t8rzleTOi0NhGzVqEkr--