Univention Bugzilla – Bug 18479
Umbenennen einer Gruppe auf AD-Seite sorgt für Probleme
Last modified: 2019-01-03 07:19:41 CET
Habe Benutzer und Gruppe auf AD-Seite erzeugt und den Benutzer der Gruppe hinzugefügt. Ändere ich jetzt von der Gruppe das SamAccountName-Attribut (etwas anderes lässt die Windows-Oberfläche nicht zu, passiert aber gleichermaßen auch über ldap direkt), so gibt es im Connector folgende Exception: failed in post_con_modify_functions Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/univention/connector/__init__.py", line 1017, in sync_to_ucs f(self, property_type, object) File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 58, in group_members_sync_to_ucs return connector.group_members_sync_to_ucs(key, object) File "/usr/lib/python2.4/site-packages/univention/connector/ad/__init__.py", line 1298, in group_members_sync_to_ucs if ldap_object_ucs.has_key('uniqueMember'): AttributeError: 'NoneType' object has no attribute 'has_key' Anschließend ist der Benutzer auch nicht mehr Mitglied der Gruppe.
siehe auch ucs-test: scripts-72_ad-connector/72sync_ad_change_groupname
We will not ship a UCS 3.1-2 release; the next UCS release will be UCS 3.2. As such, this bug is moved to the new target milestone.
*** Bug 25111 has been marked as a duplicate of this bug. ***
Created attachment 9061 [details] 18479-adc-change-groupname-421.patch The problem boils down to an implicit move via the UDM module `groups/group`. On changing the AD `sAMAccountName`, the UDM `name` attribute is changed which translates into a change of the `cn` and therefore the DN. `group_members_sync_to_ucs()` retrieves the `ldap_object_ucs` by the old DN, which returns an `None` object. The attached patches fix the issue by storing the DN as returned by UDM's `modify()` in `object['dn']` and enables the test case. As `modify()` at this point returns the old DN, this is dependent on bug #41694.
(In reply to Lukas Oyen from comment #4) > Created attachment 9061 [details] > 18479-adc-change-groupname-421.patch The "if modified_dn:" is not necessary. object.modify() always returns the DN - if the object changes or not.
Created attachment 9062 [details] 18479-adc-change-groupname-421.patch Updated patch without the conditional. (@Florian: Even better, I did it to keep the logic of the old version.)
object.modify() returns the DN as bytestring. The AD connector has always unicode in object['dn']. I would wrap unicode() arround it.
object['olddn'] must be updated instead of object['dn'] if the DN comes from there.
(In reply to Florian Best from comment #8) > object['olddn'] must be updated instead of object['dn'] if the DN comes from > there. No. Here only the direction AD -> UCS is of interest. In case of a modify, olddn != dn signals a `modrdn` on the AD side. This bug is the case where a normal modification took place on the AD side and triggered a `modrdn` on the UCS side. `olddn` contains the DN pre-modrdn, `dn` contains the `dn` post-modrdn (modify). As we are in `modify_in_ucs()` the values of `olddn`/`dn` were mapped from AD DNs to UCS DNs. After `modify_in_ucs()` (or `move_in_ucs()`) only `dn` is of interest: the "new" DN after the modification in UCS.
Okay, thanks for clarifying that.
Code rebased on 4.2-2 in branch loyen/18479-adc-rename-groupname-422
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.