Univention Bugzilla – Bug 41938
Moving users to non-readable location confuses AD-Connector
Last modified: 2016-09-21 20:28:31 CEST
Created attachment 7861 [details] excerpt from connector.log at debug level 3 This is most probably related to S4-Connector Bug 32542 and/or Bug 41884, but affects the AD-Connector. 1) create 2 OUs (e.g. gsmitte and gsnord) 2) create at least one user in gsmitte 3) install and configure univention-ad-connector on school server gsmitte 4) move the user via import script from gsmitte to gsnord. 5) check connector.log of school server for gsmitte (the server should have NO read access for gsnord) See attached log file with debug level 3. Instead of running the function "group_members_sync_from_ucs", the AD-Connector decides to do this: > move group from uid=mary,cn=schueler,cn=users,ou=tgbbz,dc=schule,dc=example,dc=org] to [cn=tgbbz-11a,cn=klassen,cn=schueler,cn=groups,ou=tgbbz,DC=intern,DC=cabbages,DC=ad] ... and fails, because the group already exists. Please note: Installing univention-ad-connector on an UCS Slave is done as a customer implementation.
Created attachment 7898 [details] bug41938.patch I've merged the S4-Connector patches mentioned by Michael to apply to the ad-connector.py listener module but the resulting behavior is still untested.
(In reply to Arvid Requate from comment #1) > Created attachment 7898 [details] > bug41938.patch > > I've merged the S4-Connector patches mentioned by Michael to apply to the > ad-connector.py listener module but the resulting behavior is still untested. Thanks, the patch works. UCS 4.1-3: r72543 UCS 4.2: r72544 YAML: r72545
UCS 4.1-3 with new ad-connector (1) disabled access to subtree cn=ignore... for Administrator in slapd.conf access to dn.subtree="cn=ignore,dc=four,dc=test" by dn.base="uid=Administrator,cn=users,dc=four,dc=test" none by * +0 break (2) changed binddn from cn=admin... to uid=Administrator... in /etc/service/univention-directory-listener/run (3) create normal user account move user to cn=ignore change description of some object (to trigger a normal change after the modrdn) I get "14.09.16 13:47:57.695 LISTENER ( ERROR ) : The entryUUID attribute of the saved object (uid=test8,dc=four,dc=test) does not match the entryUUID attribute of the current object (dc=four,dc=test). This can be normal in a selective replication scenario. 14.09.16 13:47:57.697 LISTENER ( ERROR ) : rm old object " in the listener log. That is OK, the listener sees the 'r' for the user object, but not the 'a' (modrdn is 'r' + 'a'), the next change does not correspond to the current "old_dn" object (where the modrdn objects are stored) and is ignored. Move from a readable container into another readable container still works as expected (modrdn in listener -> modify in connector). OK - jenkins OK - merged to 4.2-0 OK - yaml
<http://errata.software-univention.de/ucs/4.1/267.html>