On Fri, Nov 30, 2007 at 03:48:19PM -0800, C.J. Adams-Collier wrote: > > 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)
Is this still the case with Heimdal 1.0? If it is, I'd suggest reporting it upstream. No daemon should depend on the current directory. > > 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. Quite the contrary. You want everything installed on the slaves in case the master dies and you have to do a failover. Maybe add a low-priority debconf question whether this will be the master or a slave and configure the kadmind/kpasswdd daemons appropriately. > > 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. IMHO if the KDC is compromised then whether the intruder gets root or not is the least of your worries. You must assume that the complete database was stolen and they're happily cracking the master key so you must re-key every principal. Re-installing the KDC from scratch is about half an hour (you do not run _anything_ else on it, right?), re-generating and re-distributing the host keys and issuing new passwords for users may take days or weeks depending on the number of principals. > > 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. What do you mean by that? > > 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 Which one? A single KDC instance can serve multiple realms using multiple databases (well, you need some small patches for 0.7; they should be included in 1.0 - I'll find out once I upgrade). Or different kdc/kadmind/kpasswdd instances may run on the same machine bound to different IP addresses. > > * LDAP bind dn and password capable of creating the KerberosPrincipals > > ou and a bind dn for the heimdal daemons' access to principals Huh? You want to discover a _password_?!? If that password is stored anywhere else than the kdc's configuration that would be quite a serious misconfiguration... > > 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. That would be a very _BAD_ thing to do. Mucking with other packages' config files only increases the possibility that something will go wrong if the admin already did non-trivial modifications to those files. > > 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. Well, the UNIX philosophy is to let sysadmins shot themselves in the foot if they want to. Do not employ clueless sysadmins. > > 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. Automated update? On a KDC?!?! No way! An update can _ALWAYS_ go wrong and can _ALWAYS_ cause breakage, so - no sane man wants to do it on the master before being absolutely sure that it worked on a replica - no sane man wants to do it at a time when there are no sysadmins near the console Gabor -- --------------------------------------------------------- MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences --------------------------------------------------------- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]