Bug 32082 - krb5 key version (kvno) not synchronous in Samba4 and OpenLDAP
krb5 key version (kvno) not synchronous in Samba4 and OpenLDAP
Status: NEW
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 5.0
Other Linux
: P5 normal with 5 votes (vote)
: ---
Assigned To: Samba maintainers
https://git.knut.univention.de/univen...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-25 14:50 CEST by Arvid Requate
Modified: 2021-05-07 10:38 CEST (History)
8 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 4: A User would return the product
User Pain: 0.206
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2016101421000118, 2016120821000501, 2019090521000856
Bug group (optional):
Max CVSS v3 score:


Attachments
s4connector_sync_to_ucs_KeyVersionNumber.patch (5.63 KB, patch)
2018-02-21 14:56 CET, Arvid Requate
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2013-07-25 14:50:42 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?
Comment 1 Arvid Requate univentionstaff 2014-02-12 20:04:07 CET
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.
Comment 2 Arvid Requate univentionstaff 2016-10-25 15:31:47 CEST
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.
Comment 3 Arvid Requate univentionstaff 2017-03-07 12:43:09 CET
Just fixed this again manually for 4 local memberservers.
Comment 4 Stefan Gohmann univentionstaff 2017-06-16 20:39:30 CEST
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.
Comment 5 Arvid Requate univentionstaff 2018-02-21 14:56:10 CET
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.