Red Hat ENTERPRISE LINUX 5 - DEPLOYMENT Deployment Manual page 702

Chapter 43. Securing Your Network
Start 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
Start 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
With its service key, the slave KDC could authenticate any client which would connect to it. Obviously,
not all of them should be allowed to provide the slave's 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
Once the slave KDC has obtained a copy of the database, it will also need the master key which was
used to encrypt it. If your KDC database's master key is stored in a stash file on the master KDC
(typically named /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.
Ensure that the slave KDC's firewall allows the master KDC to contact it using TCP on port 754
(krb5_prop), and start the kprop service. Then, double-check that the kadmin service is disabled.
676