User Account Matching and Completion Authentication

[angusdenton]

Hi All
We are trying to move over to OIDC authentication for all our users. Currently we are using LDAP.
Also we are an OpenLMS client so I cannot run SQL on the Moodle database that updates or creates records.
We are NOT trying to Sync data between Entra and Moodle, we are simply associating Moodle user accounts with Entra AD accounts where the Moodle username matches the username part of the AD UPN value and flipping the Auth Method to OIDC.

Moodle User asmith

matches

UPN asmith@sc.school.edu.au

Automatic matching is successful however a handful refuse to 'Complete'
Some of these accounts 'come good' 12 hours later, some never complete.

So what actually is completion ?
I had assumed that is the first login. Sometimes the matched users get an error if they attempt login that the Moodle account cannot be found, and we don't auto provision, that would create duplicate accounts.

From Lai Wei (@weilai-irl) post 2493
Regarding the status of the user on the "Manage User Connections" page:

• "Connected." will show if the auth_oidc_token table has a record for the Moodle user with the userid field matching the ID of the Moodle account. A record is created in the table when a user that's connected has logged in to Moodle.
• "Matched with existing user. Awaiting completion." will show if a record in the auth_oidc_token is not found for the Moodle account, but a record is found in the local_o365_connections table is found with the muserid column matching the Moodle user ID. This is when a manual connection is created.
• "Synced from Azure AD. Awaiting initial login." will show if both above conditions are not met, but a record is found in the local_o365_objects table with type field set to user and moodleid field set to the Moodle user ID. This is when a user connection record is created automatically, e.g. from user sync, but the user hasn't logged in yet.

I can see the accounts in the corresponding Db tables (Can do a Db SELECT ONLY) as described in the "Matched..." status above.
Just cannot get em over the line to connceted.
An explanation and some help would be greatly appreciated.

[weilai-irl]

Hi angusdenton,

Thanks for the detailed report, and sorry for the delay in getting back to you. I finally got a chance to review this issue, and I confirm it's a real bug.

What's happening

When you manually match a Moodle account to an Entra ID account via Manage User Connections, a row is stored in local_o365_connections keyed by the full Entra UPN (e.g. asmith@sc.school.edu.au). Since your Moodle usernames are only the UPN prefix (asmith), the two don't match as strings.

On first OIDC login, auth_oidc's login handler correctly looks up that local_o365_connections row and finds the right Moodle user — but then it threw that match result away and kept using the UPN-derived value from the ID token as the "username" for the rest of the login (looking up the Moodle account, creating the token record, etc.). Since no Moodle user has the username asmith@sc.school.edu.au, and account auto-creation is disabled (as it is on your OpenLMS instance), login fails with "Invalid login: User not found in Moodle."

This only affects manually matched accounts whose Moodle username differs from the Entra UPN used for matching — which is exactly your setup, and explains why only "a handful" of accounts were affected rather than all of them. There's also a related casing inconsistency: the manual-match form stored the UPN as-typed, while the automated bulk-match tool lower-cases it, so a stray case difference between what's typed and what Entra ID returns could also silently break the match.

I didn't find any scheduled task in either plugin that would explain accounts self-resolving ~12 hours later — my best guess is that those users happened to log in with their original (LDAP) credentials at some point and completed the connection via the "Connect to Microsoft 365" link in the Microsoft block, which uses a different, unaffected code path.

Fix

• auth/oidc/classes/loginflow/authcode.php: when a manually-matched user is found and their Moodle auth field is already oidc, the login now binds to that matched user directly instead of re-deriving a username from the ID token.
• Manual UPN matching (local/o365/classes/page/acp.php) now lower-cases the entered UPN at save time, consistent with the automated matching tool, and the lookup at login time normalizes case too — so stray case differences no longer break the match.

With this fix, a manually matched user (with auth already set to oidc) should connect successfully on their very first OIDC login, rather than needing to log in with their original credentials first.

Please find the fix in the linked PR. They will be included in the next release following review.

Regards,
Lai