I'm running a Kerberos / LDAP authentication server for many years. Kerberos data is stored inside LDAP. Now, I have a second site and want to mirror the server to the new site. This basically works, but there is a strange side effect. Each server has a KDC and a LDAP running. KDC talks to LDAP using local ldapi:///.
If I use the original KDC krb1.example.com I can authenticate to the master LDAP and the replica. If I use the replicated KDC krb2.example.com, I can still authenticate to the master LDAP, but trying the replica I get
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)Which is strange, since krb2 is literally a clone on the LXC container krb1 i.e. the configurations are identical safe for the changes required for replication. But still more puzzeling is a look into the ticket caches after trying to query either LDAP server. With a TGT from krb1
root@krb2:/# klist -e
Ticket cache: FILE:/tmp/krb5_cc_0.tkt
Default principal: [email protected]
Valid starting Expires Service principal
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/[email protected]
renew until 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
04.02.2022 01:05:42 04.02.2022 11:05:29 ldap/[email protected]
renew until 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
04.02.2022 01:05:53 04.02.2022 11:05:29 ldap/[email protected]
renew until 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96and from krb2:
root@krb2:/# klist -e
Ticket cache: FILE:/tmp/krb5_cc_0.tkt
Default principal: [email protected]
Valid starting Expires Service principal
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/[email protected]
renew until 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
04.02.2022 00:53:47 04.02.2022 10:53:45 ldap/[email protected]
renew until 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96which has no entry for ldap/krb2.example.com due to the error. But apparently there is no difference in the encryption types required. So, why does it complain?
Currently both LDAP servers refer to krb1. But due to the LDAP replication all keys should be identical i.e. a key from krb1 should be the same as from krb2, shouldn't it? And if keys from krb1 work for both LDAP servers, why does the key from the replica server only work for the master LDAP?
supported_enctypes for the realm in both /etc/krb5kdc/kdc.conf are supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3. There are no enctype directives in either /etc/krb5.conf. There are no ssf configuration used in either LDAP. The krbPrincipalName entries for krb2 exist in both LDAP.
Even if I obtain the TGT from krb2 and then switch the krb5.conf to krb1 for the service ticket, I can authenticate to LDAP on krb2.
OpenLDAP is in version 2.4.47, Kerberos 1.17 on both machines (current Debian stable).
Update: It turned out that replication is incomplete i.e., krbPrincipalKey is not (reliably) replicated. I checked the slapd debugging output:
Feb 9 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND authcid="sync/[email protected]" authzid="dn:uid=sync/krb2.example.com,cn=example.com,cn=gssapi,[email protected]"
Feb 9 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND dn="cn=admin,dc=example,dc=com" mech=GSSAPI sasl_ssf=256 ssf=256
So, synprov apparently binds as cn=admin,dc=example,dc=com, which is intended.However, if I do
root@krb1:~# ldapsearch -b 'cn=KERBEROS,dc=example,dc=com' -D 'cn=admin,dc=example,dc=com' -Wx 'krbPrincipalName=ldap/[email protected]'
then I see krbPrincipalKey. So why doesn't it get replicated?
I restart slapd on krb2 with options -c rid=1,csn=0, which I understood should sync the entire database. But since some entries have a key and some don't, I do not trust that this is true.
