Ticket 5338: Race conditions in key rotation
jaltman at secure-endpoints.com
Wed Jun 25 17:51:08 EDT 2008
Jeffrey Hutzelman wrote:
> --On Wednesday, June 25, 2008 03:49:28 PM -0400 Jeffrey Altman
> <jaltman at secure-endpoints.com> wrote:
>> This is not true. The delay when a server is down is the timeout
>> for any response
>> not the time necessary to get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and retry.
> Without your change, the delay when a server is down is the same as
> the delay when a server is not down, which is the time necessary to
> get KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN and move on to try the next
> service principal name. There is no timeout because the routing
> configuration guarantees the request does not go to the server that is
Then why did you raise the issue of the timeout when the server was down?
> With your change, the delay is the time to get
> KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN from a working server, plus the time
> to timeout the request to the admin server, which is down.
> Unless, of course, I'm misreading your earlier statement that
>> This definition is specified either via the use of the "master_kdc"
>> in the realm section of the krb5.conf (the profile) or in DNS SRV
Its not the admin_server unless your master_kdc and admin_server records
are pointing to the same
machines. But yes, if the master_kdc is down there will be an added
delay with this logic.
Of course, we really need to find a better way to obtain afs service
tickets that doesn't involved
N best guesses to figure out what the correct realm should be and what
the correct principal
format should be. Is it afs at REALM or afs/cell at REALM and with rxk5 or
rxgk some additional
principal name form? But this is getting severely off topic.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20080625/2ad065f7/attachment.bin
More information about the krbdev