Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-71437

Specific user LDAP sync on login, allowing LDAP cron to run far less often

    XMLWordPrintable

Details

    • Improvement
    • Status: Open
    • Minor
    • Resolution: Unresolved
    • 3.10.3
    • None
    • Authentication
    • None
    • MOODLE_310_STABLE

    Description

      I am currently running two significant instances of Moodle: one with >47,000 LDAP user accounts and another with >10,000 LDAP user accounts (the latter also uses LDAP enrolments). Nearly all of these entries are users not using those Moodle instances and on the >47,000 user one, most are suspended users (i.e., accounts no longer active but they might become active again). Many/most of the users in both cases will not be logging in to any Moodle instances.

      In the case of the >47,000 LDAP users, the policy includes past accounts are never deleted: they are suspended. If/when re-activated the identity of the person is in-person directly verified before it is re-enabled. This policy is completely outside of the Moodle use of LDAP and storing records for >47,000 users is a complete waste of disk space, task run time, and DBMS log entries. (For both systems I have a cron job that purges all LDAP sync scheduled task logs after a few hours to avoid a huge growth in DBMS disk space use.)

      In effect, a relatively infrequently-run scheduled task for global LDAP user sync should be possible by performing a user-specific LDAP sync when one logs in, i.e., if the log in is successful then do a quick sync of that user's records and then finish the login sequence (or deny the login if some error occurs with a suitable message to contact the administrator or something).

      I don't control LDAP user account creation/suspension policies or of the LDAP servers --just the Moodle servers. It would be good to store less data in the database for accounts that have never and will likely never log in. For accounts that have logged in before, then of course syncing should be done (e.g., to catch suspended accounts due to compromise, etc.) --but that can be done infrequently if syncing/enrolment checks are done at the time of logging in. Compared to the load of running the LDAP users sync and the LDAP enrolment scheduled tasks very frequently, it would be less load and allow "instant" updates of LDAP information by updating each user's LDAP info upon actually logging in.

      Over time the >47,000 LDAP user server's records will only increase --not decrease: most of those accounts are suspended (again completely per poilcies, etc. unrelated to Moodle) and so up to several thousand can potentially log in (but only a subset of them would actually wind up using Moodle).

      How feasible would doing this with Moodle's authentication / LDAP subsystem be? Certainly some might want the current behaviour, some might want it to be done at login, some might want a hybrid solution. But the more users / course enrolments / courses that are in LDAP over time, the less the current LDAP strategy appears to scale well and the less accurate the information is in the Moodle database relative to the LDAP server information --which is a problem. For example, suppose an account is marked as compromised. Currently this won't be seen by Moodle until the next LDAP user sync task is run --which might be an unacceptable amount of time (however short that time might be). Do such updates at authentication time (even if users have to be presented with a please wait screen), would allow handling such issues.

      If I am missing something about a feature or setting that can be used, please advise.

      Attachments

        Activity

          People

            Unassigned Unassigned
            preney Paul Preney
            Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Sujith Haridasan
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: