No response on -mentors in > 24 hours, so I'm looping in -devel.<br><br>Cheers,<br><br>C.J.<br><br><br><div class="gmail_quote">On Nov 29, 2007 8:33 AM, C.J. Adams-Collier <<a href="mailto:cjcollier@gmail.com">cjcollier@gmail.com
</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hey folks,<br><br>I'm looking to make some changes to the heimdal debian packages.
<br>Currently, the heimdal-kdc package contains the following daemons:<br><br>* ./usr/lib/heimdal-servers/kdc<br>* ./usr/lib/heimdal-servers/kadmind<br>* ./usr/lib/heimdal-servers/kpasswd<br><br>If I understand correctly, kdc is responsible for checking credentials
<br>and issuing tickets, kpasswd is responsible for updating credentials,<br>and kadmind is responsible for remote administration of credentials.<br><br>As it stands, kadmind is started only from inetd. During a perusal of
<br>the docs, I found the following:<<EOF<br><br>4.6 Remote administration<br>=========================<br><br>The administration server, `kadmind', can be started by `inetd' (which<br>isn't recommended) or run as a normal daemon. If you want to start it
<br>from `inetd' you should add a line similar to the one below to your<br>`/etc/inetd.conf'.<br>EOF<br><br>I modified my krb5.conf file so that heimdal stores its principals in an<br>LDAP data store. A peculiarity of this configuration is that kadmind
<br>expects the access control file to be named after the LDAP dn of the<br>principal container node and to be in the current directory:<<EOF<br><br>cjac@kerberos:~$ ls -l /etc/heimdal-kdc/*.acl<br>-rw-r--r-- 1 root root 156 Nov 8 18:00 /etc/heimdal-kdc/kadmind.acl
<br>lrwxrwxrwx 1 root root 28 Nov 8 17:31 /etc/heimdal-kdc/ldap:ou=KerberosPrincipals,dc=cls2,dc=colliertech,dc=org.acl -> /etc/heimdal-kdc/kadmind.acl<br>EOF<br><br>In order to set $PWD to the correct value, inetd would need to call a
<br>wrapper which does the chdir(2) and exec(3) . I haven't gotten around<br>to creating one, since the documentation advises against a configuration<br>which uses inetd and hints toward eventual deprecation / obsolescence of
<br>inetd support.<br><br>I have instead created some extra package files in<br>heimdal-0.7.2.dfsg.1/debian/ which will (hopefully) configure kadmind to<br>run as a daemon. When I get it working on my system, I'll submit a
<br>patch to the BTS and prostrate myself for a beating.<br><br>At this point, it seems that kadmind and kpasswd should be de-coupled<br>from kdc and moved into their own packages. I can imagine many use<br>cases where administrators wouldn't feel comfortable opening a TCP port
<br>for remote administration of kerberos principals, and "slave" servers<br>should not run kpasswd. Allowing sysadmins to choose not to install the<br>daemons seems a useful feature.<br><br>Currently, all heimdal servers run as root. Yipe. We should probably
<br>create a system user and group as well as an SELinux MAC policy.<br>This /is/ a network authentication infrastructure, after all.<br><br>cjac@kerberos:~$ ps auwx | grep heimdal | grep root<br>root 1776 0.0 4.1 7164 2712 ? Ss 06:13 0:00 /usr/lib/heimdal-servers/kdc
<br>root 1778 0.0 2.6 6172 1740 ? Ss 06:13 0:00 /usr/lib/heimdal-servers/kpasswdd<br><br>While going through all of this, I considered requirements to ease the<br>process of modifying the heimdal packages to configure the system to use
<br>alternative principal sources. Is it possible to have one package query<br>another's entries in the database? How about making modifications to<br>another's configuration? In order to store to OpenLDAP, heimdal would
<br>benefit from being able to discover some system settings:<br><br>* the configured LDAP base DN<br>* LDAP bind dn and password capable of creating the KerberosPrincipals<br>ou and a bind dn for the heimdal daemons' access to principals
<br><br>Additionally, the package would need to cause some modifications<br>to /etc/default/slapd and /etc/ldap/slapd.conf, which are owned by the<br>slapd package.<br><br>* /etc/default/slapd:<br>** SLAPD_SERVICES="$SLAPD_SERVICES ldapi:///"
<br><br>/etc/ldap/slapd.conf:<br>** include /etc/ldap/schema/hdb.schema<br>** localSSF <SSF><br>** sasl-secprops minssf=<above SSF><br>** sasl-regexp "gidNumber=<heimdal GID>\\\+uidNumber=<heimdal UID>,cn=peercred,cn=external,cn=auth"
<br> "<heimdal bind dn>"<br>** access to dn.subtree=<principal container dn><br> by dn="<heimdal bind dn>"<br><br>Will heimdal packages need to ask slapd to re-configure itself with
<br>these modifications, or can they make modifications in such a way that<br>slapd won't over-ride them and will recognize them when the user<br>re-configures?<br><br>If heimdal is configured to store principals to LDAP, removal of slapd
<br>would break the system's kerberos settings, unless principals were<br>dumped to heimdal's native database and the /etc/krb5.conf were updated<br>to reflect the change.<br><br>I would like to see a simple set of regression tests run after
<br>(re)configuration of slapd and heimdal packages. This would ensure that<br>the heimdal user is able to access and modify principals. There should<br>also be a rollback mechanism in case the regression tests fail. I'd
<br>hate to see an automated update cause a kerberos outage until a human<br>was able to fix the problem.<br><br>Looking forward to your responses,<br><font color="#888888"><br>C.J.<br><br></font></blockquote></div><br><br clear="all">
<br>-- <br>moo.