• Kerberos through loadbalancer

    From Stefan Kania@21:1/5 to All on Fri May 20 09:41:20 2022
    Hi to all,

    we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
    securing the replication via kerberos, everything works fine between the providers. But now we want to set up some consumers. Between the
    providers and the consumers a loadbalancer is located, so the consumers
    only connect to the loadbalancer and the loadbalancer chooses one of the providers. For the replication we put the fqdn from the loadbalancer
    into the configuration. The fqdn is ldap.example.net. We then created a host-principal and a service-principal for ldap.example.net and we put
    the host-key into /etc/krb5.keytab of all ldap-providers the same with
    the service-key. So now all provider can use both, the own keys and the
    keys from the loadbalancer. But it's not working :-(. In the log of the provider we see that the consumer connects. ldaps is working. But
    kerberos failed with the following messages:
    --------------------
    SASL [conn=5032] Failure: GSSAPI Error: Miscellaneous failure (see
    text) (Decrypt integrity check failed for checksum type
    hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96)

    slapd[59382]: conn=5032 op=0 RESULT tag=97 err=49 qtime=0.000028
    etime=0.017274 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

    --------------------
    The same user we are using works without using the loadbalancer. If our solution is wrong, what would be the right way to use a loadbalancer
    together with kerberos?

    Stefan




    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CdEwggSUMIIDfKADAgECAghoLCY2SG4frzANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJE RTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJI MSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBOMB4XDTIxMTAwMzE0MzMwM1oX DTIyMTAwMzE0MzMwM1owbjELMAkGA1UEBhMCREUxITAfBgNVBAUTGDQwMDAwMDAwNjE1OWMx N2QyYmZjMTAyYzEVMBMGA1UEAwwMU3RlZmFuIEthbmlhMSUwIwYJKoZIhvcNAQkBFhZzdGVm YW5Aa2FuaWEtb25saW5lLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4L6 +t8YsmErxzkeCgfmXRrQQEHJQyZQxYPObVLOqodpHjkmMnYHYjplhHyxcAaJKNuCoAv941t1 iH1Lu12yOQS2yRE7xNAcoPx/acnZo5M7dAJOJ8JTmTYFbKkNGSNT7PJpA1xrxjuIRgXnEg/N 1nDKaSRIDrMyjDdUsa/mFKi1fp8/CvDIg/oL0Z0FuB6BsZHnshP+leRSjEDARmhkC8ifiDKo EMqiLVU1CqHgidRWM/aPYKpJ8zOQCUvZsIID4Vy393nJytuCBAUz9jCuDXwaFI7x2+yhg2VZ qZgURJlwwwgXk7DUCtXV5Jm8fyJQQT41MEb+IBVTqW+lEx+qkwIDAQABo4IBPDCCATgwHQYD VR0OBBYEFN3Lma+ERE52zn+UO6mQL8KOfmWpMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU 6caT0dUPBmRy6mqWProQ8lRUsnkwVgYDVR0gBE8wTTBLBgwrBgEEAfsrAgEDAggwOzA5Bggr BgEFBQcCARYtaHR0cDovL3NlYzUuZGduc2VydmljZS5kZS9wb2xpY2llcy9pbmRleC5odG1s MD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9zZWM1LmRnbnNlcnZpY2UuZGUvY3JsL2NybDIt dHlwZS1lLmNybDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnN0ZWZhbkBrYW5pYS1vbmxpbmUuZGUwDQYJKoZIhvcNAQELBQAD ggEBAM4bjRa/F8JdiKUN4vUmR/T/+JgCfYWpIhZM/4G6otEeQH/3yZSjsSw6KakUGlUzrhga B2bLyqjGwa7AjpwfuipQy0PRuKxZm5Lk7DDa3iIY4vqftpC2F5YMyb7yW2fLAOsnW3U4z44L cyKOuThoyXtrK4klUuqg0PjCDRhPlsjB/E+ITF1Jb0zRFY55flsoaCey1Cghpe7yTqxaWbSG MR8r10FYGbBDy7j/kXbKGYm9e2fX2SitrDeZrjtTkvraFdNrnWx4BGyYEzflTfkOFZQGLRPD pRjkzsxZ8Lf/Ew3tEUEdk41ACOo+r8GM4riMms7zhn6hJxEQF3KIp8NxFT0wggU1MIIEHaAD AgECAghVHErXZq0l9jANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJERTEzMDEGA1UECgwq REdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJIMR0wGwYDVQQDDBRk Z25zZXJ2aWNlIFJvb3QgNzpQTjAeFw0xNjEwMjYwOTIyNDFaFw0yNDEwMjYwOTIyNDFaMGYx CzAJBgNVBAYTAkRFMTMwMQYDVQQKDCpER04gRGV1dHNjaGVzIEdlc3VuZGhlaXRzbmV0eiBT ZXJ2aWNlIEdtYkgxIjAgBgNVBAMMGWRnbnNlcnZpY2UgQ0EgMiBUeXBlIEU6UE4wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcpfKUP3THo0fSl2bOa6PNbRcDYZaE4ZV3vLGr e/U445OsRahORPeP/9L4nycTK6fUawpDTqOaDxtXYxjoJNC9LnKRxVB/UkBf0h25vN0L1iV4 KhCaY8TimV0z2yUSlb2NuZ4gdBU69qJkasqYj+AP8OcQOo0idj9Nr1eloHD32i0JDPkhBj8V f6c6b7mNyn8yfZYvZlzzV2iQ/cvo6iFLx2wgG7mCkOZ8BAHGDFw6T0UIA0Bk60YhRMRxI7GX jMxBQA2Y/XXoP4dvQDDtMNmK0r5DUXof87w2brXctuQ2b4xNwFIErVoAQu8ftnXTm9iOtaOs WyLMZX6v5szaQBqBAgMBAAGjggHqMIIB5jASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQY MBaAFAEMFht0ctM8FO4md7dJFFPY+4sbMFsGCCsGAQUFBwEBBE8wTTBLBggrBgEFBQcwAYY/ aHR0cDovL3JvY3NwLWRnbi5kZ25zZXJ2aWNlLmRlOjgwODAvZWpiY2EvcHVibGljd2ViL3N0 YXR1cy9vY3NwMGoGA1UdIARjMGEwXwYMKwYBBAH7KwIBBAIBME8wTQYIKwYBBQUHAgEWQWh0 dHA6Ly93d3cuZGduc2VydmljZS5kZS90cnVzdGNlbnRlci9wdWJsaWMvZGduc2VydmljZS9p bmRleC5odG1sMIGZBgNVHR8EgZEwgY4wgYuggYiggYWGgYJsZGFwOi8vbGRhcC5kZ25zZXJ2 aWNlLmRlOjM4OS9DTj1DUkwtMSxPPURHTiUyMFNlcnZpY2UlMjBHbWJILEM9REU/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50MB0GA1UdDgQWBBTpxpPR1Q8GZHLqapY+uhDyVFSyeTAOBgNVHQ8BAf8EBAMCAQYwGwYJ KwYBBAHAbQMFBA4wDAYKKwYBBAHAbQMFATANBgkqhkiG9w0BAQsFAAOCAQEAq7w5+kXJ+/xT at0jiTX4GDX5HUeQohqAuLGfotHcqQqqjF8G6UUI0q4i0tnhHtldhZrNBOErgThGsToNZ1Y2 Gn0FRrcrUU9LnhSMwd1XJ0Je6ERSdEh4vXf8YxJQGZJPCPJcrblhue0mmwO9nbhKewGglht5 VWSHTS8vq5Da3zbxFG6lIdE62V4KqcMAiyY2BfL8guCPscTWl5txJrjb4ENo9nRqdzsXNEG3 yyzgmyv6znQ4pGgTe5E6qXx5bO6XCDoUK4Kz1S82PzR6hvcxKZo7kKK2ut2B3buwU8xqfw73 EMH8imv4LW/Sx59wKElKjijjHdNrFG/wMRobDYzMyTGCA4IwggN+AgEBMHIwZjELMAkGA1UE BhMCREUxMzAxBgNVBAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2Ug R21iSDEiMCAGA1UEAwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wDQYJ YIZIAWUDBAIBBQCgggHhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTIyMDUyMDA3NDEyMVowLwYJKoZIhvcNAQkEMSIEIBmKFFj8mlNZlQ3MHlsxit6/6dK4 oby6r87XUSJoazf4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYEGCSsGAQQBgjcQBDF0MHIwZjELMAkGA1UEBhMCREUxMzAxBgNV BAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2UgR21iSDEiMCAGA1UE AwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wgYMGCyqGSIb3DQEJEAIL MXSgcjBmMQswCQYDVQQGEwJERTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0 c25ldHogU2VydmljZSBHbWJIMSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBO AghoLCY2SG4frzANBgkqhkiG9w0BAQEFAASCAQAGd0Xhdfsm5XyxtftXQLILUjvb3SurHqgW LsaGZRQpJWzoL7+7CIIQLPiaSbulJYqMlAaTJgl81Oc3bN7auGZtwoUO0QobZXTEw1Ub3k0X /4H18ozIw8fWQV1nL0pa/kgiZOUAWioiU7qhXvI3qbqLfguk1t9sTquvgPivNGPz2g2sg95W X7ssipUYM0eKUbuE8Qv7iv0Sa96p/oiijUQ3SNoskAhty2+43toxdwpUiaVgypJdUm323q2N +QFYiZn7wdjQlgaN4E0Z6gSKw2GjkxyNEkBIDl6ciGaWrQAJqd+zVNjjfYtc0bXJ2lhE2i+t RI/+urML32Qr+iWBNspXAAAAAAAA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Kania@21:1/5 to All on Fri May 20 10:33:41 2022
    Here the messages we get using ldapsearch on one of the consumers: ---------------
    ldapsearch -H ldaps://ldap.example.net
    SASL/GSSAPI authentication started
    ldap_sasl_interactive_bind: Invalid credentials (49)
    additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context


    $ klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: search-repl@

    Valid starting Expires Service principal
    05/20/2022 09:46:35 05/20/2022 19:46:35 krbtgt/DE@DE
    renew until 05/21/2022 09:46:35
    05/20/2022 09:46:50 05/20/2022 19:46:35 ldap/consumer01@DE
    renew until 05/21/2022 09:46:35
    05/20/2022 09:47:07 05/20/2022 19:46:35 ldap/ldap1@DE
    renew until 05/21/2022 09:46:35
    05/20/2022 09:47:24 05/20/2022 19:46:35 ldap/ldap@DE
    renew until 05/21/2022 09:46:35

    ---------------
    As you can see we get the ticket for ldap.

    Stefan

    Am 20.05.22 um 09:41 schrieb Stefan Kania:
    Hi to all,

    we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
    securing the replication via kerberos, everything works fine between the providers. But now we want to set up some consumers. Between the
    providers and the consumers a loadbalancer is located, so the consumers
    only connect to the loadbalancer and the loadbalancer chooses one of the providers. For the replication we put the fqdn from the loadbalancer
    into the configuration. The fqdn is ldap.example.net. We then created a host-principal and a service-principal for ldap.example.net and we put
    the host-key into /etc/krb5.keytab of all ldap-providers the same with
    the service-key. So now all provider can use both, the own keys and the
    keys from the loadbalancer. But it's not working :-(. In the log of the provider we see that the consumer connects. ldaps is working. But
    kerberos failed with the following messages:
    --------------------
    SASL [conn=5032] Failure: GSSAPI Error: Miscellaneous failure (see
    text) (Decrypt integrity check failed for checksum type
    hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96)

    slapd[59382]: conn=5032 op=0 RESULT tag=97 err=49 qtime=0.000028 etime=0.017274 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

    --------------------
    The same user we are using works without using the loadbalancer. If our solution is wrong, what would be the right way to use a loadbalancer
    together with kerberos?

    Stefan




    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos





    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CdEwggSUMIIDfKADAgECAghoLCY2SG4frzANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJE RTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJI MSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBOMB4XDTIxMTAwMzE0MzMwM1oX DTIyMTAwMzE0MzMwM1owbjELMAkGA1UEBhMCREUxITAfBgNVBAUTGDQwMDAwMDAwNjE1OWMx N2QyYmZjMTAyYzEVMBMGA1UEAwwMU3RlZmFuIEthbmlhMSUwIwYJKoZIhvcNAQkBFhZzdGVm YW5Aa2FuaWEtb25saW5lLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4L6 +t8YsmErxzkeCgfmXRrQQEHJQyZQxYPObVLOqodpHjkmMnYHYjplhHyxcAaJKNuCoAv941t1 iH1Lu12yOQS2yRE7xNAcoPx/acnZo5M7dAJOJ8JTmTYFbKkNGSNT7PJpA1xrxjuIRgXnEg/N 1nDKaSRIDrMyjDdUsa/mFKi1fp8/CvDIg/oL0Z0FuB6BsZHnshP+leRSjEDARmhkC8ifiDKo EMqiLVU1CqHgidRWM/aPYKpJ8zOQCUvZsIID4Vy393nJytuCBAUz9jCuDXwaFI7x2+yhg2VZ qZgURJlwwwgXk7DUCtXV5Jm8fyJQQT41MEb+IBVTqW+lEx+qkwIDAQABo4IBPDCCATgwHQYD VR0OBBYEFN3Lma+ERE52zn+UO6mQL8KOfmWpMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU 6caT0dUPBmRy6mqWProQ8lRUsnkwVgYDVR0gBE8wTTBLBgwrBgEEAfsrAgEDAggwOzA5Bggr BgEFBQcCARYtaHR0cDovL3NlYzUuZGduc2VydmljZS5kZS9wb2xpY2llcy9pbmRleC5odG1s MD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9zZWM1LmRnbnNlcnZpY2UuZGUvY3JsL2NybDIt dHlwZS1lLmNybDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnN0ZWZhbkBrYW5pYS1vbmxpbmUuZGUwDQYJKoZIhvcNAQELBQAD ggEBAM4bjRa/F8JdiKUN4vUmR/T/+JgCfYWpIhZM/4G6otEeQH/3yZSjsSw6KakUGlUzrhga B2bLyqjGwa7AjpwfuipQy0PRuKxZm5Lk7DDa3iIY4vqftpC2F5YMyb7yW2fLAOsnW3U4z44L cyKOuThoyXtrK4klUuqg0PjCDRhPlsjB/E+ITF1Jb0zRFY55flsoaCey1Cghpe7yTqxaWbSG MR8r10FYGbBDy7j/kXbKGYm9e2fX2SitrDeZrjtTkvraFdNrnWx4BGyYEzflTfkOFZQGLRPD pRjkzsxZ8Lf/Ew3tEUEdk41ACOo+r8GM4riMms7zhn6hJxEQF3KIp8NxFT0wggU1MIIEHaAD AgECAghVHErXZq0l9jANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJERTEzMDEGA1UECgwq REdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJIMR0wGwYDVQQDDBRk Z25zZXJ2aWNlIFJvb3QgNzpQTjAeFw0xNjEwMjYwOTIyNDFaFw0yNDEwMjYwOTIyNDFaMGYx CzAJBgNVBAYTAkRFMTMwMQYDVQQKDCpER04gRGV1dHNjaGVzIEdlc3VuZGhlaXRzbmV0eiBT ZXJ2aWNlIEdtYkgxIjAgBgNVBAMMGWRnbnNlcnZpY2UgQ0EgMiBUeXBlIEU6UE4wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcpfKUP3THo0fSl2bOa6PNbRcDYZaE4ZV3vLGr e/U445OsRahORPeP/9L4nycTK6fUawpDTqOaDxtXYxjoJNC9LnKRxVB/UkBf0h25vN0L1iV4 KhCaY8TimV0z2yUSlb2NuZ4gdBU69qJkasqYj+AP8OcQOo0idj9Nr1eloHD32i0JDPkhBj8V f6c6b7mNyn8yfZYvZlzzV2iQ/cvo6iFLx2wgG7mCkOZ8BAHGDFw6T0UIA0Bk60YhRMRxI7GX jMxBQA2Y/XXoP4dvQDDtMNmK0r5DUXof87w2brXctuQ2b4xNwFIErVoAQu8ftnXTm9iOtaOs WyLMZX6v5szaQBqBAgMBAAGjggHqMIIB5jASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQY MBaAFAEMFht0ctM8FO4md7dJFFPY+4sbMFsGCCsGAQUFBwEBBE8wTTBLBggrBgEFBQcwAYY/ aHR0cDovL3JvY3NwLWRnbi5kZ25zZXJ2aWNlLmRlOjgwODAvZWpiY2EvcHVibGljd2ViL3N0 YXR1cy9vY3NwMGoGA1UdIARjMGEwXwYMKwYBBAH7KwIBBAIBME8wTQYIKwYBBQUHAgEWQWh0 dHA6Ly93d3cuZGduc2VydmljZS5kZS90cnVzdGNlbnRlci9wdWJsaWMvZGduc2VydmljZS9p bmRleC5odG1sMIGZBgNVHR8EgZEwgY4wgYuggYiggYWGgYJsZGFwOi8vbGRhcC5kZ25zZXJ2 aWNlLmRlOjM4OS9DTj1DUkwtMSxPPURHTiUyMFNlcnZpY2UlMjBHbWJILEM9REU/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50MB0GA1UdDgQWBBTpxpPR1Q8GZHLqapY+uhDyVFSyeTAOBgNVHQ8BAf8EBAMCAQYwGwYJ KwYBBAHAbQMFBA4wDAYKKwYBBAHAbQMFATANBgkqhkiG9w0BAQsFAAOCAQEAq7w5+kXJ+/xT at0jiTX4GDX5HUeQohqAuLGfotHcqQqqjF8G6UUI0q4i0tnhHtldhZrNBOErgThGsToNZ1Y2 Gn0FRrcrUU9LnhSMwd1XJ0Je6ERSdEh4vXf8YxJQGZJPCPJcrblhue0mmwO9nbhKewGglht5 VWSHTS8vq5Da3zbxFG6lIdE62V4KqcMAiyY2BfL8guCPscTWl5txJrjb4ENo9nRqdzsXNEG3 yyzgmyv6znQ4pGgTe5E6qXx5bO6XCDoUK4Kz1S82PzR6hvcxKZo7kKK2ut2B3buwU8xqfw73 EMH8imv4LW/Sx59wKElKjijjHdNrFG/wMRobDYzMyTGCA4IwggN+AgEBMHIwZjELMAkGA1UE BhMCREUxMzAxBgNVBAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2Ug R21iSDEiMCAGA1UEAwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wDQYJ YIZIAWUDBAIBBQCgggHhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTIyMDUyMDA4MzM0MVowLwYJKoZIhvcNAQkEMSIEIDdpmB18F605NrKFBJGGwvikLYUD gN4/bxytb3S8sBaMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYEGCSsGAQQBgjcQBDF0MHIwZjELMAkGA1UEBhMCREUxMzAxBgNV BAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2UgR21iSDEiMCAGA1UE AwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wgYMGCyqGSIb3DQEJEAIL MXSgcjBmMQswCQYDVQQGEwJERTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0 c25ldHogU2VydmljZSBHbWJIMSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBO AghoLCY2SG4frzANBgkqhkiG9w0BAQEFAASCAQBpUsGd2MoH6e4N2L/hXdjKeeeByPyY9xjO HIUUIXxqIL3HgIhZgTwGfG3ZzQbgczHxQirn1ZuO7ckpD0d5stHn9GEJkLsZpg3Ws9JN7X3I bZuBAJtn1DjZuhoueGN40mrTuKtOqx0iKAezkSIi9zZPLPZhk7xzTEy5oxQixYzxfA8uNd00 trGBBgawV9lYN1uO2oRYdEwlzA6eoezuLQjJR9o97aOQxfUuEGf+3A32vVBiyYQt/9WBL8FV KRvfN5aLWNJzcUxM07ED7ESyePdM/8wFF0XnG6GbNXgRxBBRFq09DhUNj7tvjoaS0FoZtqye BsFef20hyLhcRxd4qATDAAAAAAAA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Russ Allbery@21:1/5 to Stefan Kania on Fri May 20 09:45:07 2022
    Copy: kerberos@mit.edu

    Stefan Kania <stefan@kania-online.de> writes:

    we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
    securing the replication via kerberos, everything works fine between the providers. But now we want to set up some consumers. Between the
    providers and the consumers a loadbalancer is located, so the consumers
    only connect to the loadbalancer and the loadbalancer chooses one of the providers. For the replication we put the fqdn from the loadbalancer
    into the configuration. The fqdn is ldap.example.net. We then created a host-principal and a service-principal for ldap.example.net and we put
    the host-key into /etc/krb5.keytab of all ldap-providers the same with
    the service-key. So now all provider can use both, the own keys and the
    keys from the loadbalancer. But it's not working :-(.

    Two things to check:

    First, how did you put the service kep for ldap/ldap.example.net onto each host? If you used ktadd via kadmin, you alas did not do that. Each time
    you downloaded the keytab entry, ktadd randomized the key again, so only
    the last host on which you put the key has a correct key and all of the
    rest have incorrect keys.

    You have to either manually copy the keytab file between hosts without
    running ktadd again, or somehow use -norandkey to generate the keytab
    entry.

    If that's not the problem, it used to be that you had to apply a one-line
    patch to Cyrus SASL to prevent it from forcing Kerberos to only use the
    keytab entry that it thought corresponded to the local hostname, which otherwise would prevent this trick from working. I thought Cyrus SASL
    upstream had finally taken that patch and included it in a release, but
    maybe you're using an old version of Cyrus SASL? I don't remember what
    error message that used to produce, though, so maybe this is a different problem.

    --
    Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Kania@21:1/5 to Russ Allbery on Fri May 27 20:04:35 2022
    Copy: kerberos@mit.edu

    Hi Russ

    Am 20.05.22 um 18:45 schrieb Russ Allbery:
    Stefan Kania <stefan@kania-online.de> writes:

    we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
    securing the replication via kerberos, everything works fine between the
    providers. But now we want to set up some consumers. Between the
    providers and the consumers a loadbalancer is located, so the consumers
    only connect to the loadbalancer and the loadbalancer chooses one of the
    providers. For the replication we put the fqdn from the loadbalancer
    into the configuration. The fqdn is ldap.example.net. We then created a
    host-principal and a service-principal for ldap.example.net and we put
    the host-key into /etc/krb5.keytab of all ldap-providers the same with
    the service-key. So now all provider can use both, the own keys and the
    keys from the loadbalancer. But it's not working :-(.

    Two things to check:

    First, how did you put the service kep for ldap/ldap.example.net onto each host? If you used ktadd via kadmin, you alas did not do that. Each time
    you downloaded the keytab entry, ktadd randomized the key again, so only
    the last host on which you put the key has a correct key and all of the
    rest have incorrect keys.
    We created one keytab for each host and each service. One ldap-key for
    each ldap(1..4).example.net and one for ldap.example.net We then put the
    key from ldap.example.net to all ldap(1..4).keytab with ktutil. We
    checked the KVNO and everything is ok there. So no two different keys.

    You have to either manually copy the keytab file between hosts without running ktadd again, or somehow use -norandkey to generate the keytab
    entry.

    If that's not the problem, it used to be that you had to apply a one-line patch to Cyrus SASL to prevent it from forcing Kerberos to only use the keytab entry that it thought corresponded to the local hostname, which otherwise would prevent this trick from working. I thought Cyrus SASL upstream had finally taken that patch and included it in a release, but
    maybe you're using an old version of Cyrus SASL? I don't remember what
    error message that used to produce, though, so maybe this is a different problem.
    We use debian 11 and the packages from Debian. Do you have some more information about the patch?


    We use use "Layer 4 Load Balancing Direct Server Return Mode" on the loadbalancer. So now NAT. So only the MAC-address is changed on the loadbalancer. The consumer is only talking to ldap.example.net, the loadbalancer.


    MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CdEwggSUMIIDfKADAgECAghoLCY2SG4frzANBgkqhkiG9w0BAQsFADBmMQswCQYDVQQGEwJE RTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJI MSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBOMB4XDTIxMTAwMzE0MzMwM1oX DTIyMTAwMzE0MzMwM1owbjELMAkGA1UEBhMCREUxITAfBgNVBAUTGDQwMDAwMDAwNjE1OWMx N2QyYmZjMTAyYzEVMBMGA1UEAwwMU3RlZmFuIEthbmlhMSUwIwYJKoZIhvcNAQkBFhZzdGVm YW5Aa2FuaWEtb25saW5lLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4L6 +t8YsmErxzkeCgfmXRrQQEHJQyZQxYPObVLOqodpHjkmMnYHYjplhHyxcAaJKNuCoAv941t1 iH1Lu12yOQS2yRE7xNAcoPx/acnZo5M7dAJOJ8JTmTYFbKkNGSNT7PJpA1xrxjuIRgXnEg/N 1nDKaSRIDrMyjDdUsa/mFKi1fp8/CvDIg/oL0Z0FuB6BsZHnshP+leRSjEDARmhkC8ifiDKo EMqiLVU1CqHgidRWM/aPYKpJ8zOQCUvZsIID4Vy393nJytuCBAUz9jCuDXwaFI7x2+yhg2VZ qZgURJlwwwgXk7DUCtXV5Jm8fyJQQT41MEb+IBVTqW+lEx+qkwIDAQABo4IBPDCCATgwHQYD VR0OBBYEFN3Lma+ERE52zn+UO6mQL8KOfmWpMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU 6caT0dUPBmRy6mqWProQ8lRUsnkwVgYDVR0gBE8wTTBLBgwrBgEEAfsrAgEDAggwOzA5Bggr BgEFBQcCARYtaHR0cDovL3NlYzUuZGduc2VydmljZS5kZS9wb2xpY2llcy9pbmRleC5odG1s MD4GA1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly9zZWM1LmRnbnNlcnZpY2UuZGUvY3JsL2NybDIt dHlwZS1lLmNybDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMCEGA1UdEQQaMBiBFnN0ZWZhbkBrYW5pYS1vbmxpbmUuZGUwDQYJKoZIhvcNAQELBQAD ggEBAM4bjRa/F8JdiKUN4vUmR/T/+JgCfYWpIhZM/4G6otEeQH/3yZSjsSw6KakUGlUzrhga B2bLyqjGwa7AjpwfuipQy0PRuKxZm5Lk7DDa3iIY4vqftpC2F5YMyb7yW2fLAOsnW3U4z44L cyKOuThoyXtrK4klUuqg0PjCDRhPlsjB/E+ITF1Jb0zRFY55flsoaCey1Cghpe7yTqxaWbSG MR8r10FYGbBDy7j/kXbKGYm9e2fX2SitrDeZrjtTkvraFdNrnWx4BGyYEzflTfkOFZQGLRPD pRjkzsxZ8Lf/Ew3tEUEdk41ACOo+r8GM4riMms7zhn6hJxEQF3KIp8NxFT0wggU1MIIEHaAD AgECAghVHErXZq0l9jANBgkqhkiG9w0BAQsFADBhMQswCQYDVQQGEwJERTEzMDEGA1UECgwq REdOIERldXRzY2hlcyBHZXN1bmRoZWl0c25ldHogU2VydmljZSBHbWJIMR0wGwYDVQQDDBRk Z25zZXJ2aWNlIFJvb3QgNzpQTjAeFw0xNjEwMjYwOTIyNDFaFw0yNDEwMjYwOTIyNDFaMGYx CzAJBgNVBAYTAkRFMTMwMQYDVQQKDCpER04gRGV1dHNjaGVzIEdlc3VuZGhlaXRzbmV0eiBT ZXJ2aWNlIEdtYkgxIjAgBgNVBAMMGWRnbnNlcnZpY2UgQ0EgMiBUeXBlIEU6UE4wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcpfKUP3THo0fSl2bOa6PNbRcDYZaE4ZV3vLGr e/U445OsRahORPeP/9L4nycTK6fUawpDTqOaDxtXYxjoJNC9LnKRxVB/UkBf0h25vN0L1iV4 KhCaY8TimV0z2yUSlb2NuZ4gdBU69qJkasqYj+AP8OcQOo0idj9Nr1eloHD32i0JDPkhBj8V f6c6b7mNyn8yfZYvZlzzV2iQ/cvo6iFLx2wgG7mCkOZ8BAHGDFw6T0UIA0Bk60YhRMRxI7GX jMxBQA2Y/XXoP4dvQDDtMNmK0r5DUXof87w2brXctuQ2b4xNwFIErVoAQu8ftnXTm9iOtaOs WyLMZX6v5szaQBqBAgMBAAGjggHqMIIB5jASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQY MBaAFAEMFht0ctM8FO4md7dJFFPY+4sbMFsGCCsGAQUFBwEBBE8wTTBLBggrBgEFBQcwAYY/ aHR0cDovL3JvY3NwLWRnbi5kZ25zZXJ2aWNlLmRlOjgwODAvZWpiY2EvcHVibGljd2ViL3N0 YXR1cy9vY3NwMGoGA1UdIARjMGEwXwYMKwYBBAH7KwIBBAIBME8wTQYIKwYBBQUHAgEWQWh0 dHA6Ly93d3cuZGduc2VydmljZS5kZS90cnVzdGNlbnRlci9wdWJsaWMvZGduc2VydmljZS9p bmRleC5odG1sMIGZBgNVHR8EgZEwgY4wgYuggYiggYWGgYJsZGFwOi8vbGRhcC5kZ25zZXJ2 aWNlLmRlOjM4OS9DTj1DUkwtMSxPPURHTiUyMFNlcnZpY2UlMjBHbWJILEM9REU/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50MB0GA1UdDgQWBBTpxpPR1Q8GZHLqapY+uhDyVFSyeTAOBgNVHQ8BAf8EBAMCAQYwGwYJ KwYBBAHAbQMFBA4wDAYKKwYBBAHAbQMFATANBgkqhkiG9w0BAQsFAAOCAQEAq7w5+kXJ+/xT at0jiTX4GDX5HUeQohqAuLGfotHcqQqqjF8G6UUI0q4i0tnhHtldhZrNBOErgThGsToNZ1Y2 Gn0FRrcrUU9LnhSMwd1XJ0Je6ERSdEh4vXf8YxJQGZJPCPJcrblhue0mmwO9nbhKewGglht5 VWSHTS8vq5Da3zbxFG6lIdE62V4KqcMAiyY2BfL8guCPscTWl5txJrjb4ENo9nRqdzsXNEG3 yyzgmyv6znQ4pGgTe5E6qXx5bO6XCDoUK4Kz1S82PzR6hvcxKZo7kKK2ut2B3buwU8xqfw73 EMH8imv4LW/Sx59wKElKjijjHdNrFG/wMRobDYzMyTGCA4IwggN+AgEBMHIwZjELMAkGA1UE BhMCREUxMzAxBgNVBAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2Ug R21iSDEiMCAGA1UEAwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wDQYJ YIZIAWUDBAIBBQCgggHhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTIyMDUyNzE4MDQzNVowLwYJKoZIhvcNAQkEMSIEIBV3DPb2fDbf48C6Ut0ZKlxG11zc RY5+qWkHhMnv8FozMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYEGCSsGAQQBgjcQBDF0MHIwZjELMAkGA1UEBhMCREUxMzAxBgNV BAoMKkRHTiBEZXV0c2NoZXMgR2VzdW5kaGVpdHNuZXR6IFNlcnZpY2UgR21iSDEiMCAGA1UE AwwZZGduc2VydmljZSBDQSAyIFR5cGUgRTpQTgIIaCwmNkhuH68wgYMGCyqGSIb3DQEJEAIL MXSgcjBmMQswCQYDVQQGEwJERTEzMDEGA1UECgwqREdOIERldXRzY2hlcyBHZXN1bmRoZWl0 c25ldHogU2VydmljZSBHbWJIMSIwIAYDVQQDDBlkZ25zZXJ2aWNlIENBIDIgVHlwZSBFOlBO AghoLCY2SG4frzANBgkqhkiG9w0BAQEFAASCAQAIQob0Mk+6tRf2+Lvq0g/BkyoaHEpvIKMW 7Pw9ArcH2j/0cAPzeCqchdTVoflhLqqaLqxqFxUA6pc5FNt1JqlXvmI3qS6+owQ1NYQY/PYZ od3hx0NJYnf86xkByp0kIUNsnGPeywS7/zQoNh2RMh6GH7tFJ/90eN918YXgVQPNiF8ueyOv CC4c3P6LVXuWidDnit3kUOO7Sa/46VlZMnmzyBO7tL5zT2YLLONzv0jxRBsj6RCfY0r9Bf/h V+AfWBlsNS7T2ACj+lHbrcd9liFslzSLQgc6lI9BRgJDgDrRNJiLDr73uaydf/Denr+zUCcE 71JzJblvWd1nFy4I7Dr5AAAAAAAA

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