Authentication

Hi Mark,

Yes, with a little bit of effort, I was able to accomplish Active Directory-Moodle integration.  Here's how to do it . . .

• Under "Administration," choose "Authentication."  In the "Choose an authentication method:" drop-down, choose "Use an LDAP Server."  The settings will then appear.  Next, you need to fill out these Settings.
• In the "ldap_host_url:" field, enter in the fully-qualified domain name of your server with Active Directory installed on it, proceeding it with "ldap://".  For example, if the name of your server was "myserver," and your domain was "myorganization.com," then this blank would read: ldap://myserver.myorganization.com
• In the "ldap_contexts:" field, you need to enter in the locations of where you stored all of your users in LDAP-style format.  Let's say that you had, for example, created an organizational unit called "Students" and an organizational unit called "Teachers" at the root level of your Active Directory tree.  (In other words, at the same depth as the "Users" folder.)  Then, let's say that you also had users in the "Users" folder.  Your "ldap_contexts:" field, carrying forward the previous "myorganization.com" example, would be: ou=Students,dc=myorganization,dc=com;ou=Teachers,dc=myorganization,dc=com;cn=Users,dc=myorganization,dc=com

Note that the "Users" folder is prefaced with "cn=" and that all organization units you have created are prefaced with "ou="

• In the "ldap_user_attribute:" field, you are entering in the specific attribute in the LDAP server that matches up with the username.  If you want your users to type in their first name and last name to login, you should be able to input "cn" if you've got their first and last names entered into Active Directory.  Chances are, though, that you want them to use their Windows username to login.  So, in this field, enter: sAMAccountName
• The "ldap_search_sub:" field controls whether you want to search subcontexts for the user.  If you're like me, your organizational unit called "Students" has sub-organizational units corresponding to each class.  So, for example, I have a "Students" organizational unit inside Active Directory, and, inside that, I have another organizational unit called "Class of 2006."  If you want to search such sub-organizational units for users, set the value of "ldap_search_sub:" to anything other than zero.  (1 is a good choice.)
• In order for you to search Active Directory via LDAP, you must login using a username and password.  This is called "binding" to the LDAP server.  So, create a user that you wish to use for binding.  This user does NOT have to be a Domain Admin.  For example, you could create a user with firstname MoodleUser and lastname MoodleUser.  Then, enter this username into the "ldap_bind_dn:" blank in LDAP format.  For example: cn=MoodleUser MoodleUser,cn=Users,dc=myorganization,dc=com
• In the next blank, "ldap_bind_pw:", enter in the password for the MoodleUser you just created.
• In the next blank, "ldap_memberattribute:", you are telling Moodle the name of the attribute in the LDAP server where it can find group membership information.  In Active Directory, this is: memberOf
• The next blank is "ldap_creators:".  In this blank, enter in the Active Directory groups (in LDAP style, of course) who should be imbued with the power to create courses.  If you're like me, all of the groups are located in the "Users" folder.  So, for example, to give your teachers who are members of the "Teachers" group the power to create courses, you would enter: cn=Teachers,cn=Users,dc=myorganization,dc=com
• I have left "ldap_create_context:" blank.  From my reading, Moodle can create users via LDAP in a particular location you specify here.  Since I want to do all user account creation myself in Active Directory, I've left this blank
• The next series of optional blanks involve inputting the name of the attribute in LDAP corresponding to the information requested.  If you put these in with the proper capitalization that's in Active Directory, it doesn't seem to work.  It appears that they need to be lowercase.  So, that said, they are:

Firstname: givenname
Lastname: sn
Email address: userprincipalname or mail
Phone 1: telephonenumber
Phone 2: othertelephone
Address: streetaddress
City/town: l (that's the letter l)
Countery: c
Description: description
ID number: useraccountcontrol

I don't see anywhere in Active Directory where language is stored, so I just typed "English" in the blank.  For the email address, if your Active Directory domain matches your email address, you can just use userprincipalname.  For example, if your Active Directory is myorganization.com and your email addresses are username@myorganization.com, then userprincipal name will be fine.  If they're not the same, then enter the email addresses into the "E-mail:" blank on the "General" tab of the user's "Properties," and you should be set.

Also, I don't store ID numbers in Active Directory, so I just set it to useraccountcontrol, which, I think, is a unique number given to each user account.  You could just as well leave that blank uncompleted.

With all of this, I have noticed something . . . whether it's a bug or a "behaves as expected," I'm not sure.  If you enter in the data in the various fields (I think particularly the email field), the user is not prompted to edit his/her profile as under the email confirmation method.  The user is simply logged in and whatever information in Active Directory is transferred.

Give it a shot and see if it works!

Kyle