Moodle accounts connected to deleted Entra user objects

[benkahn-openlms]

I wanted to raise an issue I am seeing. I work with an organization that commonly deletes Entra accounts for users that leave and recreates them when they come back. Typically the period of absence is over 30 days, so the Entra account cannot be restored when they return. Instead they are recreated with the same UPN/email and other account details. This leads to a situation where a Moodle account may be linked to an Entra account but point to an object ID for the user object that is no longer present. This mismatch leads to unexpected behavior.

I came to notice this because the org enabled the setting Suspend previously synced accounts in Moodle when they are deleted from Microsoft Entra ID, and they reported that some accounts they were manually activating, but they kept getting automatically suspended each day, disrupting the users ability to use the system. I traced this to the scheduled task Suspend/re-enable/delete users based on Microsoft Entra ID status with output like: Suspended jane.doe123 (deleted in Entra ID)

Looking at these accounts:

• in the "Manage User Connections" page they look normal, and show "Synced from Microsoft Entra ID.
  Awaiting initial login." (This is because the users were created via the MS365 user sync but do not actually use OIDC auth, they chose to keep using SAML2 that they had already been using before implementing the local_365 plugins)
• inspecting the database table mdl_local_o365_objects, I found the entry for the user has a matching 'o365name' value but contained an object ID that did not match the object ID present in the user's Entra profile

From the testing I've done so far there is no way to easily disconnect the user from the deleted account, since only the "Resync" link is available from the GUI. The only ways fix this per account would be:

• manually delete the rows associated with the user from any of mdl_local_o365_objects and local_auth_oidc_token
• arrange for the user to login via alternate auth, and have them finish connection/disconnect their account from the Microsoft block
• expose OIDC auth and have them log in to complete the connection, then the option to disconnect their account appears for admins in the Manage User Connections page

I understand the plugins need to hold on to the connection to be able to reactivate the Moodle account if the Entra user comes back, but from what I can tell it is not working in the case that the user comes back after 30 days. I am not sure what the best solution is to handle this more gracefully in an automated way would be, but at minimum I wonder if a disconnect option could be added for accounts that are synced from Entra but awaiting login so this could be handled without action from the end user or manual deletion of database rows?

[weilai-irl]

Hi benkahn-openlms

Thanks for the detailed report. I confirm this as a real bug in the plugin.

Root cause
The scheduled task userenabledstatussync ("Suspend/re-enable/delete users based on Microsoft Entra ID status") decides whether a user was deleted in Entra purely by checking if the objectid stored in local_o365_objects is still present in the current list of active Entra users. It never re-checks by UPN/email, so once that stored objectid is stale (because Entra recreated the account under a new object ID after the 30+ day retention window), the task will always treat the user as deleted and keep suspending it - exactly the loop you described.

There is separate logic in the user sync process (usersync::sync_existing_user()) that's meant to repair exactly this situation: when it finds an Entra user whose UPN matches an existing Moodle account, it's supposed to detect that the stored objectid differs from the current one and update local_o365_objects accordingly. However, a recent performance change (a batch pre-fetch added to avoid N+1 queries during sync) inadvertently broke this: the pre-fetch cache only ever loads local_o365_objects rows whose stored objectid is still active in Entra, so a row with a stale objectid can never be loaded into that cache — and the repair logic silently never runs. This is a regression, not an original design gap.

This also explains why "Resync" doesn't help: it looks up the user in Entra using the stored (stale) objectid, gets a not-found result, and silently does nothing.

Fix
I've patched usersync::sync_existing_user() so the currently-stored objectid is read directly from the existing bulk user-matching query (adding one column to an already-run query, no extra DB calls) instead of the broken cache. The comparison against the current Entra objectid now happens in memory, and local_o365_objects.objectid is updated only when it has actually changed - restoring the intended self-healing behaviour without reintroducing the N+1 query pattern the original optimisation was meant to avoid.

With this fix, once a recreated Entra account is picked up by a normal user sync run (matched by UPN/email as before), the stored objectid is corrected automatically, and the enabled-status sync task will stop mis-suspending the account. No manual database cleanup should be needed going forward for this scenario.

One important catch for already-affected accounts
On sites that run the user sync task with Microsoft Graph delta queries, they only return users that changed since the last sync. If your affected accounts were recreated in Entra a while ago, that "recreated" event was already delivered once and consumed by the old, buggy code — so a plain delta sync going forward won't naturally re-surface those specific accounts to repair them. They need one full sync pass (all current Entra users, not just deltas) to be picked up and fixed. The per-account "Resync" button won't help either, since it looks the user up by the stored (stale) objectid, which still won't resolve.

To handle this without asking site admins to run anything manually, the fix also queues a one-off adhoc task during the plugin upgrade itself: if the site is currently using delta sync, it temporarily forces a single full sync run, then restores the previous delta setting automatically. If a site already has "Perform a full sync each run" enabled, this is a no-op. So simply upgrading to the version containing this fix should repair existing stuck accounts as well, with no extra steps needed.

Please find fix in the PRs linked to this issue, and test locally to verify it works. We will go through the review process locally and include the fix in the next release.

Regards,
Lai