Univention Bugzilla – Full Text Bug Listing |
Summary: | S4-Connector rejects for CN=Machine/CN=User due to CN=MachineStaging/CN=UserStaging | ||
---|---|---|---|
Product: | UCS | Reporter: | Arvid Requate <requate> |
Component: | S4 Connector | Assignee: | Samba maintainers <samba-maintainers> |
Status: | RESOLVED WONTFIX | QA Contact: | Samba maintainers <samba-maintainers> |
Severity: | normal | ||
Priority: | P5 | CC: | stoeckigt |
Version: | UCS 4.3 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: |
https://forge.univention.org/bugzilla/show_bug.cgi?id=45327 https://forge.univention.org/bugzilla/show_bug.cgi?id=49931 |
||
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?: | 2: Will only affect a few installed domains | How will those affected feel about the bug?: | 2: A Pain – users won’t like this once they notice it |
User Pain: | 0.069 | Enterprise Customer affected?: | |
School Customer affected?: | Yes | ISV affected?: | |
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | 2019050721000314 | Bug group (optional): | |
Max CVSS v3 score: |
Description
Arvid Requate
2019-05-16 17:35:47 CEST
tl;dr: Try putting CN=MachineStaging and CN=UserStaging on the ignorelist. Details: Using the LDAP search with notification control ( https://help.univention.com/t/q-a-how-to-use-samba-ad-controls-to-work-with-notifications/10115 ) I was able to trace the origin of these temporary containers. The Group Policy Management Console (GPMC) creates them when you restore a GPO from backup. This is the order of LDAP changes as they happen, pretty straight forward: =========================================== # record 1 dn: CN=UserStaging,CN={GPOGUID},... changetype: add # record 2 dn: CN=MachineStaging,CN={GPOGUID},... changetype: add # record 3 dn: CN=User,CN={GPOGUID},... changetype: modrdn newrdn: CN=UserOld deleteoldrdn: 1 # record 4 dn: CN=Machine,CN={GPOGUID},... changetype: modrdn newrdn: CN=MachineOld deleteoldrdn: 1 # record 5 dn: CN=UserStaging,CN={GPOGUID},... changetype: modrdn newrdn: CN=User deleteoldrdn: 1 # record 6 dn: CN=MachineStaging,CN={GPOGUID},... changetype: modrdn newrdn: CN=Machine deleteoldrdn: 1 # record 7 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 6 # record 8 dn: CN=UserOld,CN={GPOGUID},... changetype: modrdn newrdn: CN=UserOld\0ADEL:... deleteoldrdn: 1 # record 9 dn: CN=MachineOld,CN={GPOGUID},... changetype: modrdn newrdn: CN=MachineOld\0ADEL:... deleteoldrdn: 1 # record 10 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 196614 # record 10 dn: CN={GPOGUID},... changetype: modify replace: versionNumber versionNumber: 196617 =========================================== From that I think we could safely try putting CN=MachineStaging on the ignorelist, but we should probably not put CN=MachineOld on it too, because the S4-Connector would probably treat the modrdn operations in record 3&4 as a deletes which could be dangerous if the S4-Connector echos that delete back to Samba/AD. We may have a recipie against that by using the LDAP Post Read control (Bug #43628 / Bug #48988), but that would probably require an invasive code change in the S4-Connector. This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you. |