List,
> I would like to upgrade my inter-realm trust key from DES to AES.
I've always wondered...
Those descriptions that explain that we need a ticket krbtgt/A@B to
allow clients in realm B to access services in realm A (right?) seem to
forget about one thing, namely to avoid failures authenticating.
In any live setup, I would first setup the service-side KDCs,
krbtgt/A@B on the KDC for A
krbtgt/B@A on the KDC for B
and only after the dust on that has settled (replication and such) I
would trust myself to add the tickets to the client-side KDCs,
krbtgt/A@B on the KDC for B
krbtgt/B@A on the KDC for A
Likewise, to remove an older krbtgt, I'd want to first remove the
client-side KDC entry, see to it that all replicas are gone, and then
wait for one longest ticket time, and only then remove the service-side
KDC entry.
I didn't see that documented anywhere, though it seems to be the one
sane approach to avoid interruptions to the authentication services. Right?
(Not sure if this is on-topic, sorry... changing the keys available may
not be the same as setting up fresh crossover trust.)
Cheers,
-Rick
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
