On 7/6/2011 2:22 PM, Simo Sorce wrote: > I would resolve all these issues by using aliases at the KDC level, but > thank you for explaining, it's valuable data on the way KDC/DNS are used > to keep track off.
The primary thing that the Kerberos development team needs to keep in mind every time a change is made is that Kerberos deployments are distributed and federated. In many of the environments there are many realms involved which are managed by different organizations. Upgrading clients and KDCs cannot be performed in lock step and there is no ability to coordinate which comes first the KDC / KDB update or the client deployments. Any transition plan to alter canonical name resolution processing must take that into account. It must be possible for a client machine to be updated in one organization or on one individual's machine and have it continue to work when the KDC/KDB for the realm that client communicates with is not updated to support KDC side aliasing. Just my two cents ... Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
