Learning Conversations about #Moodle


Source: http://www.jarche.com/wp-content/uploads/2010/01/Informal-Learning-Conversations-400x336.png


One of Moodle's neatest features is being able to pull usernames and passwords from other places that can be used to login to Moodle. This works between Google and Moodle, external databases that you may have created and, of course, LDAP.

On the MoodleMayhem.org email list, someone asked the following:
We are currently using Moodle 1.9.11+ with a shared hosting Moodle partner. In the past year, our students were creating their own login accounts using their email accounts. We would like to switch to the Active Directory authentication which would allow kids and teachers to log in using their traditional network user name and password. I have no problem losing the accounts or old work files that are currently stored. We were using Moodle as a pilot last year and have not started using it for the 2011-12 school year.  Can anyone think of any “gotchas” to switching over, or the process? I assume we can use the same courses and simply add the teachers new account name as the teacher. Any help, concerns or words of wisdom would be happily accepted.
Some of the responses included some great advice:
Rusty Meyners (Eustace ISD): I don't think it's near as bad as it sounds but that may depend on a few things. You don't actually have to lose personal work IF you don't mind some minor adjustments on each individual account, so that would probably depend on how many people you are talking about. Pretty sure you just have to make sure the username matches the one in Active Directory and then change the Account Type from Email based to LDAP based. I'm saying this off the top of my head so forgive me that I can't remember for sure if you can get away with adjusting a username that doesn't currently match the AD account to where it does. If the usernames happen to already match, you may be able to switch the Authentication Type in bulk, but don't hold me to that yet.
The real question is, are you still going to be hosted by a Moodle partner and will they support the Active Directory connection? For all I know they specialize in that but it's the last thing you want to assume in this matter. As a network guy (among the many hats I wear) I sometimes take it for granted that I can do anything I want to with my firewalls and domain controllers but I'm of the understanding that many don't have as much cooperation from their server people. Even a reasonable network/server admin might balk at authenticating services and opening ports to an outside vendor, and as I say, neither can you assume the same from your Moodle host without first checking.

Miguel Guhlin (MoodleMayhem.org): I don't see any problems with Active Directory authentication in our setting (everyone, staff and students authenticate via AD). Here's how it works (or my understanding of how it works, so correct me if I'm wrong):
1) People go to Moodle and login using their Active Directory/Exchange Email username (e.g. mguhlin) and their email password.
2) The act of logging in creates an account in Moodle. That account has authentication that is set to LDAP server.
The only hiccup we have users running into is when they haven't logged in for a year, or if they've changed their password in AD recently, and then try to login to Moodle. At that point, we have two options:
1) Switch Moodle account authentication from LDAP server to MANUAL and update the password (I don't like this approach)
2) Delete the account then have the person log in with their "new" username and password so that the Moodle account matches the AD account.
As to switching authentication in bulk, you can do that in a tool like PHPMyAdmin. I had to do that once or twice before we switched to LDAP authentication for students.
Some SQL commands to find and update user authentication:
  • SELECT * FROM `mdl_user` WHERE auth='manual'
  • This will give you a list of everyone who has authentication set to manual. You could switch 'manual' to 'ldap' and get corresponding results.
  • UPDATE 'mdl_user'
  • SET auth='ldap'
  • WHERE auth='manual'
  • This update command will change everyone who is LDAP authenticated to manual. If you switch 'ldap' with 'manual' you will get the opposite result.
As always, while it's fun to play with MySQL commands, make sure to make a backup of the mdl_user table (SQL dump) before starting down this road.
Rusty raises a great point about Moodle partners. As nice as the folks are at different Moodle partners, the two I've spoken with are out to nickel and dime you to death. Simply being able to do SQL commands like the ones shown above just aren't allowed, and I couldn't imagine what you'd have to do to get authenticating services setup. In my district, there are prohibitions against doing AD authentication outside of the firewall. That's one reason why we have to host our Moodle inside (and I wouldn't want to pay a Moodle partner the exorbitant rate).
Ken Task (TCEA Moodle Expert Extraordinaire):  Since it's remotely hosted, consider the possibility that there could be times where the Moodle server is *not* talking through the ISD firewall to LDAP/AD.  Result: NO ONE can login to the Moodle IF *ALL* accounts are set to authenticate via LDAP.  While connections are, for
the most part, reliable, one may not be able to claim 27/7 access, which, in the case of an app like Moodle, kinda defeats the purpose of having web based.

IMHO, Administrator level users on the Moodle server should NOT be set to LDAP, so be careful about using splat MySQL commands or global imports of all users.   Consider giving teachers the option of setting up their accounts on Moodle via LDAP or EMail based authentication (manual).  If there is a hickup during the school day, at least the Teacher can access and use the content on the Moodle like a PowerPoint (ugh!).  Whatever the teacher chooses, they should login that way everytime.  If the LDAP account is different from their Manual account and they login with the LDAP credentials, they are no longer Teacher in their own course.

In setting up LDAP authentication, on the LDAP Authentication form in Moodle (at the very bottom) there is a section on data mapping where one associates the objects of LDAP to Moodle DB fields.   Among other
things, Moodle requires 'City/Town' or users are thrown into editing their profile upon initial access to 'tell more about themselves'. One cannot use a 'substitute' value in the Moodle form ... ie, for the City/Town field cannot use "Victoria" ... must use the object ID in LDAP ('l' - or whatever object is in LDAP).  Same for country ('c' -
or whatever object is in LDAP).  Do students have EMail addresses? Are those entered in LDAP/AD? (for students not allowed to use EMail that has to 'look like' an addy - user@somenet.net).

