Ei bine, o posibilitate este ca mașina cu kadmind ar putea avea propria copie a bazei de date, copia principală și toate KDC-urile au doar replici ale acesteia.
Atât MIT Krb5, cât și Heimdal Kerberos au instrumente de replicare, cum ar fi kpropd, pentru a construi clustere KDC redundante. Deci, în cel mai simplu caz, puteți avea trei KDC-uri, dar numai unul dintre ele rulează kadmind, cu kprop fiind folosit pentru a transfera modificări. (KDC-urile în sine nu fac actualizări permanente ale bazei de date, în afară de urmărirea opțională a orelor de „ultima conectare”, astfel încât replicarea poate fi unidirecțională.)
În același mod, puteți avea, de asemenea, o configurare similară cu „stealth master” în DNS, în care copia principală este gestionată de pe o mașină care nu este expusă clienților și toate modificările sunt transmise KDC-urilor prin kprop (sau rsync sau de bază dump+load prin SSH).
O altă posibilitate este ca KDC să fie nu utilizează stocarea BerkeleyDB bazată pe fișiere in primul loc. Atât MIT Kerberos, cât și Heimdal pot folosi efectiv un server LDAP ca baza de date KDC și, odată ce aveți asta, kadmind procesul se poate conecta la serverul LDAP de la distanță â nu ar exista principal dosar deloc.
(Mai multe servere LDAP acceptă, de asemenea, replicarea multi-master, care poate fi folosită pentru a face toate replici inscriptibile, de ex. ai putea avea 3 mașini care rulează OpenLDAP + KDC + kadmind, toate la fel "primare".
Într-adevăr, dacă te uiți la Active Directory Microsoft, acesta se bazează în întregime pe un director LDAP care deține toate informațiile – inclusiv datele KDC și DNS – și toate DC-urile reproduc schimbările în toate direcțiile. Nu are un proces „kadmin” separat; în schimb, directorii Kerberos sunt creați prin LDAP ca parte a utilizatorului general sau a contului mcahine și puteți doar să creați acea intrare pe orice DC doriți.)
