latest update 4.2.1 (2023042405) breaks logins

[bts0004]

Ever since updating to this most recent version, we now have several people no longer able to log in.

The users are getting this error message when trying to log in:
"Error occurred when trying to rename your Moodle account. A Moodle user with the new username already exists. Ask your site administrator to resolve this first."

Edit: Just to note -- this is not affecting everyone, which is confusing. There are no discernable differences between the accounts of those who can or cannot log in.

[nievessainz]

I have the same problem

[nenorojas]

Hi @bts0004 and @nievessainz ,

can you please check if the users failing to login appears in this page:

/auth/oidc/cleanupoidctokens.php

If they do, please try to delete token and reference via this page and see if they work again.

Regards

[bts0004]

I see this message: "There are no OIDC token to cleanup."

In the meantime, I have the user's authentication method switched over to manual, which allows her to log in. And browsing to this page does come back with a green confirmation that "You are linked to Microsoft 365 account (user@email.com)":
/local/o365/ucp.php?action=connection

I had her step through the first option on the page to use 'start using Microsoft 365 to log in.' It does change her authentication method back to OpenID Connect, but she ends up in the same position where she can't log in without getting the initial error message listed above. So, I have switched her back again to manual, so she can get in.

[nievessainz]

Hi @bts0004 and @nenorojas
In /auth/oidc/cleanupoidctokens.php there is no data

[nenorojas]

Hi @bts0004 @nievessainz ,

Thank you for your issue report and testing. Our recommendation at this moment is to revert plugins to version 4.1.1 (if you are using Moodle 4.1) or 4.2.0 (if you are using Moodle 4.2) while our team investigates the root cause and revert with new version with that fixed.

We will keep you posted.

Regards

[bts0004]

Thanks for the update, @nenorojas -- I'm assuming you're saying that it's safe to do an in-place revert of the previous plugin files as there were no DB changes that will cause conflicts? In other words, we don't need to perform any other steps (e.g., uninstalling) besides replacing the files with the previous version?

[jack932]

