Univention Bugzilla – Full Text Bug Listing |
Summary: | Umbenennen einer Gruppe auf AD-Seite sorgt für Probleme | ||
---|---|---|---|
Product: | UCS | Reporter: | Daniel Hofmann <hofmann> |
Component: | AD Connector | Assignee: | Samba maintainers <samba-maintainers> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | best, botner, gohmann, oyen |
Version: | UCS 4.1 | Flags: | oyen:
Patch_Available+
|
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Linux | ||
What kind of report is it?: | Bug Report | What type of bug is this?: | 5: Major Usability: Impairs usability in key scenarios |
Who will be affected by this bug?: | 2: Will only affect a few installed domains | How will those affected feel about the bug?: | 3: A User would likely not purchase the product |
User Pain: | 0.171 | Enterprise Customer affected?: | |
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | Bug group (optional): | ||
Max CVSS v3 score: | |||
Bug Depends on: | 41694 | ||
Bug Blocks: | |||
Attachments: |
18479-adc-change-groupname-421.patch
18479-adc-change-groupname-421.patch |
Description
Daniel Hofmann
2010-05-25 12:58:27 CEST
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. |