From owner-freebsd-current@FreeBSD.ORG Thu Oct 30 20:52:15 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 7E199232 for ; Thu, 30 Oct 2014 20:52:15 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 0765212B for ; Thu, 30 Oct 2014 20:52:14 +0000 (UTC) X-AuditID: 1209190c-f795e6d000006c66-25-5452a3cae855 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 35.29.27750.AC3A2545; Thu, 30 Oct 2014 16:47:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9UKl5V9030235; Thu, 30 Oct 2014 16:47:05 -0400 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 s9UKl3bj014359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Oct 2014 16:47:04 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s9UKl2iP021626; Thu, 30 Oct 2014 16:47:02 -0400 (EDT) Date: Thu, 30 Oct 2014 16:47:02 -0400 (EDT) From: Benjamin Kaduk To: "O. Hartmann" Subject: Re: Heimdal with OpenLDAP backend: Cannot open /usr/lib/hdb_ldap.so In-Reply-To: <20141030092039.47802349@prometheus> Message-ID: References: <20141030092039.47802349@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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrHtqcVCIwcQWXos5bz4wWfyd9YfJ gcljxqf5LB6nth9kDGCK4rJJSc3JLEst0rdL4Mr4/OAVY8EF3YrnV6azNzAeUeli5OSQEDCR +Pb9EyOELSZx4d56ti5GLg4hgdlMEgtuT2CFcDYySrROOs0O4Rxiklg1bSJUWQOjxIynO4DK ODhYBLQlbj0OBxnFJqAiMfPNRjYQW0RAX+Jc02kwm1nAUOLlunvsILawgJ/Eqn3nwWxOoPjx DztZQWxeAUeJufM/M4HYQgIGEhc/9DCD2KICOhKr909hgagRlDg58wkLxEwtieXTt7FMYBSc hSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1DvdzMEr3UlNJNjOBQleTZwfjmoNIh RgEORiUeXo0TgSFCrIllxZW5hxglOZiURHmjZgeFCPEl5adUZiQWZ8QXleakFh9ilOBgVhLh 9eoGyvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAoSfCuXAjUKFiUmp5a kZaZU4KQZuLgBBnOAzR8E0gNb3FBYm5xZjpE/hSjopQ4rxVIQgAkkVGaB9cLSyWvGMWBXhHm 3QNSxQNMQ3Ddr4AGMwEN/jw1AGRwSSJCSqqBccpjBY0j9fai1/dO9bnw5UqhpW9zux/THK93 Ucpub5QZumy9Hh59YLX9xNmpR/7veqXgrKkQ9jSl5tHba+vZfh/d/OV+W9eh+6wGwTO4LBsC G3POP/+neiNyx1KV79HiR52sk9VVORnq7l7brCBuU3S8cv+Whr1Ht+98dH7/ui6hR4H/L6xa 5aXEUpyRaKjFXFScCAD9u5LUAAMAAA== 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: Thu, 30 Oct 2014 20:52:15 -0000 [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. > 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) > 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. > 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". 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...) >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!) > 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. > 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