Univention Bugzilla – Bug 32082
krb5 key version (kvno) not synchronous in Samba4 and OpenLDAP
Last modified: 2021-05-07 10:38:31 CEST
krb5KeyVersionNumber and msDS-KeyVersionNumber can differ in OpenLDAP and Samba4. This can cause kerberos authentication problems in the interoperation of Samba4 and non-Samba4 systems. E.g. in an UCS@school test setup we had a Slave PDC showing krb5KeyVersionNumber=3 in OpenLDAP directly after the initial Samba4 installation via UCS@school wizard, while Samba4 showed msDS-KeyVersionNumber=1. A user logged into an UCC system tried to establish an ssh-connection to the Slave and this failed due to the setting of kerberos/kdc=<master-fqdn> in the current UCC development version, because the service-ticket issued bei the master KDC showed kvno 3 for the host/slave@REALM principal, which did not match any kvno listed in the slaves krb5.keytab (showing only kvno = 1). The UCC system was joined to the Slave, but this probably does not matter. Two experimental attempts were made to confirm or fix this issue: 1) manual change of msDS-KeyVersionNumber to 3 in secrets.ldb fixed this issue. (But sam.ldb would have to be changed as well to avoid other problems). 2) server_password_change increases msDS-KeyVersionNumber to 2, but also increases krb5KeyVersionNumber to 4. May hope would have been that the S4-Connector overwrites the krb5KeyVersionNumber, but apparantly for server_password_change we first change the password in udm (-> kvno = 4) and then, shortly afterwards we set it in samba4 via "samba-tool user". Probably the Connector then compares the hashes, finds them to be identical and stopps rpocessing password related attributes. I guess the Connector should always sync the kvno from S4 to UCS. This might be sufficient to ensure consistency?
From an experiment it looks like it's possible to synchronize this back into the Samba directory service, but it's pretty low level and we would have to take care of the attribute USNs (local and originating) manually. So it's a bit more low level than synchronizing the kerberos keys. I operated with python-ldb directly on the sam.ldb but the S4 Connector can probably do the same with his way of access to the SAM database. I guess, before going down this road, we should identify the origins of this issue and see if we can't avoid them. So, in case this happens again and someone can provide proof of the issue please provide detailed exact data of the circumstances as well.
This issue periodically causes Kerberos to fail on Memberservers, and in the case of Ticket 2016101421000118 it seems to have caused massive performance issues on the fileserver. We need to make the S4-Connector synchronize the Kerberos key version number at least from Samba/AD to OpenLDAP. In UCS Samba/AD Domains the Samba KDC is the leading authority, so the key versions it finds in it's backend need to match the ones on the clients.
Just fixed this again manually for 4 local memberservers.
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Created attachment 9405 [details] s4connector_sync_to_ucs_KeyVersionNumber.patch This patch lets the S4-Connector synchronize the Kerberos KeyVersionNumber from Samba/AD to OpenLDAP. Unidirectional. Please note that this only causes this integer valued attribute to be synchronized too. The same integer is part of the krb5Key and supplementalCredentials, which gets synchronized anyway. Please also note that this doesn't improve the situation in UCS@school, but should also not make it worse. Especially there should occur no replication ping-pong between the S4-Connectors on the School Slaves and the S4-Connector in the central school department -- because this synchronization is unidirectional.