From owner-freebsd-current@FreeBSD.ORG Mon Nov 3 17:17:17 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 15A236EF for ; Mon, 3 Nov 2014 17:17:17 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 96F41D6C for ; Mon, 3 Nov 2014 17:17:16 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-85-5457b766e164 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id DC.A9.09603.667B7545; Mon, 3 Nov 2014 12:12:06 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id sA3HC5oH023177; Mon, 3 Nov 2014 12:12:06 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sA3HC3es015444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Nov 2014 12:12:05 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sA3HC3pV025827; Mon, 3 Nov 2014 12:12:03 -0500 (EST) Date: Mon, 3 Nov 2014 12:12:03 -0500 (EST) From: Benjamin Kaduk To: "O. Hartmann" Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so In-Reply-To: <20141103162300.66b25285@prometheus> Message-ID: References: <20141030092039.47802349@prometheus> <20141103162300.66b25285@prometheus> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrZu2PTzEYMYhDYs5bz4wWfyd9YfJ gcljxqf5LB6nth9kDGCK4rJJSc3JLEst0rdL4Mo40XKYvWChQcXGdW+YGxj3q3UxcnJICJhI rN36iBHCFpO4cG89G4gtJDCbSeJ7f0gXIxeQvYFRom15GxuEc5BJYt3S3YwQVfUS24/fZgex WQS0JJr37QGLswmoSMx8sxFskoiAvsS5ptNgNrOAocTLdffA6oUF/CRW7TsPZnMCxZ+tPMgM YvMKOEp8urcUalk3o8T8jb0sIAlRAR2J1funsEAUCUqcnPmEBWKolsTy6dtYJjAKzkKSmoUk tYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGuhV5uZoleakrpJkZQqLK7qO5gnHBI6RCjAAej Eg+vxNawECHWxLLiytxDjJIcTEqivFUbw0OE+JLyUyozEosz4otKc1KLDzFKcDArifDOXw2U 401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4O3dBtQoWJSanlqRlplT gpBm4uAEGc4DNPwYSA1vcUFibnFmOkT+FKOilDivHUhCACSRUZoH1wtLJa8YxYFeEeadBlLF A0xDcN2vgAYzAQ127AoBGVySiJCSamBU1RLlk69/qivxl0HBu4/r3OQ8zSNqwvzcocVCofM0 TH9Znb2qIlnqtqttd7hFT8IntzXtj8/+FWk85rvJ59qjPMWY2T/r17tYLJgiankqj32S1VnW d2eZuu6nl8+a58R6uupQNLdD1WbFaUWNE/ZOf+M2o9uqpO2Twr5zZ97tT1laInHl5TolluKM REMt5qLiRADiXjstAAMAAA== 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 17:17:17 -0000 On Mon, 3 Nov 2014, O. Hartmann wrote: > 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. 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@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