New account created by LDAP plugin when username changed in Active Directory

New account created by LDAP plugin when username changed in Active Directory

by Rob P -
Number of replies: 4

We're currently using the LDAP authentication plugin to manage our user accounts from Active Directory.

We have a few cases occur where the username of a student has to be changed in AD which results in a new account being made in moodle separate to their original account when they next login with their changed username and their original account's past course data (submitted assignments, forum posts, enrolments....) is not in the new account. 

Is there  a way to have the profile on moodle defined by a separate variable like an id number which is separate to the username the students login with so that LDAP won't create a new account when the user tries to login with their new username?

I know there is a merge accounts plugin tool but if it wasn't needed and could be avoided that would be great.

Average of ratings: -
In reply to Rob P

Re: New account created by LDAP plugin when username changed in Active Directory

by Emma Richardson -
Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers

You can change the user attribute to something else but I think that will mean the usernames for all students.

However, if you only have a few, I would suggest changing the username both in LDAP and Moodle at the same time and then it should sync up correctly.  I have had a few of those where I have just had to delete the newly created account in Moodle and switch the username of the correct account to match the LDAP username.  It works fine after that.

Average of ratings: -
In reply to Rob P

Re: New account created by LDAP plugin when username changed in Active Directory

by Jamie Kramer -

Hi Robert. I concur this is a pain point for many LDAP implementations over the years. I agree with you that uniqueness should some how have a way to be ensured via LDAP configuration settings. In other types of LDAP integrations I have been involved with, when dealing specifically with AD, we decided to use the objectGUID as the "key" between LDAP user objects  and user accounts in the LMS, since the objectGUID attribute is guaranteed unique and non-changing. This idea of using the objectGUID wasn't specifically implemented in the Moodle LDAP auth plugin, but in another type of data sync. However, the idea remains the same and could be applied to the LDAP auth plugin. I would think it shouldn't be too hard, yet it has been a while since I last scoured over the LDAP auth plugin code....

I have considered on many occasions of developing a patch to make this better. At this point I had not yet checked in Moodle Tracker issues to see if a patch might already exist, but since you brought this up and it is a subject I am familiar with I am going to go searching now. Maybe we'll get a nice surprise and find out that a fix exists.

I concur with Emma, that for now AFAIK the only workaround is to manually make updates to LDAP and Moodle user profile manually/simultaneously, and it is not ideal.

Average of ratings: -
In reply to Rob P

Re: New account created by LDAP plugin when username changed in Active Directory

by David Manning -

I believe this issue stems back to moodle using the username as a primary key for ldap sync. This seems like a problematic implementation because: 

  • Sometimes the username can change for the profile (e.g. someone gets married)
  • Sometimes the username can be reused with a different person (e.g. Bob smith/bsmith leaves the organization, and later Barbara Smith/bsmith joins)

Is there some way to address?

Average of ratings: -
In reply to David Manning

Re: New account created by LDAP plugin when username changed in Active Directory

by Olumuyiwa Taiwo -
Picture of Plugin developers

How about using a non-changing LDAP attribute as the username? Employee ID and email address (for example) are unlikely to be reused for different employees, since reusing them would create problems in other business processes/applications/systems. 

The issue seems to be with business processes that allow reusing of "identifying" attributes rather than with Moodle, and it's likely that the issue being seen by OP is affecting other systems as well.

Average of ratings: -