• Selective kdc discovery

    From Paul B. Henson@21:1/5 to All on Thu Oct 29 11:13:47 2020
    So management wants to replicate our core authentication infrastructure
    into the cloud so if the campus is down people will still be able to
    access cloud services. The components in question consist of a
    shibboleth idp which avails of kerberos for authentication and LDAP for directory services/attributes.

    Ideally, I would like on campus services to use the campus instances if
    they are available, and failover to the cloud instances if not. And correspondingly, I would like the cloud services to use the cloud
    instances if they are available, and campus ones if not.

    For LDAP the idp allows configuration of multiple directory servers,
    with failover. So I can easily configure the campus idp to hit campus
    ldap first, then failover to the cloud, and vice versa for the cloud idp.

    I'm trying to figure out how to handle kerberos. The question is also complicated in that the idp uses the java Kerberos client, which I don't
    think has feature parity with the MIT libraries in terms of kdc discovery.

    Using SRV or URI DNS records, it looks like I can configure some number
    of kdc's as primary, and other ones as secondary. However, this would
    cause both the campus and cloud instances to get the same one first, and
    the other one second. Potentially this could be worked around with
    separate DNS views, but I don't think that is going to be feasible for
    this deployment. I am also not sure if the java kerberos client
    understands SRV/URI records and properly splits them based on priority?

    In the krb5.conf file, you can specify kdc's statically, but there is no mechanism for prioritizing them or indicating which ones should be tried
    first. You can also specify one or more master_kdc's, but based on the documentation those are only accessed in the case of a password failure
    on one of the regular kdc entries? If, hypothetically, all of the
    regular kdc entries timeout, would the master_kdc entries still be used,
    or would the request simply fail at that point with an unreachable kdc
    error?

    Any other suggestions for achieving a separate primary/failover
    configuration for two different network locations in a fashion that
    would work properly with the Java kerberos client?

    Thanks much…

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Paul B. Henson on Sat Oct 31 01:02:34 2020
    To: kerberos@mit.edu

    On 10/29/20 2:13 PM, Paul B. Henson wrote:
    In the krb5.conf file, you can specify kdc's statically, but there is no mechanism for prioritizing them or indicating which ones should be tried first.

    In the MIT krb5 implementation, they are tried in the order specified,
    with a 1s delay in between. I can't speak to the Java implementation, unfortunately.

    You can also specify one or more master_kdc's, but based on the
    documentation those are only accessed in the case of a password failure
    on one of the regular kdc entries? If, hypothetically, all of the
    regular kdc entries timeout, would the master_kdc entries still be used,
    or would the request simply fail at that point with an unreachable kdc
    error?

    The request would fail with an unreachable error, in the MIT implementation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roland C. Dowdeswell@21:1/5 to Greg Hudson on Sat Oct 31 12:12:04 2020
    Copy: kerberos@mit.edu

    On Sat, Oct 31, 2020 at 01:02:34AM -0400, Greg Hudson wrote:


    In the MIT krb5 implementation, they are tried in the order specified,
    with a 1s delay in between. I can't speak to the Java implementation, unfortunately.

    Last I checked with the Java implementation which is granted a very
    long time ago (maybe 2012), they were used in order retrying failures
    three times. I think that the default timeout was 30s between each
    attempt meaning that it took 90s to reach the second KDC in the
    list. And, I think that it would never fail back to TCP unless
    the KDC specifically told it that the reply was too big for UDP.

    There is a krb5.conf var kdc_timeout, but I think that Java interprets
    in in either micro or milliseconds whereas Heimdal uses the same
    variable and interprets it in seconds. Some experimentation may
    be in order.

    These issues may have been fixed, but it is worth testing each of
    them because they can cause serious issues if a KDC is unavailable
    for any reason.

    You can also use the JNI implementation in Java which has the nice
    property that you don't have an extra set of Java libs with a
    separate set of bugs in your deployment.

    --
    Roland C. Dowdeswell http://Imrryr.ORG/~elric/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Paul B. Henson on Sun Nov 1 11:06:07 2020
    On 10/29/20 12:13 PM, Paul B. Henson wrote:
    Any other suggestions for achieving a separate primary/failover configuration for two different network locations in a fashion that
    would work properly with the Java kerberos client?

    I have no idea if this would work or not.

    But I would consider DNS views / host entries such that the first name
    in the list always resolved to the local server and subsequent names
    resolved to remote servers.

    The other thing I might try is to work with the networking team to see
    if it's possible to have things on an anycast IP to attract clients to
    the closest server. In the event that the close server has a problem,
    stop announcing the anycast IP and things will naturally go to the next closest server.

    You might be able to achieve similar behavior with something like a load balancer.

    I have no idea what sort of protections are in place that might fight
    this or what would need to be done to overcome it. Possibly having the
    local and remote instance be a clone of each other so that they seem to
    be the same entity.



    --
    Grant. . . .
    unix || die


    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzkwggUhMIIECaADAgECAhA53zcXtFD9dENby64EqrKqMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTExOTAwMDAw MFoXDTIwMTExODIzNTk1OVowKzEpMCcGCSqGSIb3DQEJARYaZ3RheWxvckB0bmV0Y29uc3Vs dGluZy5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwIZcEJcuE7mUfxJnD I8oOSX/TvAhoP11agD++8L7Ok8fFJhJK0lOVRsq1M6lF2E2Vzuyffg2ppbecWvHcIRadsaiG imnrJQasdkhj/JUtqPUXnC0SVA0AzYLrLReQB+9j/jTgB5JnFLyC2lEn9KTA6JmDGjvVkv2T k+I2+v24nI4/2lGjD+jIKQiFXkE1uqablXJAw1c9Mh9d4/wjnIM9zLGv1i3xxOLdQ1PXSUZL 12wOy1r7CsGAnNSNhGaceB2tdhdleFEyIHgSgDWtWResHdu/ubZqFiHxaLRJlafOHMj3yC6x NOA1IdcNJsaRkQHxSkayKzeE5JK3TxlV83dbAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBQJ wPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUU6bXebmKM+efFHN0MBjYuJO9Za8wDgYD VR0PAQH/BAQDAgWgMAwGA1UdEw
  • From Paul B. Henson@21:1/5 to Roland C. Dowdeswell on Wed Nov 4 22:10:25 2020
    Copy: kerberos@mit.edu

    On Sat, Oct 31, 2020 at 12:12:04PM +0000, Roland C. Dowdeswell wrote:

    Last I checked with the Java implementation which is granted a very
    long time ago (maybe 2012), they were used in order retrying failures
    three times. I think that the default timeout was 30s between each
    attempt meaning that it took 90s to reach the second KDC in the
    list.

    That does still appear to be the default based on empirical testing.

    There is a krb5.conf var kdc_timeout, but I think that Java interprets
    in in either micro or milliseconds whereas Heimdal uses the same
    variable and interprets it in seconds. Some experimentation may
    be in order.

    Yep, a value of 5000 for kdc_timeout for kdc timeout makes it wait 5
    seconds. It also appears to respect the max_retries parameter.

    You can also use the JNI implementation in Java which has the nice
    property that you don't have an extra set of Java libs with a
    separate set of bugs in your deployment.

    It's not my app, it's the shibboleth idp which uses the built in java
    kerberos implementation.

    I guess I'm going to have to figure out a way to give the two locations different views of the DNS SRV records giving higher priority to the
    local servers. And see if the java implementation even implements the
    priority component of the record <sigh>.

    Thanks for the info...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul B. Henson@21:1/5 to Greg Hudson on Wed Nov 4 21:53:39 2020
    Copy: kerberos@mit.edu

    On Sat, Oct 31, 2020 at 01:02:34AM -0400, Greg Hudson wrote:

    In the MIT krb5 implementation, they are tried in the order specified,
    with a 1s delay in between. I can't speak to the Java implementation, unfortunately.

    Ah, so each subsequent server is only used if all the ones before it
    failed? There's no mechanism for load balancing when using file based
    kdc configuration?

    We're currently using DNS SRV records and all of our kdc's seems to have
    fairly equal load. Are DNS SRV records handled differently in terms of distributing load, or is that just a side effect of the resolver handing
    them back in a different order for each lookup?

    The request would fail with an unreachable error, in the MIT implementation.

    Thanks for the info. It doesn't look like the java implementation tries
    the listed master anyway for a password failure, it just immediately
    errors out.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Paul B. Henson on Thu Nov 5 02:39:54 2020
    Copy: kerberos@mit.edu

    On 11/5/20 12:53 AM, Paul B. Henson wrote:
    We're currently using DNS SRV records and all of our kdc's seems to have fairly equal load. Are DNS SRV records handled differently in terms of distributing load, or is that just a side effect of the resolver handing
    them back in a different order for each lookup?

    SRV records contain a priority and a weight. The MIT krb5
    implementation orders the records by priority and ignores the weight.
    If all records have the same priority, we don't randomize the order, but
    the DNS resolver will typically will.

    (Heimdal actually uses the weight fields, so that part varies by implementation.)

    There's no mechanism for load balancing when using file based
    kdc configuration?

    Correct.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)