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

LDAP auth sync should skip and report problematic user accounts

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Waiting for peer review
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.3, 3.5.3, 3.5.18, 3.8.8, 3.8.9, 3.9.6, 3.9.7, 3.10.4, 3.11
    • Fix Version/s: None
    • Component/s: Authentication
    • Labels:
    • Testing Instructions:
      Hide
      1. Create a user account in Active Directory or other LDAP source registry. Ensure that the username is "$newusername" sign.
      2. Login to Moodle as a Site Administrator
      3. Navigate to Site Administration > Security > Site Security Settings
      4. Ensure that Allow extended characters in usernames is disabled. Save if you made a change.
      5. Navigate to Site Administration > Server > Scheduled Tasks.
      6. Locate the line for LDAP user sync job
      7. Click the "Run Now" link.
      8. Click the "Run Now" button.

      If you don't see the "Run Now" link in step 6, you will need to:

      1. Navigate to Site Administration > Server > System Paths
      2. Fill in the Path to PHP CLI and save*.*

      What you should see:

      1. When the page finishes loading, scroll through the list of added users. You should now see a message that tells you the information for the user that could not be synchronized. It will look something like this:

      Error: Cannot create new user account. Details and the reason:
      stdClass Object
      (
          [modified]] => 1618919858
          [confirmed] => 1
          [auth] => ldap
          [mnethostid] => 1
          [username] => $newusername
          [lang] => en
          [calendartype] => gregorian
      )
      Skipping this user.

      There should also be a reason listed. The message will vary depending on the reason that the sychronization failed. If you have one or more other accounts that could not be syncronized, you will see additional similar messages which will be the same as Moodle currently displays.

      The difference is that you can now see the which account caused the issue and Moodle will complete the rest of the synchronization process for the rest of the users - neither of which it currently does.

      2. Scroll down to the very bottom of the page. A new additional message will appear a few lines before the end indicating the number of failed account creations. The number may vary depending on the number of issues but the message should look like this:

      Warning: Skipped creation of 2 user accounts.

      This was done so that Moodle Administrators could go directly to the bottom to find out if there were any issues instead of having to look through potentially thousands of user accounts in the list (I have over 28,000 in my list).

      If you made it this far, the change is working correctly.

      Show
      Create a user account in Active Directory or other LDAP source registry. Ensure that the username is "$newusername" sign. Login to Moodle as a Site Administrator Navigate to Site Administration > Security > Site Security Settings Ensure that  Allow extended characters in usernames is disabled . Save if you made a change. Navigate to Site Administration > Server > Scheduled Tasks. Locate the line for LDAP user sync job Click the "Run Now" link. Click the "Run Now" button. If you don't see the "Run Now" link in step 6, you will need to: Navigate to Site Administration > Server > System Paths Fill in the Path to PHP CLI and save*.* What you should see: 1. When the page finishes loading, scroll through the list of added users. You should now see a message that tells you the information for the user that could not be synchronized. It will look something like this: Error: Cannot create new user account. Details and the reason: stdClass Object (     [modified] ] => 1618919858     [confirmed] => 1     [auth]  => ldap     [mnethostid]  => 1     [username]  => $newusername     [lang]  => en     [calendartype]  => gregorian ) Skipping this user. There should also be a reason listed. The message will vary depending on the reason that the sychronization failed. If you have one or more other accounts that could not be syncronized, you will see additional similar messages which will be the same as Moodle currently displays. The difference is that you can now see the which account caused the issue and Moodle will complete the rest of the synchronization process for the rest of the users - neither of which it currently does. 2. Scroll down to the very bottom of the page. A new additional message will appear a few lines before the end indicating the number of failed account creations. The number may vary depending on the number of issues but the message should look like this: Warning: Skipped creation of 2 user accounts. This was done so that Moodle Administrators could go directly to the bottom to find out if there were any issues instead of having to look through potentially thousands of user accounts in the list (I have over 28,000 in my list). If you made it this far, the change is working correctly.
    • Affected Branches:
      MOODLE_310_STABLE, MOODLE_311_STABLE, MOODLE_33_STABLE, MOODLE_35_STABLE, MOODLE_38_STABLE, MOODLE_39_STABLE
    • Pull 3.9 Branch:
      MDL-58395-M39
    • Pull 3.10 Branch:
      MDL-58395-M310
    • Pull 3.11 Branch:
      MDL-58395-M311
    • Pull Master Branch:
      MDL-58395-master

      Description

      If you have a problematic username it's impossible to tell which one and change it so LDAP can sync

      Possible solution suggested by Iñaki https://moodle.org/mod/forum/discuss.php?d=349037#p1408848

      Look for a line like this in auth/ldap/auth.php, around line 950 (in Moodle 3.2.1):

      $id = user_create_user($user, false);

      Then change it to look like this:

      try {
          $id = user_create_user($user, false);
      } catch (Exception $e) {
          echo "!!!! Could not add user. Exception details: ".print_r($e, true);
          echo "\n!!!! Stopping so you can fix the problematic user...\n\n\n";
          die();
      }

      This could be adapted as needed into a full solution

        Attachments

          Activity

            People

            Assignee:
            michael-milette Michael Milette
            Reporter:
            johno John Okely
            Peer reviewer:
            Ferran Recio Ferran Recio
            Participants:
            Component watchers:
            Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias, Sujith Haridasan
            Votes:
            5 Vote for this issue
            Watchers:
            12 Start watching this issue

              Dates

              Created:
              Updated:

                Time Tracking

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 30 minutes
                30m