The behavior is different is the host is actually unreachable. If the machine is gone, instead of the KDC process being down then auth succeeds with a few seconds of lag. The issue seems to be when the call returns "connection refused"
KRB5_TRACE=/dev/stdout kinit [email protected] [19969] 1321656817.827423: Getting initial credentials for [email protected] [19969] 1321656817.827948: Sending request (170 bytes) to LS.CBN [19969] 1321656817.831693: Sending initial UDP request to dgram 172.20.23.10:88 [19969] 1321656818.834981: Sending initial UDP request to dgram 172.30.26.12:88 [19969] 1321656818.844036: Received answer from dgram 172.30.26.12:88 [19969] 1321656818.845838: Response was from master KDC [19969] 1321656818.845870: Received error from KDC: -1765328359/Additional pre-authentication required [19969] 1321656818.845915: Processing preauth types: 2, 136, 19, 133 [19969] 1321656818.845943: Selected etype info: etype aes256-cts, salt "LS.CBNtparker", params "" [19969] 1321656818.845953: Received cookie: MIT Password for [email protected]: [19969] 1321656824.612797: AS key obtained for encrypted timestamp: aes256-cts/50AF [19969] 1321656824.612886: Encrypted timestamp (for 1321656824.612816): plain 301AA011180F32303131313131383232353334345AA10502030959D0, encrypted B86E9C566EDB920FC28E01FD3B070DEDE0482A03CF9B3FEB5856FB1BE7A6706A6023503348B34FFB581CE3EADF2E2E43FFC1F65DFBE42435 [19969] 1321656824.612912: Produced preauth for next request: 133, 2 [19969] 1321656824.612941: Sending request (265 bytes) to LS.CBN (master) [19969] 1321656824.617433: Sending initial UDP request to dgram 172.20.23.10:88 [19969] 1321656825.619054: Sending initial UDP request to dgram 172.30.26.12:88 [19969] 1321656825.631209: Received answer from dgram 172.30.26.12:88 [19969] 1321656825.631311: Processing preauth types: 19 [19969] 1321656825.631328: Selected etype info: etype aes256-cts, salt "LS.CBNtparker", params "" [19969] 1321656825.631338: Produced preauth for next request: (empty) [19969] 1321656825.631360: AS key determined by preauth: aes256-cts/50AF [19969] 1321656825.631470: Decrypted AS reply; session key is: aes256-cts/109F [19969] 1321656825.631504: FAST negotiation: available [19969] 1321656825.631553: Initializing FILE:/tmp/krb5cc_0 with default princ [email protected] [19969] 1321656825.631938: Removing [email protected] -> krbtgt/[email protected] from FILE:/tmp/krb5cc_0 [19969] 1321656825.631952: Storing [email protected] -> krbtgt/[email protected] in FILE:/tmp/krb5cc_0 [19969] 1321656825.632108: Storing config in FILE:/tmp/krb5cc_0 for krbtgt/[email protected]: fast_avail: yes [19969] 1321656825.632157: Removing [email protected] -> krb5_ccache_conf_data/fast_avail/krbtgt\/LS.CBN\@LS.CBN@X-CACHECONF: from FILE:/tmp/krb5cc_0 [19969] 1321656825.632173: Storing [email protected] -> krb5_ccache_conf_data/fast_avail/krbtgt\/LS.CBN\@LS.CBN@X-CACHECONF: in FILE:/tmp/krb5cc_0 On 11/18/2011 05:13 PM, Greg Hudson wrote: > On 11/18/2011 02:17 PM, Tom Parker wrote: >> The problem I have is that if I update my client from 1.8.3 to 1.9.1 my >> High Availability breaks. A 1.9.1 client will not successfully >> authenticate if one of my KDCs is down. My 1.8.3 clients work fine. > Unfortunately, I'm unable to reproduce this. I created two SRV records, > one pointing to a test server and one pointing to an invalid point, and > 1.9.x clients were able to make successful AS and TGS requests to that > zone regardless of whether they tried the incorrect or correct port first. > > There weren't very many changes to the KDC location or communication > code between 1.8 and 1.9 (although there were a few mostly innocuous > ones) and there haven't been any since the 1.9 branch. > > 1.9 supports a new tracing facility which might provide a little > additional information, although it's not possibly to use in concert > with pam_krb5. But you can use it with kinit or kvno, e.g.: > > KRB5_TRACE=/dev/stdout kinit [email protected] > KRB5_TRACE=/dev/stdout kvno host/[email protected] > > When I do this in my test scenario, I see stuff like: > > [6252] 1321653654.244586: Sending initial UDP request to dgram > 18.18.1.59:50799 > [6252] 1321653654.244628: UDP error receiving from dgram > 18.18.1.59:50799: 111/Connection refused > [6252] 1321653654.244641: Sending initial UDP request to dgram > 18.18.1.59:50800 > [6252] 1321653654.247219: Received answer from dgram 18.18.1.59:50800 > > Or, if the wrong entry goes to a black hole, I see (note the one-second > delay between the first and second entries): > > [6652] 1321654279.235052: Sending initial UDP request to dgram > 18.70.0.200:50799 > [6652] 1321654280.236097: Sending initial UDP request to dgram > 127.0.1.1:50800 > [6652] 1321654280.236639: Received answer from dgram 127.0.1.1:50800 > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
