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