After applying puppet to install the needed packages and make sure the
directories and such are in place, I used the fabric job build_new to deploy
auth2.l.znet. The following was performed to get the server ready to
serve clients.
The rc.conf configuration on the auth boxes have the following manual
additions.
kerberos5_server_enable="YES"
slapd_enable="YES"
slapd_cn_config="YES"
slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ ldaps://[2001:111:1111:1ab::18:4111]/ ldaps://10.210.18.35/"'
slapd_sockets="/var/run/openldap/ldapi"
slapd_krb5_ktname="/etc/krb5.keytab"
saslauthd_enable="YES"
saslauthd_flags="-a kerberos5"
Kerberos
Setting up the kerberos slave was pretty simple.
On all slave kerberos servers, the following has been added to inetd.conf.
krb5_prop stream tcp nowait root /usr/libexec/hpropd hpropd
The /var/heimdal/m-key file seems to be needed on both master ans slave KDC.
Puppet installed the cron on the master to execute hprop every hour to push the
database from the master to the slaves, as well as setup the inetd.conf on
the slave to receive the incoming connections. Once that was done, replication
of the kerberos realm was up and running. All that was needed was to adjust
the client configuration.
LDAP
Running fab build_new in the tools/ldap/ directory of this repo
deployed a base cn=config and znet databases.
Slapd was giving the following error when a client would connect.
OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied
The following made the error go away, and probably needs to be added to puppet.
chmod g+r /etc/krb5.keytab
chown :ldap /etc/krb5.keytab
An /etc/hosts entry seems to be required on the server for the server, though
this may be required for any GSSAPI client. The following command works as
expected when the host entry is present on the client system.
ldapwhoami -Y GSSAPI -Z -H ldaps://auth2.l.znet:636/