Migration from LDAP to AAD - best way to do so with minimal disruption to users

[nbozhkov-ucl]

Hi all,

Moodle 3.11.8 auht_oidc and local_o365 - 3.11.4 (2021051725).

We have tested the oidc and o365 plugins successfully and ready to switch our production Moodle to AAD. We run the sync with the following options enabled:

• Match preexisting Moodle users with same-named accounts in Azure AD
• Switch matched users to Microsoft 365 (OpenID Connect) authentication

We have a big Moodle instance with 80k+ active users. When we run a test sync with AAD it took nearly 3 days to the sync job to finish. That is significantly long time to have some users unable to login to Moodle and have mixture of login methods e.g. some users still on LDAP but others using OIDC.

We thought we could run a two step process to first match the users and then switch to OIDC (with the presumption OIDC switch to be a quick run). However this did not work out as only the users that have triggered an update from AAD were switched to OIDC. Would temporary enabling the option to perform a full sync each run do the trick in shorter amount of time?

After matching the user could we simply run a SQL update statement to change from LDAP to OIDC login type or that will cause problems with the plugins?

For a comparison our full LDAP sync for the same number of users takes between 2-3 hours overnight.

Has anyone done similar migration? Any ideas on how to migrate to OIDC without having a massive impact on users while the sync job is running? Thanks.

[AntonT76]

Hi @nbozhkov-ucl

we only had about 10k users to migrate and we changed user names AND authentication method both with SQL statements. So interruption time was very short. But this worked only because our LDAP-usernames were similar to the AAD usernames and the SQL statements were easy to implement.

We do not have any problems with this method, just a problem with user synchronisation, but this was because we have used an older plugin and it was resolved by updating the plugin.

But I don't want to give any guarantee that it works so well in your system.

br, Anton

[nbozhkov-ucl]

Thanks @AntonT76

We will not be changing usernames as they are using as unique key for other Moodle integrations. Our usernames are in the samAccountname format e.g. abcdefg and not the UPN format [email protected]. So only the login type to change. I have tested this approach by running a sql update statement and it works but was worried that it does not say "Connected" on the user connection status in o365 plugin and whether this might bring any problems down the line if used in Production.

Further comments from other members are welcome.

Thanks. Nikola

[bmuczynski]

Hi @nbozhkov-ucl

we only had about 10k users to migrate and we changed user names AND authentication method both with SQL statements. So interruption time was very short. But this worked only because our LDAP-usernames were similar to the AAD usernames and the SQL statements were easy to implement.

We do not have any problems with this method, just a problem with user synchronisation, but this was because we have used an older plugin and it was resolved by updating the plugin.

But I don't want to give any guarantee that it works so well in your system.

br, Anton

Thanks for this tip @AntonT76!

Could you please share some more details for you approach? Was it enough to update mdl_user and mdl_auth_oidc_token tables? Could you maybe share your SQL implementation for this problem?

BR Bart

[AntonT76]

Hello @bmuczynski

shure, here is the procedure:

• prepare all oidc settings in Moodle and Azure, but disable oidc-authentication and cron job
• disable ldap-authentication und shut down Moodle
• use db query
• restart moodle and activate oidc-authentication (it is useful if you also have a local based admin login)
• try to login (normally it will work) and activate oidc cron job

The DB-Admin has used following query (I hope this is the correct one, our DB Admin is currently not available): UPDATE mdl_userSETauth='oidc' ,username = concat(username, '@yourdomain.com') WHERE deleted=0 AND auth='ldap_syncplus';

Note:

• LDAP and AAD usernames were similar (eg we changed from "u123456" to "[email protected]")
• we didn't change deleted accounts

br, Anton