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.
signature.asc
Description: This is a digitally signed message part
