Propagating the Kerberos Server

Monitoring Propagation

For example, a prop_hostname file that is older than 48 hours or is unusually large indicates a propagation problem between the primary and secondary security servers as specified in hostname.

Updating the principal.ok Time Stamp

You may notice that, by default, the time stamp of the principal.ok file on the primary security server does not update after propagation. On the primary security server, the principal.ok file retains the date when the database is initially created. Do not change this database unless the database is deleted and rebuilt.

On the secondary security server, the principal.ok file is updated each time a propagation full dump from the primary is successfully completed. During a full dump, the database updates are copied to temporary files on the secondary security server. When all of the temporary files are updated, they are put into place on the secondary security server as permanent database files. If a full dump is not completed, the principal database files on the secondary security server, including the principal.ok file, remain unchanged, and the date does not change.

Because most propagation occurs as incremental propagation, an old time stamp on the principal.ok file of the secondary security server does not necessarily indicate a propagation failure, whereas a new principal.ok file indicates a failure.

Comparing the Database to Its Copies

No built-in functionality is available in the principal database to automatically ensure consistency between the database on the primary security server and the secondary security servers. However, you can use /opt/krb5/admin/kdb_dump to manually compare the contents of two databases and to identify discrepancies.

You must periodically check that the primary and secondary databases are synchronized. An out-of-sync condition is likely to exist when the following events occur:

Authentication problems

The out-of-sync condition may first appear as an intermittent authentication failure. In this scenario, a principal that changes the password after the password expires is unable to authenticate, even though the password change is successful. The principal continues its attempt to authenticate, and succeeds if the authentication

Chapter 9

265