Description Julia Bremer 2024-05-07 20:19:50 CEST

It is possible to configure allowed / disallowed service plans in Azure globally via UCR.
It is also possible to configure those allowed/disallowed service plans on groups via UDM. 

During the user creation or activation in Office365, the group memberships of that user object are evaluated, to get the service plan configuration for that user object.

This doesn't work anymore during user creation, when the group membership is adjusted during creation. 

The office365-user.py is a listener and thus gets its data directly from the listener and thus from openLDAP. 
The create operation won't contain the group membership, even if the group membership is set during the UDM creation operation.
On LDAP level, there are one create and two mod operations. 
First, the user creation (without memberOf) takes place,
then the group modification, where the user is added to memberUid / uniqueMembers and 
finally the user modification, where memberOf is updated. 

The office365 listener will only assign new subscriptions during a create operation or when the user is activated for o365.
Thus whenever activation an a group membership update or a creation and a group membership update take place, the new group membership won't be evaluated. 

Surprisingly, this has worked before.
While the LDAP operation sequence hasn't changed, UDM has.

The office365 listener takes the LDAP object and translates it to UDM before evaluating group memberships, by doing something like:
obj = mod.object(None, self.lo, self.po, dn, attributes=attributes)
obj.open()
Where attributes are the LDAP values gotten from the listener. 

Previously, the group membership was not loaded from the given LDAP attributes, but during open() via a dedicated LDAP search on the group objects. 

Since Bug #55269 this was changed, so that memberOf is used to gather the group membership on the user. Thus, the translated UDM object doesn't contain the group membership when fed with an LDAP object that doesn't contain the memberOf value yet. 


TL;DR: 
Doing something like:

udm users/user create --set username=test --set lastname=test --set group=cn=testgroup,$base --set UniventionOffice365Enabled=1 
OR
udm users/user modify --dn=uid=test,$base --append groups=cn=testgroup,$base --set UniventionOffice365Enabled=1 

will result in the office365 listener not evaluating the settings of the group testgroup during subscription assignment.