Integration of LMS Moodle and Microsoft Active Directory. Part 1
Well, this is my first post in the habr-community. In the future, this article should be one of the articles in the series of stories about building an information infrastructure of an educational institution based on Moodle , BigBlueButton , Microsoft Active Directory and Kaspersky Security Center .
For those who do not know, Moodle is a distance learning system , a sort of CMS with an emphasis on education, a lot has already been written about it in Habré. In this article I will tell you how to fully connect it with the user base created in Microsoft Active Directory.
Well, let's assume that the following has already been done:
')
First, on any machine included in the domain, you need to run the Active Directory Users and Computers MMC snap-in. Of course, you can go to the server via RDP and run it there, as many administrators like. But if you plan to further simplify your work by transferring responsibilities for maintaining the user base to others, I recommend to learn now how to install this snap-in on client machines. This is done differently in different versions of Windows. First download: for XP , for 7 SP1 and for 8 . In XP, a snap-in appears immediately via Control Panel> Administrative Tools . In 7 and 8, after installing the downloaded update, you will need to go to Control Panel> Programs> Turn Windows components on or off . There you can select Remote Server Administration Tools> Role Administration Tools> Active Directory Domain Services Tools and ...> Active Directory Domain Services Tools> Snap-ins and Command-Line Utilities ... and mark the last one to install.
Using this snap-in, we will create a separate unit for users. In it, we will store the accounts of all users, setting the structure convenient for us. Trite, but I will call this unit "Users".
In order for the Moodle system to request information about users from Active Directory, we will create a special user for communication. Let it be called moodle_liceum . Let's create it not in the “Users” container created by us, but in the existing “Users” container, so that there is no confusion between the real users' accounts and the service account created for system communication.
Add the created account to the Domain Admins group.
Of course, adding a service account to the group of administrators is not a good idea, because having hijacked the Moodle administrator password or getting access to the Moodle database, you can also get access to the domain, because the Moodle user password for communication is stored in clear text. In fact, it is enough to give this account only the rights to edit users in the "Users" division. How to do this, I will describe later. But, as they say, there is one nuance . In this case, it will not be possible to change the password from the Moodle to the user if he is a member of the Domain Admin group. Regardless of the rights to edit the division in which the user is located, only another domain administrator can change the password for the domain administrator. Such is the mysterious soul of Windows.
Now we will create this user in Active Directory.
Middle name, if you want it to be displayed, it is better to immediately enter in the same field as the name. The fact is that neither Active Directory nor Moodle provides default patronymic fields in the interface. Immediately you should change the order of the name and surname in the "Full Name" field. This will allow us to see users in the list sorted by the usual way by the name.
After creating the user and setting up his password, call the properties. Fill in the fields with email, country and city. What is it for? The fact is that the meticulous Moodle system considers that the e-mail, country and city fields are required to be filled by all users. And, if they cannot be obtained from Active Directory, the user will not be able to continue working until he has entered this data. Well, with the city and the country is clear, but what if the user does not have e-mail, or she is not known to the administrator? In this case, you can come up with a fictitious email. If desired, the user will be able to change it, while the confirmation letter will be sent to the new address, which means that the user does not have access to the mail we have invented will not be a restriction.
Go to Moodle in Administration> Plugins> Authentication> Authentication Settings , enable the LDAP Server plugin
Why LDAP? Well, LDAP is such a protocol for working with a hierarchical database. So, it is possible and necessary to connect to Active Directory using this protocol.
Well, let's start setting up the authentication plugin. Enter the name of our server in the “Server URL” field by adding the prefix ldap: // to it . Remember, the web server must be able to correctly resolve the LDAP server name to an IP address. To do this, you can specify a domain controller as a DNS server, you can also configure DNS more cleverly, you can simply enter the correct IP into the hosts file on the machine with the web server. Well, you can, of course, in the Moodle settings, specify the IP instead of the name. By the way, who does not know, you can check what the name resolves with using the ping and nslookup commands.
Of course, if you are thinking about the future, you have a backup domain controller. In this case, it is also worth pointing here. Other parameters in this section should be left as default.
Now you need to specify the data to connect to the server. However, this is not just a username and password; instead, a “Distinguished Name” is required instead of a username, it is DistinguishedName or Post DN. What is it? The fact is that in a hierarchical database, as in a file system, there can be many objects with the same name. So, the fact that the file system is called the file name, in LDAP, it is common to call common name or CN, and what is called the full file name, that is, the file name plus the path to it, is called the distinguished name or DN. Well, now a small digression about how to find out this very DN.
Back in the Active Directory Users and Computers snap-in. In the View menu, enable the option Additional Components
Now, when we call the properties of different objects, among the tabs there will be an attribute editor.
In the attribute editor, you can view all the properties of an object. Will be there and we need to distinguishName.
By the way, it's time to see how the fields are called, in which any user data is stored. By comparing what we entered in the user card and what we see in the attribute editor, we create a label.
Supervisors will notice that the country is stored twice - with the full name in the co attribute and the code in the c attribute. For Moodle you need exactly two-letter code.
Introduce the distinguished username and password derived from Active Directory into Moodle. In my example, the distinguished name will be CN = moodle_liceum_ru, CN = Users, DC = ad, DC = liceum, DC = ru . In the field “User Type” we indicate “MS ActiveDirectory”.
By default, Moodle stores password hashes in its database. It stores well - in the latest versions, the bcrypt algorithm is used, so that using the md5 database, such passwords cannot be decrypted. True, this is of little use, because if the connection with Active Directory suddenly disappears, users will not be able to log in to the system, despite the information in it about passwords. The only way to use the saved password is if the administrator manually switches the authentication type for the user account to the Manual Registration option. But you can disable this by turning on the Do not store passwords option.
In the Containers field we indicate the distinguished name of the department in which users are stored. It can be learned as described above. In our case it will be OU = Users, DC = ad, DC = liceum, DC = ru . Since users are stored in our subdivisions, we enable the Search parameter in child containers .
In the User Attribute field , specify sAMAccountName . You can, of course, experiment with this parameter. If you specify mail here, then you will need to specify an email address when logging in, if you specify telephoneNumber, then your phone number. However, with all the alternative options, we will not then be able to configure automatic login with an account from the domain.
We will leave other parameters by default.
Well, it's time to try to log in to Moodle with an account from Active Directory.
If everything has been done correctly, then it will be possible to enter Moodle. However, the system will offer us to fill in an empty questionnaire - there will be no user data in Moodle.
The reason is simple - we haven’t told Moodle yet where exactly the data should be taken. For this, the group of parameters “Data mapping” is responsible. Fill in the fields using the previously obtained label.
Well, try to log in again. This time, if everything is done correctly, no requests for filling in the missing fields will arise. In the upper right corner will be specified user data.
If you invoke a user profile, you can make sure that the data matches the information from the LDAP.
How do you use the Local Account Update, External Account Update, and Block Value settings when matching data?
I would like to manage data such as, for example, the first and last names exclusively from Active Directory. This is necessary, for example, so that the students do not write down any nonsense instead of the name and surname. And when data changes in AD, I would like to update them as quickly as possible in Moodle. For such options, a combination is suitable For each entry , Never , Locked .
In my example, the email addresses of users are unknown, so dummy ones are invented instead. This approach allows users to start working in the system immediately, and then, if desired, replace the email address with the real one, for example, to begin receiving notifications. If you want users to enter e-mail when they first log in, this field should not be filled in Active Directory. For email, I use the option With every login , When updating , Unlocked . This allows you to update data in AD when you update it in Moodle, and vice versa.
Well, now let's check if the data is updated. Let's exit Moodle, fix the user's email in Active Directory and go back to Moodle again. In the profile, the user should display a new mail.
Now we’ll change the email from Moodle. A confirmation email will be sent. The address in Moodle and in Active Directory will have to change immediately after confirming the new address.
Well, how to set up passwords in Active Directory from Moodle, how to allow users to create accounts on their own, and, of course, how to enter Moodle without entering a password - I hope to tell you about all this in the following sections. Unless, of course, someone sends an invite.
For those who do not know, Moodle is a distance learning system , a sort of CMS with an emphasis on education, a lot has already been written about it in Habré. In this article I will tell you how to fully connect it with the user base created in Microsoft Active Directory.
What is it for?
- Well, firstly, to simplify the work of the administrator, because it is easier to keep users in one database, and not in two.
- Secondly, for the possibility of delegating the functions of managing the list of users to other employees. The fact is that in Moodle all users “lie” in a single list without division into structure, and, as a result, it is impossible to give someone the right to edit parts of this list. And at the Active Directory level it is quite possible to delegate editing rights: to employees of a specific dean's office for students of this faculty, and for class teachers for students of their own class.
- Thirdly, the use of such a bundle allows you to organize SSO - the entrance to the site with the same username and password with which the user logged on to Windows. A trifle, but nice - no need to once again enter the password.
Where to begin?
Well, let's assume that the following has already been done:
- Set up a computer with a server version of Microsoft Windows. Any version, you can 2003, you can 2008 (in the screenshots will be 2012). On this server, the role of the domain controller has already been raised. Several machines have already been entered into the domain. Let the domain be called ad.liceum.ru , its NetBIOS name ad_liceum_ru , and the domain controller pdc.ad.liceum.ru
- Configured web server with Moodle. I have it based on Ubuntu 12.04. Of course, you can install IIS and Moodle on the same machine as the domain controller, but that’s another story. Let the server be called moodle.liceum.ru . The screenshots will be Moodle 2.5, but the logic has not fundamentally changed since version 1.9. Moodle is already configured to send mail.
- The domain controller, web server, and machines included in the domain have the ability to interact with each other. In the simplest case, you can simply arrange them in one network, but you can use a more complex configuration with clever routing and closing all unnecessary ports.
')
Manage users in Active Directory
First, on any machine included in the domain, you need to run the Active Directory Users and Computers MMC snap-in. Of course, you can go to the server via RDP and run it there, as many administrators like. But if you plan to further simplify your work by transferring responsibilities for maintaining the user base to others, I recommend to learn now how to install this snap-in on client machines. This is done differently in different versions of Windows. First download: for XP , for 7 SP1 and for 8 . In XP, a snap-in appears immediately via Control Panel> Administrative Tools . In 7 and 8, after installing the downloaded update, you will need to go to Control Panel> Programs> Turn Windows components on or off . There you can select Remote Server Administration Tools> Role Administration Tools> Active Directory Domain Services Tools and ...> Active Directory Domain Services Tools> Snap-ins and Command-Line Utilities ... and mark the last one to install.
Using this snap-in, we will create a separate unit for users. In it, we will store the accounts of all users, setting the structure convenient for us. Trite, but I will call this unit "Users".
In order for the Moodle system to request information about users from Active Directory, we will create a special user for communication. Let it be called moodle_liceum . Let's create it not in the “Users” container created by us, but in the existing “Users” container, so that there is no confusion between the real users' accounts and the service account created for system communication.
Add the created account to the Domain Admins group.
Of course, adding a service account to the group of administrators is not a good idea, because having hijacked the Moodle administrator password or getting access to the Moodle database, you can also get access to the domain, because the Moodle user password for communication is stored in clear text. In fact, it is enough to give this account only the rights to edit users in the "Users" division. How to do this, I will describe later. But, as they say, there is one nuance . In this case, it will not be possible to change the password from the Moodle to the user if he is a member of the Domain Admin group. Regardless of the rights to edit the division in which the user is located, only another domain administrator can change the password for the domain administrator. Such is the mysterious soul of Windows.
Now we will create this user in Active Directory.
Middle name, if you want it to be displayed, it is better to immediately enter in the same field as the name. The fact is that neither Active Directory nor Moodle provides default patronymic fields in the interface. Immediately you should change the order of the name and surname in the "Full Name" field. This will allow us to see users in the list sorted by the usual way by the name.
After creating the user and setting up his password, call the properties. Fill in the fields with email, country and city. What is it for? The fact is that the meticulous Moodle system considers that the e-mail, country and city fields are required to be filled by all users. And, if they cannot be obtained from Active Directory, the user will not be able to continue working until he has entered this data. Well, with the city and the country is clear, but what if the user does not have e-mail, or she is not known to the administrator? In this case, you can come up with a fictitious email. If desired, the user will be able to change it, while the confirmation letter will be sent to the new address, which means that the user does not have access to the mail we have invented will not be a restriction.
Customize Moodle
Go to Moodle in Administration> Plugins> Authentication> Authentication Settings , enable the LDAP Server plugin
Why LDAP? Well, LDAP is such a protocol for working with a hierarchical database. So, it is possible and necessary to connect to Active Directory using this protocol.
Well, let's start setting up the authentication plugin. Enter the name of our server in the “Server URL” field by adding the prefix ldap: // to it . Remember, the web server must be able to correctly resolve the LDAP server name to an IP address. To do this, you can specify a domain controller as a DNS server, you can also configure DNS more cleverly, you can simply enter the correct IP into the hosts file on the machine with the web server. Well, you can, of course, in the Moodle settings, specify the IP instead of the name. By the way, who does not know, you can check what the name resolves with using the ping and nslookup commands.
Of course, if you are thinking about the future, you have a backup domain controller. In this case, it is also worth pointing here. Other parameters in this section should be left as default.
Now you need to specify the data to connect to the server. However, this is not just a username and password; instead, a “Distinguished Name” is required instead of a username, it is DistinguishedName or Post DN. What is it? The fact is that in a hierarchical database, as in a file system, there can be many objects with the same name. So, the fact that the file system is called the file name, in LDAP, it is common to call common name or CN, and what is called the full file name, that is, the file name plus the path to it, is called the distinguished name or DN. Well, now a small digression about how to find out this very DN.
We look for the necessary information in LDAP
Back in the Active Directory Users and Computers snap-in. In the View menu, enable the option Additional Components
Now, when we call the properties of different objects, among the tabs there will be an attribute editor.
In the attribute editor, you can view all the properties of an object. Will be there and we need to distinguishName.
By the way, it's time to see how the fields are called, in which any user data is stored. By comparing what we entered in the user card and what we see in the attribute editor, we create a label.
| Value | Attribute |
|---|---|
| Surname | sn |
| Name | givenName |
| Windows login | sAMAccountName |
| City | l |
| A country | with |
Supervisors will notice that the country is stored twice - with the full name in the co attribute and the code in the c attribute. For Moodle you need exactly two-letter code.
We continue to customize Moodle
Introduce the distinguished username and password derived from Active Directory into Moodle. In my example, the distinguished name will be CN = moodle_liceum_ru, CN = Users, DC = ad, DC = liceum, DC = ru . In the field “User Type” we indicate “MS ActiveDirectory”.
By default, Moodle stores password hashes in its database. It stores well - in the latest versions, the bcrypt algorithm is used, so that using the md5 database, such passwords cannot be decrypted. True, this is of little use, because if the connection with Active Directory suddenly disappears, users will not be able to log in to the system, despite the information in it about passwords. The only way to use the saved password is if the administrator manually switches the authentication type for the user account to the Manual Registration option. But you can disable this by turning on the Do not store passwords option.
In the Containers field we indicate the distinguished name of the department in which users are stored. It can be learned as described above. In our case it will be OU = Users, DC = ad, DC = liceum, DC = ru . Since users are stored in our subdivisions, we enable the Search parameter in child containers .
In the User Attribute field , specify sAMAccountName . You can, of course, experiment with this parameter. If you specify mail here, then you will need to specify an email address when logging in, if you specify telephoneNumber, then your phone number. However, with all the alternative options, we will not then be able to configure automatic login with an account from the domain.
We will leave other parameters by default.
Login
Well, it's time to try to log in to Moodle with an account from Active Directory.
If everything has been done correctly, then it will be possible to enter Moodle. However, the system will offer us to fill in an empty questionnaire - there will be no user data in Moodle.
The reason is simple - we haven’t told Moodle yet where exactly the data should be taken. For this, the group of parameters “Data mapping” is responsible. Fill in the fields using the previously obtained label.
Well, try to log in again. This time, if everything is done correctly, no requests for filling in the missing fields will arise. In the upper right corner will be specified user data.
If you invoke a user profile, you can make sure that the data matches the information from the LDAP.
Check data update
How do you use the Local Account Update, External Account Update, and Block Value settings when matching data?
I would like to manage data such as, for example, the first and last names exclusively from Active Directory. This is necessary, for example, so that the students do not write down any nonsense instead of the name and surname. And when data changes in AD, I would like to update them as quickly as possible in Moodle. For such options, a combination is suitable For each entry , Never , Locked .
In my example, the email addresses of users are unknown, so dummy ones are invented instead. This approach allows users to start working in the system immediately, and then, if desired, replace the email address with the real one, for example, to begin receiving notifications. If you want users to enter e-mail when they first log in, this field should not be filled in Active Directory. For email, I use the option With every login , When updating , Unlocked . This allows you to update data in AD when you update it in Moodle, and vice versa.
Well, now let's check if the data is updated. Let's exit Moodle, fix the user's email in Active Directory and go back to Moodle again. In the profile, the user should display a new mail.
Now we’ll change the email from Moodle. A confirmation email will be sent. The address in Moodle and in Active Directory will have to change immediately after confirming the new address.
Well, how to set up passwords in Active Directory from Moodle, how to allow users to create accounts on their own, and, of course, how to enter Moodle without entering a password - I hope to tell you about all this in the following sections. Unless, of course, someone sends an invite.
Source: https://habr.com/ru/post/200872/
All Articles