Kerberos Login Handler and multiple KDCs

[Douglas E. Engert]

On 4/3/2012 9:13 PM, Martin B. Smith wrote:
> 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)


OK, with straight Kerberos with a master and slaves KDCs. We use AD, that does not have
that issue, so I never looked to see which DC the IDP is using at any given time.

>
>> 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):
>

This sure looks like what you are seeing!
Never knew it was there.

> # 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,
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444