weilai-irl
commented
3 months ago Hi @bothmani
First of all, let me run through the user sync task logic to confirm what you have experienced.
- Firstly, since you have the "Perform a full sync each run" option enabled, the task would request the list users API to get all users in your tenant. The API returns paginated results, so if you have a lot of users, it may take a number of subsequent requests to receive the full list. Note the API doesn't allow filter by group, so it's currently not possible to only get users from a selected group.
- The task will then process each user received. If a received Microsoft user doesn't have a matching Moodle account, the logic will check against the user creation restrictions. If the restriction is on either group name or group ID, then it will then try to get the name or/and ID of the group that the user is member of, and check if the configured group name or ID is on the list, thus decide whether a new Moodle account needs to be created. Note there is a one API request for each user, to if you have over 80K users, among which 50K don't have Moodle accounts, it will make 50K requests in each cron task run. This would be where most of the 8 hrs time are spent.
- The user creation restriction is only considered when a new Moodle account may need to created, from either user sync task, or user login. Once a Moodle account is created, removing the user from the group will not affect the existing Moodle account.
So to answer your questions:
- The easiest way to optimise the processing time is to use delta sync rather than full sync. This will require disable the "Perform a full sync each run" option. After this change, the first scheduled task would be the same as the current task run, i.e. taking 8 hrs to finish; however, all subsequent runs will only receive Microsoft users whose account details have changed since the last delta sync. In most cases, this will significantly reduce the task run time.
- As explained above, currently this is not possible. Technically we can update the logic to process user creation restrictions on group name or ID to fetch user IDs of members of groups matching the criteria in bulk to reduce the number of API request. We just didn't have the necessity to do it to date - the delta sync approach solves most of the issues. You can make a separate change request for it, and it will be processed in due course.
- Technically there is a way. If you configured your Azure app to require assignment to access, then configure to only allow your "Moodle-access" group to access the app, then effectively non-members of the group will not be able to login to use the Azure app, therefore will lose access to Moodle. Note that the user sync task will still process them; if they have existing accounts in Moodle, their accounts will not be deleted, but they won't be able to login using auth_oidc. If you move a user out of the group, they will lose Moodle access; if you move a user into the group, they will gain Moodle access. To configure it, in your Azure portal, go to Enterprise applications, and find the Azure app. On the Properties page, set "Assignment required?" to "Yes", and on the "Users and Groups" page, add individual users or groups. See screenshots attached.
Hope these help.
Regards, Lai
Hello, Technical environment :
Active options:
Questions:
1- How can I optimize processing time? 2- Is there a way to only retrieve users from the "Moodle-access" group? 3- If a user is removed from the group, they remain active on Moodle. Is there a way to deactivate them when they no longer belong to the authorized group?
Thank you in advance. Regards,