Bug 52159 - Group synchronisation is not triggered, if a user is reactivated
Group synchronisation is not triggered, if a user is reactivated
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Office 365
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Felix Botner
Erik Damrose
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-09-29 16:14 CEST by Christina Scheinig
Modified: 2021-01-11 12:50 CET (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2020081821000232
Bug group (optional):
Max CVSS v3 score:


Attachments
304_membership_after_deactivation_reactivation (5.08 KB, text/plain)
2020-11-25 10:13 CET, Felix Botner
Details
office365-user.py.patch (1.04 KB, patch)
2020-11-25 10:17 CET, Felix Botner
Details | Diff
proposed patch (1.16 KB, patch)
2020-12-08 10:35 CET, Erik Damrose
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2020-09-29 16:14:12 CEST
In a customer environment, the group sync is activated for office 365. In some scenarios a user is deactivated and moved and reactivated again. The connection to azure is therefor removed from the user for this time and reactivated again.
The user is synchronized to azure again, but the group synchronization is not triggered, if the groups are not modified afterwards.

The expected behaviour would be that also the group membership is updated in azure automatically.
Comment 2 Felix Botner univentionstaff 2020-11-25 10:13:46 CET
Created attachment 10563 [details]
304_membership_after_deactivation_reactivation

This is a test for 92_office365 to reproduce the problem.

We remove membership for all groups in azure_handler.py->deactivate_user, but if the user is reactivated we do not re activate the group membership.
Comment 3 Felix Botner univentionstaff 2020-11-25 10:17:13 CET
Created attachment 10564 [details]
office365-user.py.patch

Here a patch for the user listener.

In case of reactivation, add user to all groups in azure, he belongs to in UDM.

Just a first draft, need discussion (What do we do if the group does not exists in azure?).
Comment 4 Felix Botner univentionstaff 2020-12-02 09:56:19 CET
git@git.knut.univention.de:univention/components/office365.git branch 4.4
f94ba6064a34ce5742d46230b247998e99f2693a
f47e4236334ed07705c99d66a4eca8ed86b44714

* moved create_groups() from office365-group.py to listener.py
* in office365-user.py, in case of reactivation (and if office365/groups/sync
  is True) add user to all azure groups (create the group if it does not
  yet exist in azure)
* added 92_office365/304_membership_after_deactivation_reactivation
Comment 5 Erik Damrose univentionstaff 2020-12-08 10:35:31 CET
Created attachment 10574 [details]
proposed patch

The fix generally works with the provided test.

Reopen: As discussed, I see one problem not covered currently. The check to decide if the group has to be created just checks if the group is in any Azure AD, but not if the group has to be created in the current AD connection.

See the proposed patch, which also adds a bit of logging to spot inconsistent objects more easily.

Do we need to adapt the current test or an additional one?
Comment 6 Felix Botner univentionstaff 2020-12-08 20:46:35 CET
(In reply to Erik Damrose from comment #5)
> Created attachment 10574 [details]
> proposed patch
> 
> The fix generally works with the provided test.
> 
> Reopen: As discussed, I see one problem not covered currently. The check to
> decide if the group has to be created just checks if the group is in any
> Azure AD, but not if the group has to be created in the current AD
> connection.
> 
> See the proposed patch, which also adds a bit of logging to spot
> inconsistent objects more easily.
> 
> Do we need to adapt the current test or an additional one?

yes, good catch, i applied that patch
and updated the test case for that scenario (group exists but for different connection)

package updated
Comment 7 Erik Damrose univentionstaff 2020-12-11 15:05:27 CET
OK: applied patch
OK: as discussed, the test was slightly adjusted
Verified
Comment 8 Erik Damrose univentionstaff 2021-01-11 12:50:56 CET
Released with App Version Univention Microsoft 365 Connector v3.3