Univention Bugzilla – Bug 43093
AD-Member: Password-hash read does not work when msDS-ReplicationEpoch is set
Last modified: 2021-07-28 12:38:09 CEST
I found this behavior in an environment with the following specifications: - Windows 2k8 AD-Master - UCS 4.1-4 Membermode (syncmode: read) Then, somehow the customer installed Samba/AD (with univention-s4-connector) Replication from MS-AD > OpenLDAP > Samba-AD works just fine, but: - univention-connector-list-rejected shows >500 'AD rejected' (in sync read?!) - connector.log show for nearly each of this rejects 'RuntimeError: (8593, 'WERR_DS_DIFFERENT_REPL_EPOCHS') for more info see ticket#...274 Ok, I know this situation is not strictly recommended, but: The traceback in connector.log indicates a problem fetching the ntlm password hash from MS-AD: ============================================================================ 01.12.2016 11:45:49,557 LDAP (PROCESS): sync to ucs: [ user] [ modify] uid=horst,cn=users,dc=domain,dc=tld 01.12.2016 11:45:49,566 LDAP (ERROR ): failed in post_con_modify_functions 01.12.2016 11:45:49,566 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/connector/__init__.py", line 1309, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.7/univention/connector/ad/password.py", line 383, in password_sync res = get_password_from_ad(connector, univention.connector.ad.compatible_modstring(object['dn'])) File "/usr/lib/pymodules/python2.7/univention/connector/ad/password.py", line 183, in get_password_from_ad (level, ctr) = connector.drs.DsGetNCChanges(connector.drsuapi_handle, 8, req8) RuntimeError: (8593, 'WERR_DS_DIFFERENT_REPL_EPOCHS') ============================================================================
additional info: at least one change - as far as I remember there were 2 or 3 changes - which had been replicated from MS-AD to LDAP as well as Samba-AD, before the given traceback occurs. This makes it even more obscure...
Created attachment 9761 [details] adjust_to_replication_epock.patch Something like this may be required. Untested. I just adjusted the code of drs_DSBind to expose the epoch and rebind with a matching value.
Ok, this actually works. I've prepared an epoch=2 MS AD 2008R2 by performing the rendom procedure and samba-tool drs bind against the AD DC confirms this. Then I installed AD connection on one of my UCS DC Masters and patched the AD-Connector as proposed in Comment 2. After setting up an SSL-secured bidirection replication the replication of password hashes from AD to UCS works: ============================================================================== 28.11.2018 17:47:39,327 LDAP (INFO ): get_password_from_ad: Read password from AD: cn=user3 last4,cn=users,DC=w2k8r2d3ar,DC=org 28.11.2018 17:47:39,339 LDAP (PROCESS): Adjusting to AD Replication Epoch: 1 28.11.2018 17:47:39,346 LDAP (INFO ): get_password_from_ad: Found unicodePwd blob ============================================================================== I also checked this with a UCS system in ad/member mode and switched on hash synchronization following https://help.univention.com/t/speed-up-ldap-binds-on-ad-member-mode-systems/41 (well, I resync'ed the users via resync_object_from_ad.py like in Bug 48231) After that the hashes are synchronized normally. Setting "patch available". PS: It would be better to adjust the drs_DsBind from samba drs_utils.py to 1. return the info structure, so we can check info.info.repl_epoch and 2. to support passing an epoch value to the function. This would avoid my ugly code duplication. Something like that would be required for Bug 38234 anyway.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
Still applies to 4.4 and should also apply to UCS 5. Patch worked. Added actual ticket number
Ups there is a new bug existing so I set back old status.