Primarily we want the sync to create/disable users based on our AD, and keep their profile attributes up to date. Can you provide documentation on how you're getting the accounts to create at first login?
There weren't any particularly fancy settings to do this, and I've done it from scratch on other test instances (just spun one up, entered our LDAP connection details / attribute mappings) et voila.
I haven't included all of our mappings here, but 3 key ones are attached.
We chose to keep email as being populated from LDAP/AD when they first login, but they can then choose an alternative email address e.g. Hotmail.
Personally I'd like to revert this to be college email address always, but we have non-college users on our moodle under manual accounts (external delivery partners, who aren't managed under LDAP).
Regarding disable accounts, our Identity Management processes that create accounts when a student enrols (or re-enrols, and picks up their old account / reactivates it) also disables the accounts once their course has completed (or they have a payment issue). So we don't have to worry about them being locked out of the system - our MIS system is QL, but Novell Identity Manager does the account creation/disabling.
Maybe I'm missing something but I was under the impression that Moodle still required a local entry in it's database with a username before it would check back against the Active Directory and pull the information over. As far as pulling information over locking fields and an on login/sync is already setup.
That is not the case, I believe.
Assuming it successfully matches the username/password entered against the LDAP server, if there is no account for them in the mdl_user table it will create one and map attributes as per your LDAP plugin configuration.
That is not correct. If LDAP is set up correctly, when an AD user logs in, it will check the LDAP server and if the user is present, it will set up the account according to the mapping that you set up in the LDAP settings. The sync is useful for when you are also doing LDAP enrollments or need to remove a student from Moodle (as a student that has left will not log in again to initiate the user suspension or deletion).
Currently, the authentication ldap sync is part of the built in tasks so can be set up there. I have about 2000 thousand users and the sync takes about two minutes. Your time is definitely excessive. If you have access to the server, you might try running the sync manually (auth/ldap/cli/sync_users.php) so that you can watch it and see where it is hanging.
Tested the user account, so you can. Something learned. Due to workflows I can't modify I still need the accounts created before the users log in for the first time, but it's good to know that in a worst case scenario accounts can be created this way.
That said we don't have access to the server given we're using MoodleRooms as our host, we're putting a ticket with them now to see what we can find out on their side. But on 9/23 we ran it and had an approximately 5 hour run time, 9/24 had approximately a 9 hour run time, then 9/26 another 5 hour run time. There are only a total of 17k accounts that it should be syncing.
Currently we have done the following:
Increased the resources available to our AD server (doubled)
Went to admin/settings.php?section=performance and increased the PHP Memory available for the Cron script to the maximum on MoodleRooms
Increased our admin/auth_config.php?auth=ldap Page Size to the active directory maximum (1000)
At this point I'm going through active directory and confirming that the correct accounts are disabled to reduce the size of the query and see if that improves the performance on this script.
Update to this: I tested the sync on both our sandbox server with MoodleRooms and a private server on my desktop. In both instances I was getting sync times in the minutes. MoodleRooms is trying to come back and say that because we have the user profile mappings set to Update local on every login that is the culprit for the consistent five hours.
Is that accurate or am I getting my chain jerked? Again on my sandbox environment I'm doing 17k users entirely in the 5-8 minute range.
Is you LDAP server in a completely different network location than your Moodle server?
If this is so, network latency could make a huge impact in synchronization times. For the sake of the argument, assuming a 1 second round-trip latency for user update query (and you need at least one LDAP query per user update), that means your 17K spend 4.7 hours just in network latency (without taking into account any processing time either in the LDAP server or the Moodle server).
On the other hand, having your two servers connected to the same network gear (switch/router/whatever) can bring that latency down to a few dozens of microseconds (again just talking about network latency, I'm not counting processing time that should be the same in both scenarios).
You could add some instrumentation code (using PHP's microtime() function) to measure the time it takes to perform the relevant LDAP queries (just the queries, to minimize PHP execution times, etc.). And then measure them in both your private server and the MoodleRooms server and see if it makes any difference.
Saludos. Iñaki.
Late reply, but this issue is still ongoing and still causing issues.
Our AD server is cloud based. As above when I attempted to run this on the MoodleRooms sandbox and my own private development sandbox we were completing this synchronization in under 15 minutes. Given the discrepancy between that and the reliable 5 hour run time on our production in MoodleRooms I'm out of ideas as to what is causing the disparity in times.
I'll follow up with MR and see if they'll try adding the microtime() to measure what's going on.