Hi @bts0004 and @nenorojas (Is it ok to mention you guys or should I not do that since you are already "Assignees"?

We have the same problem on Moodle 4.0.9+ Build 20230629 and auth_oidc Build 2022041920

The error:

Error occurred when trying to rename your Moodle account. A Moodle user with the new username already exists. Ask your site administrator to resolve this first.

More information about this error
Debug info: 2
Error code: erroruserwithusernamealreadyexists
Stack trace:

line 690 of /auth/oidc/classes/loginflow/authcode.php: moodle_exception thrown
line 379 of /auth/oidc/classes/loginflow/authcode.php: call to auth_oidc\loginflow\authcode->handlelogin()
line 136 of /auth/oidc/classes/loginflow/authcode.php: call to auth_oidc\loginflow\authcode->handleauthresponse()
line 168 of /auth/oidc/auth.php: call to auth_oidc\loginflow\authcode->handleredirect()
line 31 of /auth/oidc/index.php: call to auth_plugin_oidc->handleredirect()

/auth/oidc/cleanupoidctokens.php showed one user only, I removed that one successfully. Now it shows "There are no OIDC tokens to cleanup".

Cleaned up the cache too.

Somer users are working, some not, I haven't found a pattern yet.
Since it is the production environment of one of our customers I will try to replace the Plugin with an older one, even if our moodle is 4.0.9 and not 4.1 or 4.2 as it was in your recommendation.

Thank you!
Regards,
Michael

[nenorojas]

Hi @jack932,

Our team is looking into this case, the version 4.0 will not receive any bug fixes anymore because we follow Moodle release, so 4.0.4 of auth_oidc and local_o365 was the last one.

We have disabled from Moodle plugins pages the version 4.1.2 and 4.2.1 until we find a solution.

One pattern we noticed so far is that it might be related to users that doesn't have a UPN valid anymore, changed to something else, and there's still entries in this table [mdl_local_o365_objects].

Can you please check if the users with this error have any entries for invalid users in this table?

If they do, please try to remove it in a test environment and see if it sorts the problem.

Regards

[jack932]

@nenorojas
Thank you for your answer, it is appreciated! I will do that and report back asap.

[nenorojas]

Thanks for the update, @nenorojas -- I'm assuming you're saying that it's safe to do an in-place revert of the previous plugin files as there were no DB changes that will cause conflicts? In other words, we don't need to perform any other steps (e.g., uninstalling) besides replacing the files with the previous version?

Hi @bts0004 , rollback to an earlier version of the plugin is never safe process, so can you please check if my previous note #2331 (comment) if there are invalid entries for the users with problems to login? It seems that this problematic version has a DB change, that would make harder to revert.

Regards

[jack932]

Hi @jack932,

Our team is looking into this case, the version 4.0 will not receive any bug fixes anymore because we follow Moodle release, so 4.0.4 of auth_oidc and local_o365 was the last one.

We have disabled from Moodle plugins pages the version 4.1.2 and 4.2.1 until we find a solution.

One pattern we noticed so far is that it might be related to users that doesn't have a UPN valid anymore, changed to something else, and there's still entries in this table [mdl_local_o365_objects].

Can you please check if the users with this error have any entries for invalid users in this table?

If they do, please try to remove it in a test environment and see if it sorts the problem.

Regards

On our staging moodle we have moodle 4.0.9+ Build 20230629 and auth_oidc 4.0.4 2022041920.

In the column mdl_local_o365_objects.o365name, the domain part was upper case.
Just deleting the entry did make the login work! Nice.
In the column mdl_local_o365_objects.o365name, the domain part is now lower case.

This user had the following state:

I tried the same procedure with another user but there the error message persisted. This user had another state:

So I thought I might aswell change the o365name to lowercase there too, sadly without success.

What always helps to solve the error if the user is in the "connected" state is:

1. Disconnect the user in /local/o365/acp.php?mode=userconnections
2. Set the authentication method to "OpenID Connect" /admin/user.php
3. Match the user in /local/o365/acp.php?mode=userconnections
4. (Not sure if needed) Run /admin/tool/task/schedule_task.php?task=local_o365%5Ctask%5Cusersync

What I ask myself:
Once I delete an entry in mdl_local_o365_objects the entry still shows in /local/o365/acp.php?mode=userconnections, where does that entry come from?
It even shows after:
Purge all Caches /admin/purgecaches.php
Cleanup OpenID Connect tokens /auth/oidc/cleanupoidctokens.php
Cleanup User Sync Delta Tokens /local/o365/acp.php?mode=maintenance_cleandeltatoken

Maybe there is a way to disconnect and reconnect all users?

Michael

[bts0004]

Hi @bts0004 , rollback to an earlier version of the plugin is never safe process, so can you please check if my previous note #2331 (comment) if there are invalid entries for the users with problems to login? It seems that this problematic version has a DB change, that would make harder to revert.

Regards

@nenorojas I can confirm that using this tip has resolved the issue with the accounts who were unable to log in. We are now back up and running with everyone. Thanks for your assistance and the tips from @jack932

[jack932]

We have restored the Database and files to the pre-update state to solve the problem.
So we reverted the bad state: Moodle 4.0.9+ Build 20230629 and auth_oidc 4.0.4 2022041920
To a working state: Moodle 4.0.7+ Build 20230322 and auth_oidc 4.0.3 2022041915

Since there won't be a fix for the plugin on Moodle 4.0 we will either update to auth_oidc version 4.1.1 and Moodle 4.1 or auth_oidc 4.2.0 and Moodle 4.2, both should be working👍️

[nenorojas]

Hi @bts0004 @jack932 , thanks for your feedback about this case.

So far we have identified that this issue is related to UPN Change in the latest release https://github.com/microsoft/o365-moodle/releases 4.1.2 and 4.2.1, links related:
#1156
#2214 (comment)

It seems to happen for students synced in the past and at some stage their user has been deleted in Azure AD and a new one provided. The entries from /local/o365/acp.php?mode=userconnections are created by the user sync task.

Maybe there is a way to disconnect and reconnect all users?
That needs to be done one by one, we are still investigating the best way to allow admins to handle these exceptions via UI, may be allowing deleting the entries from user connection by admins via UI, but cleaning the entries from DB at this moment seems to fix the problem for users to login.

Regards

[VOOM108]

We seem to have a similar, if not the same issue. In our case, this error message comes, when users for some reason had a name change in the past (like after weddings) or a change of the mail address for some other reason. They get 2 OIDC accounts, with the same username, hence the error. Merging them into one account and re-syncing simply created a second account again. Deleting accounts completely and re-syncing them sometimes works, but not always.

Moodle 4.0.4 / local_365 and OIDC 4.0.4

[aspark21]

Wouldn’t be surprised if it was a result of the botched processing of tokens

#2182 (comment)

[aspark21]

Can you try this branch and see if it resolves your issue https://github.com/aspark21/moodle-auth_oidc/tree/patch-2

[aspark21]

Yeah #1156 combined with that pre-existing bug is a recipe for disaster

@weilai-irl

[redwampa]

Hi,

I faced the same issue on 2 different instances of Moodle :

• First one Moodle upgraded from V3.11 to 4.0.9+, with OIDC and O365 plugins updated from 3.11.4 to 4.0.4
• Second already in Moodle V4.0.2+, with OIDC and O365 plugins updated from 4.0.1 to 4.0.4

Prior to setup O365 months ago, our students were identified by their student number. After the setup, we used the "User match" to match old accounts to O365 accounts.

After the recent upgrade, only students created before the "user match" had issues to login. The other ones, created directly by O365 didn't have any issue. I identified that all usernames have been replaced by email addresses on old "matched" accounts in the mdl_user DB table.

The solution I found to fix this problem, is to uncheck the option "update all accounts in Moodle for users in Azure AD", check "Match Azure usernames to moodle emails instead of moodle usernames during the sync" in O365 setup page, delete all problematic entries in database tables auth_oidc_token and local_o365_objects, then run again a "user match" with a CSV.

I hope this will help you to solve the problem.

Best regards,

[weilai-irl]

Hi all,

After some investigation, I think we found the root cause of the issue. Basically it's caused by a new feature in the last release that supports Microsoft account UPN changes. When a UPN change is detected, Moodle will try to update the username of the Moodle user to match the change, and the logic to determine whether Microsoft account UPN has changed contains a bug.

• Microsoft UPN allows for uppercase letters.
• Moodle username doesn't allow for uppercase letters.
• When creating a Moodle account from a Microsoft account, either from user sync task or login, Moodle will convert the username to lowercase.
• When connecting a Moodle account with a Microsoft account, local_o365 plugin keeps record of Microsoft account UPN and GUID, and link it to a Moodle user ID.
• When trying to determine if the UPN of a Microsoft account has changed, Moodle would compare the Moodle user username and the original value of the Microsoft account UPN for exact match. If they don't match Moodle would try to rename the Moodle user. This would happen if the UPN contains uppercase letters and Moodle username contains lowercase letters, and although the Moodle user update attempt contains exactly the same user details, calling user_update_user() function would trigger a DB error.

The solution to this is to consider letter cases when determining whether a Moodle account needs to be renamed. This will be included in the next release.

A step further would be allow site admins to choose whether to use the feature to support UPN changes. We will consider this in the next release too.

Regards,
Lai

[lukaslangkissC02]

We also have this problem. We use a feature of the Azure AD, which allows the user to use the UPN or the alternate email address to login. Therefore, the Moodle username can also be the alternate email address, which is a problem for synchronizing course participants with external systems.

Please consider to always use the UPN as username and not the alternate email address.

[katcee]

We have a problem using 4.1.1 on Moodle 4.1.2. Some of our users have 2 usernames but the same email address - usually after the original account owner got married or changed the spelling of their name. There is one account but it has two IDs, so it could be Jane.Smith@smithtown.com as the original, then Jane.Jones@smithtown.com as the new alias/proxy email. In the past, moodle has always defaulted to the first ID but absorbed both ids as separate accounts with the same email address (it seems to bypass any unique email address settings). We usually suspend the unused one. With this plugins 4.1.1 version, the login process defaults to the alias or second email, which means anyone logging in has completed nothing. We don't want to try to merge accounts because what happens if someone experiences another email change? Will it then default to that one as well? How can we get it to work so that it is defaulting to the original account again?

[weilai-irl]

Hi all,

The latest release from today (4.0.5, 4.1.3 and 4.2.2) contains improvements to the feature to support Microsoft account UPN changes, which caused some issues relating to user logins since the previous release (which has since been pulled back). The logic is described at https://docs.moodle.org/402/en/Microsoft_365#Support_Microsoft_account_UPN_changes, and a toggle has been added to turn this feature on or off.

Please check out this new release.

I'm going to close this issue now. Feel free to open a new issue if you still experience difficulty with user logins.

Regards,
Lai