More than 2 failed master_kdc servers cause errors

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

More than 2 failed master_kdc servers cause errors

pgb205
krb5.conf looks like
kdc=server1kdc=server2kdc=server2master_kdc=server1master_kdc=server2master_kdc=server3
server1 and server2 are down. server3 is up and running
Attempting to auth with kinit user_id and above configuration will fail.
However commenting master_kdc=server1 and master_kdc=server2 lines will allow authentication
kdc=server1kdc=server2kdc=server2#master_kdc=server1#master_kdc=server2master_kdc=server3
KRB_TRACE shows that uncommented config only tries first two kdc servers and then just gives up.
I'm not sure if this is a bug with kerberos or something else that I have to fix.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More than 2 failed master_kdc servers cause errors

Greg Hudson
On 08/07/2017 04:31 PM, pgb205 wrote:
> krb5.conf looks like
> kdc=server1
> kdc=server2
> kdc=server2
> master_kdc=server1
> master_kdc=server2
> master_kdc=server3
> server1 and server2 are down. server3 is up and running
> Attempting to auth with kinit user_id and above configuration will fail.

(Did you mean to list "kdc=server2" twice?)

master_kdc is only intended to operate as a fallback for when a client
contacts a KDC which contains out-of-date keys due to propagation delay.
 If the client tries to contact all of the KDCs listed in values of
"kdc" and can't contact any of them, it does not fall back to trying
KDCs listed in master_kdc.

Also, the master_kdc fallback only applies to initial authentication,
not to TGS requests, although that should probably change.

> However commenting master_kdc=server1 and master_kdc=server2 lines will allow authentication
> kdc=server1
> kdc=server2
> kdc=server2
> #master_kdc=server1
> #master_kdc=server2
> master_kdc=server3

I would not expect that to work when server1 and server2 are
inaccessible, and it doesn't work when I try it in a simple test
environment.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More than 2 failed master_kdc servers cause errors

pgb205
Greg,
Sorry my mistake
I meant the following krb5.conf
kdc=server1kdc=server2kdc=server3master_kdc=server1master_kdc=server2master_kdc=server3
the above DOES NOT WORK when server1 and server2 are down.But If I comment master_kdc=server2 I'm able to kinit. Like so:
kdc=server1kdc=server2kdc=server3master_kdc=server1#master_kdc=server2master_kdc=server3
It seems like kerberos is ok with encountering one failed master_kdc but not two or more.
This is what KRB_TRACE shows with 'bad' configuration. Server3 is never even tried.
kinit tries server1 and server2 but never even attempts server3KRB5_TRACE=/dev/stdout kinit user(a)test.domain [12536] 1501112935.251721: Getting initial credentials for user(a)test.domain [12536] 1501112935.251917: Sending request (181 bytes) to test.domain[12536] 1501112935.251956: Resolving hostname server1[12536] 1501112935.252875: Sending initial UDP request to dgram server1_ip:88[12536] 1501112936.253962: Resolving hostname server2[12536] 1501112936.255680: Retrying AS request with master KDC[12536] 1501112936.255699: Getting initial credentials for user(a)test.domain[12536] 1501112936.255763: Sending request (181 bytes) to test.domain (master)[12536] 1501112936.255779: Resolving hostname server1[12536] 1501112936.256379: Sending initial UDP request to dgram server1_ip:88[12536] 1501112937.257451: Resolving hostname server2kinit: Invalid argument while getting initial credentials

      From: Greg Hudson <[hidden email]>
 To: pgb205 <[hidden email]>; "[hidden email]" <[hidden email]>
 Sent: Monday, August 7, 2017 4:52 PM
 Subject: Re: More than 2 failed master_kdc servers cause errors
   
On 08/07/2017 04:31 PM, pgb205 wrote:
> krb5.conf looks like
> kdc=server1
> kdc=server2
> kdc=server2
> master_kdc=server1
> master_kdc=server2
> master_kdc=server3
> server1 and server2 are down. server3 is up and running
> Attempting to auth with kinit user_id and above configuration will fail.

(Did you mean to list "kdc=server2" twice?)

master_kdc is only intended to operate as a fallback for when a client
contacts a KDC which contains out-of-date keys due to propagation delay.
 If the client tries to contact all of the KDCs listed in values of
"kdc" and can't contact any of them, it does not fall back to trying
KDCs listed in master_kdc.

Also, the master_kdc fallback only applies to initial authentication,
not to TGS requests, although that should probably change.

> However commenting master_kdc=server1 and master_kdc=server2 lines will allow authentication
> kdc=server1
> kdc=server2
> kdc=server2
> #master_kdc=server1
> #master_kdc=server2
> master_kdc=server3

I would not expect that to work when server1 and server2 are
inaccessible, and it doesn't work when I try it in a simple test
environment.


   
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More than 2 failed master_kdc servers cause errors

Greg Hudson
On 08/07/2017 05:51 PM, pgb205 wrote:
> It seems like kerberos is ok with encountering one failed master_kdc but
> not two or more.

>From the trace output, I think resolving server2 is encountering an
unusual error, which unfortunately manifests as EINVAL ("Invalid
argument") in our code.  That error does trigger the fallback to
master_kdc (though with better error handling it would not); during that
fallback, the same error occurs when it hits server2 and is then
reported to the client.  If you comment out "master_kdc=server2", then
that server is skipped during the master_kdc fallback and you get an
answer from server3.

The most reliable way to figure out what's going wrong is to step
through the kinit process in a debugger, focusing on resolve_server() in
lib/krb5/os/sendto_kdc.c.  That approach will only work well if you
rebuild the code with debugging symbols and without optimization.

If that isn't an easy option, you might be able to get some useful
information with "ltrace -e getaddrinfo kinit ..." to see if
getaddrinfo() is returning an error.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Loading...