Token Refresh Blocked By Multi-Factor Auth (MFA)

[upats]

Hello, last week I upgraded my site and plugins from Moodle 3.4.8 -> 3.6.5 and office 365 plugins from the latest stable 3.4. to 3.6 branch.

After the upgrade, some users report that their Moodle/Outlook Calendar sync was broken. For most users refreshing the token from the Microsoft Block works fine to restore the connection. For some users, they still get an error message "Exception: No token available for user #moodleidhere" when trying to view their calendar sync settings, even after refreshing. Looking in the DB local_office365_token table confirms there are no tokens for these users.

From looking at logs I saw this had to do with Azure MFA, which our school implemented over the summer. As a note, we have MFA rules in place for the Moodle Azure app so that users only see an MFA confirmation if they access Moodle from off-campus.

So in this case, it seems that some users had not done MFA for Moodle for a while if they were only accessing it from on-campus. When they tried to refresh the token, it required MFA, but the user was not given an MFA request because they were on our campus. If the user still had a non-expired MFA token for Moodle, it works, but if they don't it fails silently.

We are able give users the workaround of forcing an MFA request by having them try from off-campus (or via LTE instead of WiFi) but hope to find a solution that would get around this problem coming up for users at all without relaxing our MFA rules.

I realize the Office 365 Moodle plugin folks might not be the best team to solve this, please let me know if there is a better Microsoft resource to ask.

This was the output logged as an API failure:

local_o365\oauth2\token::get_for_new_resource: Problem encountered getting a new token. Data: Array ( [tokenresult] => Array ( [error] => interaction_required [error_description] => AADSTS50076: Due to a configuration change made by your administrator,
or because you moved to a new location, you must use multi-factor authentication to access '00000003-0000-0000-c000-000000000000'. Trace ID: 46ac71cb-05e0-4f22-baf5-23fabd719400 Correlation ID: a886caee-0a8d-4e03-919c-b6e6e3c455e7 Timestamp: 2019-08-19 16:20:53Z
[error_codes] => Array ( [0] => 50076 ) [timestamp] => 2019-08-19 16:20:53Z [trace_id] => 46ac71cb-05e0-4f22-baf5-23fabd719400 [correlation_id] => a886caee-0a8d-4e03-919c-b6e6e3c455e7 [error_uri] => https://login.microsoftonline.com/error?code=50076 [suberror]
=> basic_action [claims] => {"access_token":{"capolids":{"essential":true,"values":["97dfdcd9-18a8-4da5-904e-569f35938d9b"]}}} ) [resource] => https://graph.microsoft.com )

[jamesmcq]

Hi @upats - do you have a contact at Microsoft that oversees you Azure implementation? I'd see if they have any ideas to resolve. I've taken a look at https://docs.microsoft.com/en-us/azure/active-directory/develop/conditional-access-dev-guide on how we might do code changes to support MFA but I'm not sure when/if we'd be able to implement it.

[upats]

Thanks @jamesmcq. I've passed this on to my campus 365 admins.

[aspark21]

We're encountering a similar message when logging into Moodle rather than during an API call.

It would be helpful if this was at least error handled to provide a more useful explanation to the end user, that should be reasonable expectation on the Moodle side of things. But yes, ideally this should just actually prompt for the MFA, not just crash out with no explanation, UX of that is pretty terrible at the moment

But the Microsoft side of things could really do with improvement. Having experienced it myself, logging out of O365 and logging back in to Moodle does not prompt for MFA and therefore still prevents authentication. Having a completely separate browser log in did work.
However, I now have three browsers, 2 that work (one with my IP, the other via institutional VPN) and the 3rd browser that doesn't work at all (the one I primarily use 😞 )...