KDC HA Failure with krb5-1.9.1 and pam-krb5 4.4

[Tom Parker]

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 tparker at LS.CBN
[19969] 1321656817.827423: Getting initial credentials for tparker at LS.CBN
[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 tparker at LS.CBN:
[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 tparker at LS.CBN
[19969] 1321656825.631938: Removing tparker at LS.CBN -> 
krbtgt/LS.CBN at LS.CBN from FILE:/tmp/krb5cc_0
[19969] 1321656825.631952: Storing tparker at LS.CBN -> 
krbtgt/LS.CBN at LS.CBN in FILE:/tmp/krb5cc_0
[19969] 1321656825.632108: Storing config in FILE:/tmp/krb5cc_0 for 
krbtgt/LS.CBN at LS.CBN: fast_avail: yes
[19969] 1321656825.632157: Removing tparker at LS.CBN -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/LS.CBN\@LS.CBN at X-CACHECONF: 
from FILE:/tmp/krb5cc_0
[19969] 1321656825.632173: Storing tparker at LS.CBN -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/LS.CBN\@LS.CBN at 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 tparker at LS.CBN
>    KRB5_TRACE=/dev/stdout kvno host/arudrdb.ls.cbn at LS.CBN
>
> 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
>