Univention Bugzilla – Bug 54829
Old primary group re-added by AD connector after moving user between schools by sisopi import
Last modified: 2024-01-17 14:15:40 CET
A customer used sisopi import to move users between schools. They also have the univention-ad-connector installed in sync mode. The sisopi import does the following to move a user between schools 1. moves user from ou=schoolA to ou=schoolB 2. removes user from old school groups 3. adds user to new school groups The listener is stopped during all this. A few hours later, when the ad-connector is done with all the changes, a lot of users are now "normal"(not primary) members of their old primary group. I tried to reproduce this using the sisopi-import with bi-directional ad-connector, but I had no luck yet.
The customer has this issue for a long time (years). We are still getting tickets, with failed imports, with the wrong memberships as root cause of this. The customer is not happy about this.
a few questions: * are we sure there is no process on AD side maintaining group memberships which causes the changes? * who is in lead for the group memberships, AD or UCS? * can the AD Connector be configured to sync group memberhips uni-directional in the project?
(In reply to Ingo Steuwer from comment #2) > a few questions: > > * are we sure there is no process on AD side maintaining group memberships > which causes the changes? This did not look like manual adjustments, these are a lot of students after the import moving them to the transfer school, but not all of them. Having rejects on the connector intensifies the number of users with group missmatches. > * who is in lead for the group memberships, AD or UCS? These are the ucr variables for the syncmode: con.*/ad/mapping/computer/syncmode: <empty> con.*/ad/mapping/container/syncmode: <empty> con.*/ad/mapping/group/syncmode: <empty> con.*/ad/mapping/ou/syncmode: <empty> con.*/ad/mapping/sync/userPrincipalName: <empty> con.*/ad/mapping/syncmode: <empty> con.*/ad/mapping/user/syncmode: <empty> con.*/ad/password/timestamp/syncreset/ad: <empty> con.*/ad/password/timestamp/syncreset/ucs: <empty> connector/ad/mapping/sync/userPrincipalName: false connector/ad/mapping/syncmode: sync connector/s4/mapping/group/syncmode: write Hope this answers the question? > * can the AD Connector be configured to sync group memberhips > uni-directional in the project? I will ask the customer, but this could only be a workaround. What I wonder, why the S4connector is always in write mode in @school for groups? I think there is a reason, maybe related?
Now I have an answer from the customer, we will try to set the unidirectional syncmode and report if this helps root@ucs:~# ucr set connector/ad/mapping/group/syncmode=write Create connector/ad/mapping/group/syncmode
I have a customer now, were the deleted students are not removed properly from their Primary Groups (domain users ou) The customer has only the s4 connector but here the group sync is set to sync, instead of write as we do normally in school. What I want to say, we have the same issue with the s4-connector if the group sync is in sync. Afaik, the ad-connector customer has no longer the problem, since the groupsync was set to write.