Changes to kdcregister

In Informatics we have, for years, used the kdcregister program to obtain keytabs for host-based kerberos principals from the KDC. An important part of this usage is to obtain keytabs when a machine is being installed.

This has historically worked through the lcfg-kerberos LCFG component asking the user to enter their admin principal and password as one of the final stages of the installation process. This creates a ‘hostclient’ principal and extracts it to a keytab, which in turn is used to create other principals and extract them to keytabs, all according to the kerberos component resources.

A couple of factors have arisen that meant we required some new functionality from kdcregister. Firstly, colleagues in IS wished to run kdcregister at a much earlier stage of the installation process. As this is one of few parts that requires interactive input, it is preferable to do this early, and leave the machine to complete the installation, rather than require user interaction both to start and complete the installation. Secondly, the introduction of SL7 means a move to systemd, which didn’t seem to play nicely with the kerberos component requiring input at boot time (this could probably be worked
around, if needed).

One of the issues with running kdcregister early in the installation process is the requirement for a krb5.conf file with appropriate realm configuration – this provides details on how to communicate with the realm’s kadmin server. Having to provide such a file is obviously not ideal, so two new arguments have been added to kdcregister – these
allow the realm (-r) and server (-s) to be supplied. Note that the krb5 libraries still seem to require a krb5.conf file to exist, but this can be the example one shipped with kerberos.

To assist in scripted running of kdcregister, the -a option has been added. This results in kdcregister asking for a principal to authenticate with (this overrides the -p option if it’s also provided). One issue with specifying the principal to authenticate with is that getting this part wrong will result in kdcregister failing – this could present a problem during the installation process, but it would perhaps be more appropriate to wrap kdcregister in a loop, rather than put such functionality in kdcregister itself.

With the new options, an example of running kdcregister during the installation would be something like: