[Pkg-openldap-devel] Heimdal changes

[C.J. Adams-Collier]

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 <cjcollier at gmail.com> 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
>
> cjac at kerberos:~$ 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.
>
> cjac at kerberos:~$ 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20071130/a523122e/attachment-0001.htm