Consider setting key fields for 'On Every Login' for Moodle to pick up on any changes to existing LDAP accounts.   Would NOT consider setting up Moodle such that editing Moodle profile updates LDAP.  Moodle
retains LDAP user information mapped with exception of password.

Make sure the 'bind user' (user account in LDAP that is used to query the LDAP to look up student/teacher logins passwords) works! Changes to that account in LDAP or in-correct info in Moodle could render the entire site in-accessible IF all users are set to authenticate via LDAP.

AD/LDAP server 2003 or 2008?  May not affect you as you are remotely hosted, but a large ISD using LDAP in ONE Moodle experienced issues with inability to use LDAP sync via CronJob due to 'pages'/data transfer limitation in 2008 server (2003 server had a GUI setting ability - 2008 server [according to the server tech I was working with] does not). File: /moodle/auth/ldap/auth_ldap_sync_users.php has comments in it
worth reading.

While one can order the authentications (which one is first), I'd leave EMail based atop LDAP and set Allowed email domains to the ones used by teachers and students.  Example: ISD Teachers use @isd.net.
ISD Students use @student.isd.net.
the most part, reliable, one may not be able to claim 27/7 access, which, in the case of an app like Moodle, kinda defeats the purpose of having web based.
IMHO, Administrator level users on the Moodle server should NOT be set to LDAP, so be careful about using splat MySQL commands or global imports of all users.   Consider giving teachers the option of setting up their accounts on Moodle via LDAP or EMail based authentication (manual).  If there is a hickup during the school day, at least the Teacher can access and use the content on the Moodle like a PowerPoint (ugh!).  Whatever the teacher chooses, they should login that way everytime.  If the LDAP account is different from their Manual account and they login with the LDAP credentials, they are no longer Teacher in their own course.
In setting up LDAP authentication, on the LDAP Authentication form in Moodle (at the very bottom) there is a section on data mapping where one associates the objects of LDAP to Moodle DB fields.   Among otherthings, Moodle requires 'City/Town' or users are thrown into editing their profile upon initial access to 'tell more about themselves'. One cannot use a 'substitute' value in the Moodle form ... ie, for the City/Town field cannot use "Victoria" ... must use the object ID in LDAP ('l' - or whatever object is in LDAP).  Same for country ('c' -or whatever object is in LDAP).  Do students have EMail addresses? Are those entered in LDAP/AD? (for students not allowed to use EMail that has to 'look like' an addy - user@somenet.net).
Consider setting key fields for 'On Every Login' for Moodle to pick up on any changes to existing LDAP accounts.   Would NOT consider setting up Moodle such that editing Moodle profile updates LDAP.  Moodleretains LDAP user information mapped with exception of password.
Make sure the 'bind user' (user account in LDAP that is used to query the LDAP to look up student/teacher logins passwords) works! Changes to that account in LDAP or in-correct info in Moodle could render the entire site in-accessible IF all users are set to authenticate via LDAP.
AD/LDAP server 2003 or 2008?  May not affect you as you are remotely hosted, but a large ISD using LDAP in ONE Moodle experienced issues with inability to use LDAP sync via CronJob due to 'pages'/data transfer limitation in 2008 server (2003 server had a GUI setting ability - 2008 server [according to the server tech I was working with] does not). File: /moodle/auth/ldap/auth_ldap_sync_users.php has comments in itworth reading.
While one can order the authentications (which one is first), I'd leave EMail based atop LDAP and set Allowed email domains to the ones used by teachers and students.  Example: ISD Teachers use @isd.net.ISD Students use @student.isd.net.
Rusty Meyners: Good info to which I would only add that I believe there is a setting to tell Moodle not to cache the password which should avoid the problem when people change their password. Makes Moodle check against AD on each login.
Below is a screen shot of my setting and the entry in the Moodle Doc for that page.  
Confession: When I got here I found mine set to No and have put it back on Yes, which does not seem intuitive until carefully reading the explanation and the Moodle Doc - at least I hope that's right, now that I've put it out here! 
 
  •  EISD Moodle
  •   
    •  Administration
    •  
    •   Users
    •  
    •   Authentication
    •  
    •   LDAP server
    • (note that the "Yes" is not intuitive to the wording of the setting until you carefully read the explanation)
    •  Administration 
    •   Users
    •  
    •   Authentication
    •  
    •   LDAP server
    • (note that the "Yes" is not intuitive to the wording of the setting until you carefully read the explanation)

    image.png
    http://docs.moodle.org/20/en/auth/ldap#Bind_settingsimage.png
    http://docs.moodle.org/20/en/auth/ldap#Bind_settings

    You know, if you've followed this far, Rusty's sharing at the end here takes care of a problem we had been aware of and hadn't known exactly how to handle. Amazing, huh? That's the power of learning conversations...even when they happen on email lists!!




    Get Blog Updates via Email!
    Enter your email address:
    Delivered by FeedBurner
    PingIt!

    Everything posted on Miguel Guhlin's blogs/wikis are his personal opinion and do not necessarily represent the views of his employer(s) or its clients. Read Full Disclosure

    Comments

    Popular posts from this blog

    #Chromecast Add-Ons to Play Various Video File Formats

    Free Professional Learning! Education On Air #googleedu

    10 Steps to a Blended Learning Classroom #MIEexpert #MIE #tceamie1