Kerberos Login Handler and multiple KDCs

[Martin B. Smith]

Hi Douglas,

On 4/3/2012 5:23 PM, Douglas E. Engert wrote:
> It is not clear why you consider it a problem that the first KDC is not used all the time.

We have a master KDCs and slave KDCs. Clients using the slave KDC will 
notice the propagation delay of changes. While it isn't a large delay 
(strictly less than 10 minutes), it can be noticeable when a user's 
password change or principal creation isn't instant. We'd prefer clients 
to stay on the slave KDCs only as long as there's a problem with the 
master (and that's what most of our clients do, by default)

> But it may have to do with the refreshKrb5Config option of the Krb5LoginModule. Having this option
> implies that some information is cached between logins.
>
>    http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html
>
> The version of java-kerberos-idp-login-handler we are running does set refreshKrb5Config = true in
> src/main/java/ch/SWITCH/aai/idp/kerberos/krbLoginModul.java

It's helpful to hear that you're using that in production. I had looked 
it at before sending my initial email, but I was concerned about 
reproducability. If I can't reproduce the problem outside of the IdP use 
case, and then observe the effects of my changes, I won't feel 
comfortable declaring the issue resolved.

For what it's worth, I've also discovered the following in the 
default/master java.security file (after a long read through the JDK7 
source files under the sun.security.krb5 package):

# Policy for failed Kerberos KDC lookups:
#
# When a KDC is unavailable (network error, service failure, etc), it is
# put inside a blacklist and accessed less often for future requests. The
# value (case-insensitive) for this policy can be:
#
# tryLast
#    KDCs in the blacklist are always tried after those not on the list.
#
# tryLess[:max_retries,timeout]
#    KDCs in the blacklist are still tried by their order in the 
configuration,
#    but with smaller max_retries and timeout values. max_retries and 
timeout
#    are optional numerical parameters (default 1 and 5000, which means once
#    and 5 seconds). Please notes that if any of the values defined here is
#    more than what is defined in krb5.conf, it will be ignored.
#
# Whenever a KDC is detected as available, it is removed from the blacklist.
# The blacklist is reset when krb5.conf is reloaded. You can add
# refreshKrb5Config=true to a JAAS configuration file so that krb5.conf is
# reloaded whenever a JAAS authentication is attempted.
#
# Example,
#   krb5.kdc.bad.policy = tryLast
#   krb5.kdc.bad.policy = tryLess:2,2000
krb5.kdc.bad.policy = tryLast


It sounds like that perfectly describes what I'm experiencing. I 
reproduced it here for posterity.

Thanks all,
-- 
Martin B. Smith
smithmb at ufl.edu - (352) 273-1374
CNS/Open Systems Group
University of Florida

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4893 bytes
Desc: S/MIME Cryptographic Signature
Url : http://shibboleth.net/pipermail/users/attachments/20120403/6ce523b0/attachment.bin