LDAP itself is working OK as if I log in with a directory user Moodle auto-creates the account and authenticates correctly.
It seems to be an issue with the users transferring from the temporary table into the actual Moodle user records.
LDAP itself is working OK as if I log in with a directory user Moodle auto-creates the account and authenticates correctly.
It seems to be an issue with the users transferring from the temporary table into the actual Moodle user records.
OK so done a bit more testing:
It appears if I limit the search scope to a single OU with, say 10 users in they get added successfully.
As soon as I extend that to the top level OUs with around 6000 users I get the failure to add records behaviour back again. However all the users are given new phantom IDs during the sync.
Not something as simple as not having the search subdirectories selected? Does your bind user have the appropriate permissions on the top level?
Search subcontexts is on (and all the DNs are set to the exact OU anyway), LDAP Bind user can read all the way up the tree no problem.
It's so bizarre, I see every user who should be added scroll down the cli window, each one with an ID number but none of them get actually added to Moodle at the end of it.
This is so weird...perhaps a time out on the database connection? Or timeout on the script? Do you get all the way to Scheduled Task complete message?
Tried adjusting Page Size from 250 to 1000, no effect (didn't expect it to make any difference but wanted to rule it out anyway)
Then moved from the old command php auth/ldap/cli/sync_users.php script to the new scheduled task method php admin/tool/task/cli/schedule_task.php --execute="\auth_ldap\task\sync_task"
This time the sync worked correctly and I got an extra section at the end
... used 68321 dbqueries
... used 64.295272111893 seconds
So it seems something is bugged in the old sync_users.php script that works OK in the newer scheduled task version. I know the old script is deprecated but would still expect it to work correctly or be removed from the code base entirely.
Anyway that seems to have got the AD sync running, just resetting the user list to try it with eDir now but looks hopeful
That is good to know. It could be the old script has not been updated in later versions due to the scheduled task taking over. Thanks for reporting back.