I apologize in advance. I am neither an expert in AD and LDAP, nor do I have a strong understanding of how Moodle leverages it. However, I'm a quick study, and I have some geeky people who can help with the AD end of things.
Here's the problem. For 5 years our Moodle (actually, now Mahoodle) site has used simple LDAP authentication with sAMAccountName as the user atribute for login authentication. We've kept things simple, avoiding NTLM and anything requiring writing back to AD. It's all worked beautifully. Our AD system is actually state-wide, one of the largest clouds out there, but that hasn't mattered...until...
This past spring, the state contracted with Microsoft to take over hosting of the email side of our IT as a part of their Live@EDU umbrella. As a result, our school district began the process of pushing folks over to using their full email address as the login username, and AD was configured to accept both it an sAMAccountName within our WAN. So far, staff and high school have made the switch, but middle and elementary students (who don't generally use email) are stilll using sAMAccountName at the workstation level. There's a storm a'brewin', a disconnect for many of our users between logging into workstations and email, and logging into Moodle.
So, no biggie, run a query and update everybody's identified username to their email address (and change user attribute to the relevant AD identifier). 'Cept all those middle and elementary school kids will have moved from typing 8 characters to more like 30 at login, using an email address they probably don't use for email anyway. We have LOTS of 2nd/3rd grade kids using our system, and this is going to be a toughie for them. (Then, of course, there's all the high school students who have changed their email address of record in Moodle to one they REALLY use, generally not the school-supplied one which is part of our AD config - and you can see it's gonne get crazy!)
So the question is...is there a way for Moodle to be configured to accept more than one AD entry as the User Attribute for authentication purposes? And, of course, since we're Mahoodle (with SSO to Mahara), can we still maintain a consistency of entry so that, no matter what the user uses to authenticate, Moodle retains (and Mahara sees) always the same identifier? Since our AD is configured that way, I was hoping we might be able to do the same in Moodle.
NTLM/SSO would probably help a lot inside the WAN, but a sizeable number of our user base (again, young students) are using generic logins for the workstation (the machines are just left logged in all day), and personal network logins for resources like Moodle, so I'm not sure that'd work either.
Again, I'm not an expert, but I'm trainable, and will happily accept links to readings and other scaffolds so that I can understand the advice....unless, of course, the answer is a firm "No!"
as you have the source code, the answer is always yes . I mean, there's no way you can do this with just Moodle configuration, you'll need to modify some code in the LDAP authentication plugin
But as you have the source code for it, you can make it behave the way you want it.
With just a fast reading of the code, and given that you are not using NTLM or anything requiring writing back to AD (including self-registration in AD), I'd say that you'll need to modify at least user_login(), ldap_find_userdn(), iscreator(), and sync_roles(). If you are using cli/sync_users.php, you'll also need to modify sync_users() and update_user_record().
You'll need to modify authenticate_user_login() (in lib/moodlelib.php) too, so it doesn't create a new user when she has logged in with one of the alternate fields (probably by making user_login() return the canonical username and comparing it with the supplied username, and acting accordingly).
It's a bit tricky, but certainly doable.
Thanks very much for taking the time to enumerate the necessary changes. | will definitely run your suggestions past the code monkeys, and see if they're interested. But since we're talking about modifying quite a number of routines, and protecting the changes against future upgrades, I'm thinking a serious discussion about standardizing logins for users is the smart money.
I really hate to create problems for our youngest users, since, in my world (PK12 public school district), they're the ones who use the system with the most interest and enthusiasm. But the decision to move login username fields was not mine, so I guess we all have to deal.
I have my hand in a little of the Moodle system adminstration in my school but Active Directory is what I look after. I have a couple of thoughts that may help you.
When you say the AD was configured to use both sAMAccountName and the email address, I assume technically they are using the UPN (UserPrincipalName) and set that to the email address. AD has this capability built in. At my school, no one knows they can log in with something that looks like an email address but it does work. Assuming this is the case, is it possible for the younger children to have their UPN set to something simpler? Eg Fred@school? It is straight forward to do if someone knows a scripting language like vb script (I assume PowerShell could do it easy too). The only requirement is that the UPN is unique across the AD forrest but a sAMAccountName only needs to be unique across a domain.
My other thought is the way that we are likely to go to solve another problem - I have staff/students logging in via AD but parents are authenticated via the External Database method. Our plan is to bring everyone on to the AD without changing their Moodle login names. My solution to this problem is to create a new attribute in the AD schema and attach it to the user object. For staff/students I will set it to be the same as sAMAccountName but for parents, we will set it to be their email address. Moodle will reference this new attribute and the end users won't know any difference (except that parents will have a one time password reset requirement since I can extract Moodle password and put it into Moodle).
Depending on your access to the Active Directory (or the access of people who are nice to you), the second method may not be possible because you need to be a Schema Admin to make those changes. My first suggestion only requires permissions over the user (eg Account Operator or similar) to change the UPN.