Hi
We currently use M2.9 and have our LDAP set up with AD.
There is an issue i would like some help with.
When a users lastname is changed in AD it creates a new user in moodle users and does not change the original user record.
is there a way to stop this?
I know about the merge user plugin but would rather it not happen in the first place.
regards Gary
This is odd. Does the username change when they change name? We map moodle username to sAMAccountName (same as they use for college PCs, Shibboleth, and other college web apps), with UPDATE LOCAL on First Name & Surname set to be On Every Login - so when someone changes name in our AD, it updates their moodle account not create them a new one.
The only thing that should create a new user is if a not-used-on-moodle-before username is logged in with.
I would think that this is an incorrect setting somewhere. Can you post your ldap settings (with urls blacked out.?)
Thanks for the reply both
Emma
I am confident all the settings are correct but here they are
The data mappings are locked and set to update on every login.
The scenario is this:
We use an oracle based bespoke system for our HR records.
the information is 'pulled' from this into AD.
It seems that the username is also changed ie a username might be Julie.Smith but gets married and the record including username is updated to Julie.Bloggs. So is this whats making Moodle see as a new account if so is there a way to set the system to 'see' its the same account?
Thanks Gary
Ahh, there is the missing bit of information!
Yes, the username is what distinguishes the user. If the username is changing as well, then Moodle will create a new user. About all you could do in those cases, is go into the Moodle and change the username manually.
Or you could possibly set it up where Moodle uses an id number to distinguish the user identity by changing the attribute setting. But now that you already have accounts set up, you would probably need to export them to find the Moodle id numbers and then import them into a specific field in ldap and then use that field as your user attribute. Bear in mind, I have never tried doing that, so no guarantees but I can't see why it wouldn't work...
This comment is speculative as I don't know the full scenario/system setup. But...
If they really don't have a proper username, for IT systems, that is persistent to them, that is really poor Identity management. And you should raise a case to have this fixed.
Hi David
We do have a username pertinent to them in the form of first and lastname so for example the username is the in this format:
joe.bloggs
but in the case of someone getting married the username surname is updated.
We currently have a unique employee number in another field.
Does anyone know if there is there a way to point to this instead as the primary identifier?
Regards Gary
Thinking about this more, I am not sure how this would work. You could try changing the user attribute but I think that would update the username to be that new field and that is not what you want.
I think about your only option is to change the username within Moodle instead of LDAP.
We use our network logins for shibboleth authentication as well, to externally hosted services (including Google Apps). Some of these ;et users bookmark things, save preferences, data etc. So in the external world, a username that changes in a professional SSO solution shows poor identity management. And shouldn't be tolerated imo. (I'm ignoring non-organisational-bound systems like Prezi and facebook here).
There are other totally unique fields in AD per user, like GUID, but that would be a nightmare to remember.
This isn't really going to help but I do know it is possible to use LDAP for authentication and change both the user name (e.g. from sue.bloggs to sue.jones if Sue gets married) and to just change their last name on the AD end without it making a new account in moodle.
Our settings are almost exactly the same as yours so I think it must be something on the AD end.
AD does incorporate a number of unique identifiers and it seems to me that moodle should use these to link accounts rather than user name or anything like that. I believe it does but I can't see any easy documentation on it. It would certainly make sense to use that.
I would double check how they are being changed and if in changing these details it is changing anything else. Such as any of the unique identifiers. If you are modifying an AD item then they shouldn't change.
If moodle doesn't use GUID or similar then it should. That is unique and shouldn't change. So the first time it would pull over all the accounts then check against the GUID to see if anything has changed. Just because you have chosen username for login then moodle shouldn't bind on that as that can change.
Also as for the argument of never ever changing usernames. Try making someone who has undergone gender realignment keep the username John.Smith you'll quickly find yourself in court in a discrimination case.
The sole username, in an AD system, that people memorise, should be whatever gets put in sAMAccountName - it might not be pretty, but it's unique.
Our IDM system automatically changes email address with staff names, but it's in a separate field and never used as a username. It also gives staff a and students a relatively memorable username (8 characters for staff, 11 for students). For students it matches their student ID, which is unique and never changes. Staff, payroll number (again, unique). Once you have a decent IDM setup in a large organisation, this stuff runs itself.
sAMAccountName does have to be unique but it is not fixed. It can (and does) change where as some of the other identifiers don't change even if you change sAMAccountName.
Linking on a value that is unique but might change at one end would be very bad practice. If the sAMAccountName changes then if moodle worked that way then the moodle account would be separated from the AD one with no easy way to get it back.
As I have said it works on ours and picks up changes to sAMAccountName on the AD end, reflecting them in moodle and then still keeping their record but with the new details.
Hi All
Thanks for the discussion on this subject but i have found the solution which is instead of 'pointing to samacountname' i have pointed LDAP user attribute to a different field which in my case is the employeeID field as employee number never changes
we did have to do a little server-side scripting because we use uppercase letters in contact workers numbers ie CWK123 this is now being converted by MYSQL with the cron script rather than having out IT dept and HR change their processes
HTH
Gary
Always useful to hear the final solution, thanks for updating us.
Also pleasing to read that your IT people had already populated a static (i.e. non-changing) attribute in your AD already - our system has always used employee number or student ID for years as the main username, probably for this reason (staff or student ID never changes, names and ergo staff email addresses can though).
