kadmind
(it is also your realm's admin server), and one or more KDCs (slave KDCs) keep read-only copies of the database and run kpropd
.
krb5.conf
and kdc.conf
files are copied to the slave KDC.
kadmin.local
from a root shell on the master KDC and use its add_principal
command to create a new entry for the master KDC's host service, and then use its ktadd
command to simultaneously set a random key for the service and store the random key in the master's default keytab file. This key will be used by the kprop
command to authenticate to the slave servers. You will only need to do this once, regardless of how many slave servers you install.
#
kadmin.local -r EXAMPLE.COM
Authenticating as principal root/admin@EXAMPLE.COM with password.kadmin:
add_principal -randkey host/masterkdc.example.com
Principal "host/host/masterkdc.example.com@EXAMPLE.COM" created.kadmin:
ktadd host/masterkdc.example.com
Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.kadmin:
quit
kadmin
from a root shell on the slave KDC and use its add_principal
command to create a new entry for the slave KDC's host service, and then use kadmin
's ktadd
command to simultaneously set a random key for the service and store the random key in the slave's default keytab file. This key is used by the kpropd
service when authenticating clients.
#
kadmin -p jimbo/admin@EXAMPLE.COM -r EXAMPLE.COM
Authenticating as principal jimbo/admin@EXAMPLE.COM with password.Password for jimbo/admin@EXAMPLE.COM:
kadmin:
add_principal -randkey host/slavekdc.example.com
Principal "host/slavekdc.example.com@EXAMPLE.COM" created.kadmin:
ktadd host/slavekdc.example.com@EXAMPLE.COM
Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.kadmin:
quit
kprop
service with a new realm database. To restrict access, the kprop
service on the slave KDC will only accept updates from clients whose principal names are listed in /var/kerberos/krb5kdc/kpropd.acl
. Add the master KDC's host service's name to that file.
#
echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
/var/kerberos/krb5kdc/.k5.REALM
, either copy it to the slave KDC using any available secure method, or create a dummy database and identical stash file on the slave KDC by running kdb5_util create -s
(the dummy database will be overwritten by the first successful database propagation) and supplying the same password.
kprop
service. Then, double-check that the kadmin
service is disabled.
kprop
command will read (/var/kerberos/krb5kdc/slave_datatrans
), and then use the kprop
command to transmit its contents to the slave KDC.
#
/usr/sbin/kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
#
kprop slavekdc.example.com
kinit
, verify that a client system whose krb5.conf
lists only the slave KDC in its list of KDCs for your realm is now correctly able to obtain initial credentials from the slave KDC.
kprop
command to transmit the database to each slave KDC in turn, and configure the cron
service to run the script periodically.