Ну, одна из возможностей состоит в том, что машина с кадминд может быть своя копия базы данных, главная копия и все KDC имеют только ее реплики.
И MIT Krb5, и Heimdal Kerberos имеют средства репликации, такие как kpropd, для создания избыточных кластеров KDC. Таким образом, в простейшем случае у вас может быть три KDC, но только на одном из них работает kadmind, а kprop используется для передачи изменений. (Сами KDC не делают постоянных обновлений БД, за исключением дополнительного отслеживания времени «последнего входа», поэтому репликация может быть однонаправленной.)
Точно так же у вас может быть настройка, подобная «скрытому мастеру» в DNS, где основная копия управляется с машины, недоступной для клиентов, а все изменения передаются на KDC через kprop (или rsync, или базовую дамп+загрузка по SSH).
Другая возможность состоит в том, что KDC не использовать файловое хранилище BerkeleyDB в первую очередь. И MIT Kerberos, и Heimdal могут использовать LDAP-сервер в качестве базы данных KDC, и как только она у вас появится, кадминд процесс может подключаться к серверу LDAP удаленно — не было бы главный файл вообще.
(Несколько серверов LDAP также поддерживают репликацию с несколькими мастерами, которую можно использовать для все реплики доступны для записи, например. у вас может быть 3 машины с OpenLDAP + KDC + kadmind, все они одинаково «основные».
Действительно, если вы посмотрите на Microsoft Active Directory, вы увидите, что она полностью основана на каталоге LDAP, в котором хранится вся информация, включая данные KDC и DNS, и все контроллеры домена реплицируют изменения во всех направлениях. У него нет отдельного процесса «kadmin»; вместо этого участники Kerberos создаются через LDAP как часть общей учетной записи пользователя или mcahine, и вы можете просто создать эту запись на любом контроллере домена, который вам нравится.)
