Note: You are currently viewing documentation for Moodle 3.1. Up-to-date documentation for the latest stable version of Moodle is probably available here: LDAP authentication.

LDAP authentication: Difference between revisions

From MoodleDocs
(Added forest-wide note)
 
(42 intermediate revisions by 14 users not shown)
Line 1: Line 1:
{{Moodle 1.9}}
{{Authentication}}
Location: Settings link in ''Administration > Users > [[Authentication]] > LDAP Server''
This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle.  We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle. 


This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle.  We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle. 
==Table of Contents==
__TOC__
==Basic Scenario==
==Basic Scenario==
The simple and straightforward approach  for most installations.
The simple and straightforward approach  for most installations.
Line 21: Line 18:
# You '''don't''' want your LDAP users' passwords to be stored in Moodle at all.
# You '''don't''' want your LDAP users' passwords to be stored in Moodle at all.


[[LDAP_authentication#Table of Contents|Table of Contents]]
===Enabling LDAP authentication===


===Configuring Moodle authentication===
An administrator can enable LDAP authentication as follows:


Log in as an admin user and go to Administration >> Users >> Authentication >> Manage authentication. In the table that appears, enable the "LDAP Server" authentication option (click on the closed eye to make it open) and then click on the associated 'Settings' link. You will get a page similar to this one:
# Go to ''Site administration > Plugins > Authentication > Manage authentication'' and click the eye icon opposite LDAP Server. When enabled, it will no longer be greyed out.
# Click the settings link, configure as required (see information below), then click the 'Save changes' button.


[[Image:auth_ldap_config_screenshot.jpg|center]]
[[Image:LDAPserversettings.png|center]]


Now, you just have to fill in the values. Let's go step by step.
Now, you just have to fill in the values. Let's go step by step.
[[LDAP_authentication#Table of Contents|Table of Contents]]


====LDAP Server Settings====
====LDAP Server Settings====
Line 55: Line 51:
! Value to fill in
! Value to fill in
|-
|-
| Hide passwords
| Don't cache passwords
| As you '''don't''' want to store the users's password in Moodle's database, choose '''Yes''' here.
| As you '''don't''' want to store the users's password in Moodle's database, choose '''Yes''' here.
|-
|-
Line 94: Line 90:
| The attribute used to name/search users in your LDAP tree. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in</u>.
| The attribute used to name/search users in your LDAP tree. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in</u>.


By the way, it's usually '''cn''' (Novell eDirectory and MS-AD) or '''uid''' (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could use '''sAMAccountName''' (the pre-Windows 2000 logon account name) if you need too.
By the way, it's usually '''cn''' (Novell eDirectory and MS-AD) or '''uid''' (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could (and have to, if you intend to use NTLM SSO) use '''sAMAccountName''' (the pre-Windows 2000 logon account name) if you need too.
 
'''Correction''': With MS-AD '''sAMAccountName''' should be used anyway. With default value ('''cn''') AD users will have to login with full name / password (Username: '''John Doe''', Password: '''john's_pass'''). If you want to enable your users to login with domain username instead (Username: '''johnd''' Password: '''john's_pass'''), you should use '''sAMAccountName'''. Sadly, but logging in with DOMAIN\user or user@domain.com will not work anyway.
 
Note: You may wish to consider allowing extended characters in usernames in ''Administration > Site administration > Security > [[Site policies]]''.  
|-
|-
| Member attribute
| Member attribute
Line 106: Line 106:
| Object class
| Object class
| The type of LDAP object used to search for users. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in.</u>
| The type of LDAP object used to search for users. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in.</u>
* If you leave it blank, the filter "(objectClass=*)" will be used.
* If you leave it blank, the default value based on the ''User type'' selected above will be used (see below)
* If you provide "objectClass=some-string", then it will provide "(objectClass=some-string)" as the filter.
* If you provide "objectClass=some-string", then it will provide "(objectClass=some-string)" as the filter.
* If you provide a value that does not start with "(", it is assumed to be a value that should be set to "objectClass". So if you provide "some-string", then it will provide "(objectClass=some-string)" as the filter.
* If you provide a value that does not start with "(", it is assumed to be a value that should be set to "objectClass". So if you provide "some-string", then it will provide "(objectClass=some-string)" as the filter.
* If you provide a string that starts with a "(", then it will pass that as is. So if you provide "(&(objectClass=user)(enabledMoodleUser=1))", then it will pass that as the filter.
* If you provide a string that starts with a "(", then it will pass that as is. So if you provide "(&(objectClass=user)(enabledMoodleUser=1))", then it will pass that as the filter.


'''Note''': In the last case, that feature can be used on interactive logins,


Here are the default values for each of the ''ldap_user_type'' values:
Here are the default values for each of the ''ldap_user_type'' values:
* '''User''' for Novel eDirectory
* '''(objectClass=user)''' for Novel eDirectory
* '''posixAccount''' for RFC-2037 and RFC-2037bis
* '''(objectClass=posixAccount)''' for RFC-2037 and RFC-2037bis
* '''sambaSamAccount''' for SAMBA 3.0.x LDAP extension
* '''(objectClass=sambaSamAccount)''' for SAMBA 3.0.x LDAP extension
* '''user''' for MS-AD
* '''(objectClass=user)''' for MS-AD
* '''(objectClass=*)''' for Default
If you get an error about a problem with updating the ldap server (even if you have specified not to write changes back to the ldap server) try setting the ldap object class to * - see http://moodle.org/mod/forum/discuss.php?d=70566 for a discussion on this problem
If you get an error about a problem with updating the ldap server (even if you have specified not to write changes back to the ldap server) try setting the ldap object class to * - see http://moodle.org/mod/forum/discuss.php?d=70566 for a discussion on this problem
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====Force change password====
====Force change password====
Line 128: Line 128:
|-
|-
| Force change password
| Force change password
| Set this to ''Yes'' if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to ''no''. Bear in mind the password they are forced to change is the one stored in your LDAP server.
| '''NOTE: This setting is only used when creating your users with the LDAP sync users task. It's not used if your users are created as part of their first login to moodle'''.
 
Set this to ''Yes'' if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to ''no''. Bear in mind the password they are forced to change is the one stored in your LDAP server.


<u>As you don't want your users to change their passwords in their first login, leave this set to ''No''</u>
<u>As you don't want your users to change their passwords in their first login, leave this set to ''No''</u>
Line 134: Line 136:
| Use standard Change Password Page
| Use standard Change Password Page
|
|
* Setting this to ''Yes'' makes Moodle use it's own standard password change page, everytime users want to change their passwords.
* Setting this to ''Yes'' makes Moodle use its own standard password change page, everytime users want to change their passwords.
* Setting this to ''No'' makes Moodle use the the page specified in the field called "Password change URL" (see below).
* Setting this to ''No'' makes Moodle use the the page specified in the field called "Password change URL" (see below).


Line 147: Line 149:
| Here you can specify a location at which your users can recover or change their username/password if they've forgotten it. This will be provided to users as a button on the login page and their user page. if you leave this blank the button will not be printed.
| Here you can specify a location at which your users can recover or change their username/password if they've forgotten it. This will be provided to users as a button on the login page and their user page. if you leave this blank the button will not be printed.
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====LDAP password expiration settings====
====LDAP password expiration settings====
Line 158: Line 158:
|  
|  
* Setting this to ''No'' will make Moodle not to check if the password of the user has expired or not.
* Setting this to ''No'' will make Moodle not to check if the password of the user has expired or not.
* Setting this to ''LDAP'' will make Moodle check if the LDAP password of the user has expired or not, and warn her a number of days before the password expires.
* Setting this to ''LDAP'' will make Moodle check if the LDAP password of the user has expired or not, and warn them a number of days before the password expires. When the password has expired, a "Your password has expired" message is displayed, and if the user is able to change their password from Moodle, they are offered the option to do so.


Current code only deals with Novell eDirectory LDAP server and MS-AD.
Current code only deals with Novell eDirectory LDAP server and MS-AD.
Line 168: Line 168:
|-
|-
| Expiration attribute.
| Expiration attribute.
| The LDAP user attribute used to check password expiration. This option takes a default value based on the ''User type'' value you choosed above. <u>So unless you need something special, you don't need to fill this in.</u>
| The LDAP user attribute used to check password expiration. This option takes a default value based on the ''User type'' value you chose above. <u>So unless you need something special, you don't need to fill this in.</u>
|-
|-
| Grace logins
| Grace logins
Line 180: Line 180:
<u>So you don't need to fill this in.</u>
<u>So you don't need to fill this in.</u>
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====Enable user creation====
====Enable user creation====
Line 189: Line 187:
|-
|-
| Create users externally
| Create users externally
| New (anonymous) users can self-create user accounts on the external LDAP server and confirm them via email. If you enable this, remember to also configure module-specific options for user creation and to fill in some instructions in ''auth_instructions'' field in Administration >> Users >> Authentication >> Manage authentication. Otherwise the new users won't be able to self-create new accounts.
| New (anonymous) users can self-create user accounts on the external LDAP server and confirm them via email. If you enable this, remember to also configure module-specific options for user creation and to fill in some instructions in ''auth_instructions'' field in ''Site administration > Plugins > Authentication > Manage authentication''. Otherwise the new users won't be able to self-create new accounts.


As of now, only Novell eDirectory and MS-AD can create users externally.
Novell eDirectory and MS-AD can create users externally. You can also create users in RFC-2307 compliant servers.  
|-
|-
| Context for new users
| Context for new users
| Specify the context where users are created. This context should be different from other users' contexts to prevent security issues.  
| Specify the context where users are created. This context should be different from other users' contexts to prevent security issues.  
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====Course creation====
====Course creation====
Line 212: Line 208:
|}
|}


[[LDAP_authentication#Table of Contents|Table of Contents]]
====User account syncronisation====
 
====Cron synchronization script====
{| border="1" cellspacing="0" cellpadding="5"
{| border="1" cellspacing="0" cellpadding="5"
! Field name
! Field name
Line 222: Line 216:
| Specify what to do with internal user account during mass synchronization when user was removed from external source. Only suspended users are automatically revived if they reappear in ext source.
| Specify what to do with internal user account during mass synchronization when user was removed from external source. Only suspended users are automatically revived if they reappear in ext source.
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====NTLM SSO====
====NTLM SSO====
Line 239: Line 231:
| If all of you clients (or most of them) are using MS Internet Explorer, you can set this option to bypasses certain steps of the SSO login and speed up login times. This only works with MS Internet Explorer, but deals with other browsers in a sensible way (they are automatically sent to the plain login page).
| If all of you clients (or most of them) are using MS Internet Explorer, you can set this option to bypasses certain steps of the SSO login and speed up login times. This only works with MS Internet Explorer, but deals with other browsers in a sensible way (they are automatically sent to the plain login page).
|}
|}
[[LDAP_authentication#Table of Contents|Table of Contents]]


====Data Mapping====
====Data Mapping====
Line 316: Line 306:
|}
|}


[[LDAP_authentication#Table of Contents|Table of Contents]]
=====Custom User profile fields=====
 
Any user profile fields created in ''Site administration > Users > Accounts > User profile fields'' should now automatically show up at the end of the Data mapping field list after the '''Address''' field. See example: [[File:ldapcustomuserprofilefields.jpg]]
 
==Enabling the LDAP users sync job==
 
The LDAP users sync job (''\auth_ldap\task\sync_task'') [[Scheduled tasks|scheduled task]] (new in Moodle 3.0; previously there was a CLI script, see MDL-51824 for more info)  is responsible for creating and updating user information, and suspending and deleting LDAP accounts.


===Setting up regular automatic synchronisation using cron===
After enabling LDAP server authentication, an administrator need to enable and configure the LDAP users sync job as follows:
There is a script located at /auth/ldap/auth_ldap_sync_users.php which will create or suspend/delete (see the setting above) all LDAP accounts automatically. Ideally, this is called from the command line once a day during a quiet time using exactly the same procedure as the standard [[Cron|cron]] job (so you will end up with two cron entries). It is important, however, to make sure that all of the above LDAP settings are working properly before you try this, as well as backing up your database and moodledata folders. Poor LDAP configuration could lead to users being wrongly deleted.


If you find that the script is not running through all of your users properly and you have MS Active Directory + over 1000 users, this is because by default, MS AD only sends back 1000 users at a time. Follow the instructions [http://support.microsoft.com/kb/315071 here] to set the MaxPageSize setting to a number higher than your total number of users (both now and in future) to fix it. This is a forest-wide setting.
# Go to ''Site administration > Server > Scheduled tasks'' and click the gear icon opposite LDAP users sync job.
# Select the desired frequency of running and enable the task by un-ticking the disabled checkbox.
{{Warning|It is important to make sure that all LDAP settings are working properly before enabling the LDAP users sync job (as well as backing up your database and moodledata folders), since incorrect LDAP configuration can result in users being wrongly deleted!}}


[[LDAP_authentication#Table of Contents|Table of Contents]]
If you find that the script is not running through all of your users properly and you have over 1000 users in each LDAP container, this is because by default some LDAP stores such as MS AD only send back 1000 users at a time and PHP versions prior to 5.4 did not implement paged support for LDAP results. If you upgrade to PHP 5.4 or higher then Moodle will obtain all your users correctly. If you can't upgrade to PHP 5.4 you may be able to follow the instructions in http://support.microsoft.com/kb/315071 to set the Active Directory MaxPageSize setting to a number higher than your total number of users (both now and in future) to fix it. This is a forest-wide setting.


==Active Directory help==
==Active Directory help==
Line 342: Line 339:
For larger installations with  multiple LDAP servers, or multiple locations (contexts) in a LDAP tree.
For larger installations with  multiple LDAP servers, or multiple locations (contexts) in a LDAP tree.


===Using multiple LDAP Servers===
===Making your LDAP directory connection resilient===
Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax :
* Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax:
ldap://my.first.server ; ldap://my.second.server ; ...


Of course, this will only work if all the servers share the same directory information, using a replication or synchronization mecanism once introduced in eDirectory and now generalized to the main LDAP-compatible directories.
ldap://my.first.server; ldap://my.second.server; ...
 
Of course, this will only work if all the servers share the same directory information, if using eDirectory you would need to ensure your servers have viability of all relevant tree partitions, or if using Active Directory the servers are holding the same information you need though replication - see notes on a multi-domain environment if this applies.


There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.
There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.
See also: [http://moodle.org/mod/forum/discuss.php?d=17198 Using multiple LDAP servers - Our students are on separate domain] forum discussion
===Using a multi-domain AD environment===
* If you're running Active Directory with multiple domains and you have users in more then one domain you will want to configure Moodle to look at your Global Catalog server. Specifically your top level domain Global Catalog server. Here is a simple example of this kind of Active Directory layout:
my.domain.ca (Root AD Domain)
| - dc1.my.domain.ca (Domain Controller)
| - dc2.my.domain.ca (Domain Controller)
|
| - - students.my.domain.ca (Sub AD Domain)
| - - - dc1.students.my.domain.ca (Domain Controller)
| - - - dc2.students.my.domain.ca (Domain Controller)
|
| - - faculty.my.domain.ca (Sub AD Domain)
| - - - dc1.faculty.my.domain.ca (Domain Controller)
| - - - dc2.faculty.my.domain.ca (Domain Controller)
In this example we have our top level domain (my.domain.ca) and two sub-domains. One sub-domain is for faculty accounts (faculty.my.domain.ca) and the other is for student accounts (students.my.domain.ca). Listed under each of those are two domain controllers.
Using the above example you'll want to use the following for accessing the Global Catalog over SSL:
ldaps://my.domain.ca:3269/
If you prefer to access your global catalog over a non-SSL connection you'll want to use:
ldap://my.domain.ca:3268/
We found if you didn't configure things this way you'd get errors like:
  [Thu May 26 15:23:53 2011] [error] [client 192.168.xxx.xxx] PHP Warning:  ldap_search() [<a href='function.ldap-search'>function.ldap-search</a>]: Search: Partial results and referral received in /xxx/xxx/moodle20/lib/ldaplib.php on line 241, referer: http://moodle.my.domain.ca/moodle20/login/index.php
  [Thu May 26 15:23:53 2011] [error] [client 192.168.xxx.xxx] PHP Warning:  ldap_first_entry(): supplied argument is not a valid ldap result resource in /xxx/xxx/moodle20/lib/ldaplib.php on line 248, referer: http://moodle.my.domain.ca/moodle20/login/index.php


===Using multiple user locations (contexts) in your LDAP tree===
===Using multiple user locations (contexts) in your LDAP tree===
Line 361: Line 391:
Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree '''and''' on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same ''common name'' (cn), while having different ''distinguished names''. Then only the second solution will have a deterministic result (returning allways the same user).
Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree '''and''' on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same ''common name'' (cn), while having different ''distinguished names''. Then only the second solution will have a deterministic result (returning allways the same user).


===Using LDAPS (LDAP + SSL)===
===Using LDAPS (LDAP over SSL)===
====Enabling LDAPS on the LDAP server side====
====Enabling LDAPS on your directory server====


* [[Active_Directory#MS_Active_Directory_.2B_SSL|Enabling LDAPS on MS Active Directory ]]
* [[Active_Directory#MS_Active_Directory_.2B_SSL|Enabling LDAPS on MS Active Directory ]]


====Enabling LDAPS on the client side (Moodle server)====
====Enabling LDAPS on your Moodle server====
Enabling LDAPS on your server can be tricky and often it is hard to pinpoint where things are going wrong. There are also differences between Windows and Linux and even different versions and distributions of Linux.


* If you are running Moodle on MS Windows, you need to tell PHP's OpenLDAP extension to disable SSL server certificate checking. You must create a directory called ''C:\OpenLDAP\sysconf''. In this directory, create a file called ''ldap.conf'' with the following content (If you are using certain versions of PHP 5.3.x you may need to place the file at other locations, [http://bugs.php.net/bug.php?id=48866 see PHP bug #48866]):
'''If you have not done so already you will need to decide upon your approach to establishing an SSL connection to your directory server:'''


  TLS_REQCERT never
* SSL connection with unverified self-signed certificate.
 
You can generate your own SSL certificate, and then instruct your Moodle server to ignore the fact that it is not valid. This setup is not as secure as others since you cannot be sure the server you are connecting to is not fake.
 
* SSL connection with trusted self-signed certificate.
 
You can generate your own SSL certificate on your directory server, and then specifically trust this certificate by installing it on your Moodle server.
 
* SSL connection with verified certificate from Internet-trusted certificate authority (CA)
 
In this approach the LDAP server has an installed certificate from an Internet-based CA, this means that your directory server would have an Internet address & host name. Your Moodle server must be trusting the certificate authority and have Internet access. This approach is not often used as it usually incurs a cost for the certificate, and it requires your directory server and Moodle server to be exposed to the Internet.
 
==Linux servers==
'''These instructions are for establishing a link using a trusted self-signed certificate.'''
 
''Note: written for a Red Hat Enterprise Linux 6 server, other Linux distributions may differ, especially in the location of the SSL certificates and OpenLdap config files, but the core principals are the same.''
 
To check that your directory server is online and accepting SSL connections on your LDAPS port (636), you can use try:
  openssl s_client –connect <ldap server ip address>:636
 
Get your directory server’s certificate (.crt) and upload to Moodle server's ssl certificate directory, on RHEL6 this is at '''/etc/ssl/certs'''
 
Convert your ‘DER’ X509 certificate into a ‘PEM’ public key certificate.
openssl x509 -in my_server_certificate.cer -inform DER -out my_server_certificate.pem -outform PEM


* If you are running Moodle on Linux or any other Unix-like operating system, and you want to disable SSL server certificate checking, you need to edit the OpenLDAP client configuration file (usually /etc/ldap.conf or /etc/ldap/ldap.conf or even /etc/openldap/ldap.conf) and make sure you have a line like the following one:
Create certificate hashes using c_rehash
c_rehash
''If c_rehash is not installed install with: yum install /usr/bin/c_rehash''


  TLS_REQCERT never
Ensure you are able to access your LDAPS server by a DNS name, this may mean adding an entry to your host file (/etc/hosts)
  <ldap server ip address>    my_server.mydomain.school


Now you should be able to use '''ldaps://''' when connecting to your LDAP server.
Verify your certificate to check that it is installed correctly
openssl verify -verbose -CApath /etc/ssl/certs /etc/ssl/certs/my_server_certificate.pem
/etc/ssl/certs/my_server_certificate.pem: OK


If you have the certificate of the LDAPS server as a file and want to check the certificate for the connection, copy the certificate file to an arbitary directory (e.g. /etc/ldap/certificate.pem) on your client and change the content of the ''ldap.conf'' as follows:
You should now be able to connect to your LDAPS server over SSL without any errors
openssl s_client –connect <ldap server DNS name>:636


  TLS_REQCERT demand
Edit your OpenLDAP config, on RHEL6 this is located at '''/etc/openldap/ldap.conf'''
  TLS_CACERT /etc/ldap/certificate.pem
  # Define location of a CA Cert
  TLS_CACERT /etc/ssl/certs/my_server_certificate.pem
TLS_CACERTDIR /etc/ssl/certs


When the requested server certificate is bad or not provided, the connection to the LDAPS server is immediately terminated.
Finally, you may or may not need to restart Apache, before configuring Moodle to use ldaps://<server DNS name>
httpd -k restart


[[LDAP_authentication#Table of Contents|Table of Contents]]
==Windows servers==
'''These instructions are for establishing a link using an unverified self-signed certificate.'''


==Appendices==
You can tell PHP's OpenLDAP extension to disable SSL server certificate checking to do this you must create a directory called ''''C:\OpenLDAP\sysconf\'''' In this directory, create a file called ''ldap.conf'' with the following content:
===ldap auth_user_create() only suports Novell===


After configuring user authentication with ldap I realized ldap only support edir (Novell) when combining ldap an email user confirmation. For example in my case (I use openldap) I have the following error after filling the user form:
TLS_REQCERT never


auth: ldap auth_user_create() does not support selected usertype:"rfc2307" (..yet)
''(If you are using certain versions of PHP 5.3.x you '''may need to place the file at other locations''', [http://bugs.php.net/bug.php?id=48866 see PHP bug #48866])''


Now you should be able to use '''ldaps://''' when connecting to your LDAP server.


==Appendices==


=== Setting Resource Limits RedHat Directory Server ===
=== Setting Resource Limits RedHat Directory Server ===
Line 428: Line 493:
  </pre>  
  </pre>  


[[LDAP_authentication#Table of Contents|Table of Contents]]
==Any questions?==
 
Please post in the [http://moodle.org/mod/forum/view.php?id=42 Authentication forum] on moodle.org.


==See also==
==See also==
Line 437: Line 504:
* [http://download.moodle.org/download.php/docs/en/how-to_guides/ldap_auth_and_enrolment_set-up.pdf LDAP auth and enrolment set-up guide] (PDF 227KB)
* [http://download.moodle.org/download.php/docs/en/how-to_guides/ldap_auth_and_enrolment_set-up.pdf LDAP auth and enrolment set-up guide] (PDF 227KB)


Using Moodle:
Forum discussions:
* [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]
* [http://moodle.org/mod/forum/view.php?id=42 User authentication forum]
* [http://moodle.org/mod/forum/discuss.php?d=32168 PHP LDAP module does not seem to be present] forum discussion
* [http://moodle.org/mod/forum/discuss.php?d=32168 PHP LDAP module does not seem to be present] forum discussion
* [http://moodle.org/mod/forum/discuss.php?d=140901 Syncronisation with AUTH_LDAP_SYNC_USERS.PHP produces fewer accounts than it should] forum discussion
* [http://moodle.org/mod/forum/discuss.php?d=140901 Syncronisation with AUTH_LDAP_SYNC_USERS.PHP produces fewer accounts than it should] forum discussion
* [http://moodle.org/mod/forum/discuss.php?d=17198 Using multiple LDAP servers] forum discussion
* [http://moodle.org/mod/forum/discuss.php?d=17198 Using multiple LDAP servers] forum discussion
[[Category:Authentication]]


[[es:LDAP_authentication]]
[[es:LDAP_authentication]]
[[fr:Utiliser un serveur LDAP]]
[[fr:Utiliser un serveur LDAP]]
[[ja:LDAP認証]]
[[ja:LDAP認証]]
[[zh:LDAP认证]]
[[de:LDAP-Server]]
[[de:Authentifizierung über LDAP]]

Latest revision as of 14:03, 24 June 2016

This document describes how to set up Lightweight Directory Access Protocol (LDAP) authentication in Moodle. We cover the basic, advanced and some trouble shooting sections to assist the user in the installation and administrating LDAP in Moodle.

Basic Scenario

The simple and straightforward approach for most installations.

Assumptions

  1. Your Moodle site is located at http://your.moodle.site/
  2. You have configured your PHP installation with the LDAP extension. It is loaded and activated, and it shows when you go to http://your.moodle.site/admin/phpinfo.php (logged in as user 'admin').
  3. Your LDAP server has 192.168.1.100 as its IP address.
  4. You are not using LDAP with SSL (also known as LDAPS) in your settings. This might prevent certain operations from working (e.g., you cannot update data if you are using MS Active Directory -- MS-AD from here on --), but should be OK if you just want to authenticate your users.
  5. You don't want your users to change their passwords the first time they log in into Moodle.
  6. You are using a single domain as the source of your authentication data in case you are using MS-AD (more on this in the Appendices).
  7. You are using a top level distinguished name (DN) of dc=my,dc=organization,dc=domain as the root of your LDAP tree.
  8. You have a non-privileged LDAP user account you will use to bind to the LDAP server. This is not necessary with certain LDAP servers, but MS-AD requires this and it won't hurt if you use it even if your LDAP server doesn't need it. Make sure this account and its password don't expire, and make this password as strong as possible. Remember you only need to type this password once, when configuring Moodle, so don't be afraid of making it as hard to guess as possible. Let's say this user account has a DN of cn=ldap-user,dc=my,dc=organization,dc=domain, and password hardtoguesspassword.
  9. All of your Moodle users are in an organizational unit (OU) called moodleusers, which is right under your LDAP root. That OU has a DN of ou=moodleusers,dc=my,dc=organization,dc=domain.
  10. You don't want your LDAP users' passwords to be stored in Moodle at all.

Enabling LDAP authentication

An administrator can enable LDAP authentication as follows:

  1. Go to Site administration > Plugins > Authentication > Manage authentication and click the eye icon opposite LDAP Server. When enabled, it will no longer be greyed out.
  2. Click the settings link, configure as required (see information below), then click the 'Save changes' button.
LDAPserversettings.png

Now, you just have to fill in the values. Let's go step by step.

LDAP Server Settings

Field name Value to fill in
Host URL As the IP of your LDAP server is 192.168.1.100, type "ldap://192.168.1.100" (without the quotes), or just "192.168.1.100" (some people have trouble connecting with the first syntax, specially on MS Windows servers).
Version Unless you are using a really old LDAP server, version 3 is the one you should choose.
LDAP Encoding Specify encoding used by LDAP server. Most probably utf-8.

Table of Contents

Bind settings

Field name Value to fill in
Don't cache passwords As you don't want to store the users's password in Moodle's database, choose Yes here.
Distinguished Name This is the distinguished name of the bind user defined above. Just type "cn=ldap-user,dc=my,dc=organization,dc=domain" (without the quotes).
Password This is the bind user password defined above. Type "hardtoguesspassword" (without the quotes).

Table of Contents

User lookup settings

Field name Value to fill in
User type Choose:
  • Novel Edirectory if your LDAP server is running Novell's eDdirectory.
  • posixAccount (rfc2307) if your LDAP server is running a RFC-2307 compatible LDAP server (choose this is your server is running OpenLDAP, including Mac OS X server).
  • posixAccount (rfc2307bis) if your LDAP server is running a RFC-2307bis compatible LDAP server.
  • sambaSamAccount (v.3.0.7) if your LDAP server is running with SAMBA's 3.x LDAP schema extension and you want to use it.
  • MS ActiveDirectory if your LDAP server is running Microsoft's Active Directory (MS-AD)
Contexts The DN of the context (container) where all of your Moodle users are found. Type ou=moodleusers,dc=my,dc=organization,dc=domain here.

On a Mac OS X Server, this is usually cn=users,dc=my,dc=organization,dc=domain.

Search subcontexts If you have any sub organizational units (subcontexts) hanging from ou=moodleusers,dc=my,dc=organization,dc=domain and you want Moodle to search there too, set this to yes. Otherwise, set this to no.
Dereference aliases Sometimes your LDAP server will tell you that the real value you are searching for is in fact in another part of the LDAP tree (this is called an alias). If you want Moodle to 'dereference' the alias and fetch the real value from the original location, set this to yes. If you don't want Moodle to dereference it, set this to no. If you are using MS-AD, set this to no.
User attribute The attribute used to name/search users in your LDAP tree. This option takes a default value based on the User type value you chose above. So unless you need something special, you don't need to fill this in.

By the way, it's usually cn (Novell eDirectory and MS-AD) or uid (RFC-2037, RFC-2037bis and SAMBA 3.x LDAP extension), but if you are using MS-AD you could (and have to, if you intend to use NTLM SSO) use sAMAccountName (the pre-Windows 2000 logon account name) if you need too.

Correction: With MS-AD sAMAccountName should be used anyway. With default value (cn) AD users will have to login with full name / password (Username: John Doe, Password: john's_pass). If you want to enable your users to login with domain username instead (Username: johnd Password: john's_pass), you should use sAMAccountName. Sadly, but logging in with DOMAIN\user or user@domain.com will not work anyway.

Note: You may wish to consider allowing extended characters in usernames in Administration > Site administration > Security > Site policies.

Member attribute The attribute used to list the members of a given group. This option takes a default value based on the User type value you choosed above. So unless you need something special, you don't need to fill this in.

By the way, the usual values are member and memberUid.

Member attribute uses dn Whether the member attribute contains distinguished names (1) or not (0).This option takes a default value based on the User type value you choosed above. So unless you need something special, you don't need to fill this in.
Object class The type of LDAP object used to search for users. This option takes a default value based on the User type value you chose above. So unless you need something special, you don't need to fill this in.
  • If you leave it blank, the default value based on the User type selected above will be used (see below)
  • If you provide "objectClass=some-string", then it will provide "(objectClass=some-string)" as the filter.
  • If you provide a value that does not start with "(", it is assumed to be a value that should be set to "objectClass". So if you provide "some-string", then it will provide "(objectClass=some-string)" as the filter.
  • If you provide a string that starts with a "(", then it will pass that as is. So if you provide "(&(objectClass=user)(enabledMoodleUser=1))", then it will pass that as the filter.

Note: In the last case, that feature can be used on interactive logins,

Here are the default values for each of the ldap_user_type values:

  • (objectClass=user) for Novel eDirectory
  • (objectClass=posixAccount) for RFC-2037 and RFC-2037bis
  • (objectClass=sambaSamAccount) for SAMBA 3.0.x LDAP extension
  • (objectClass=user) for MS-AD
  • (objectClass=*) for Default

If you get an error about a problem with updating the ldap server (even if you have specified not to write changes back to the ldap server) try setting the ldap object class to * - see http://moodle.org/mod/forum/discuss.php?d=70566 for a discussion on this problem

Force change password

Field name Value to fill in
Force change password NOTE: This setting is only used when creating your users with the LDAP sync users task. It's not used if your users are created as part of their first login to moodle.

Set this to Yes if you want to force your users to change their password on the first login into Moodle. Otherwise, set this to no. Bear in mind the password they are forced to change is the one stored in your LDAP server.

As you don't want your users to change their passwords in their first login, leave this set to No

Use standard Change Password Page
  • Setting this to Yes makes Moodle use its own standard password change page, everytime users want to change their passwords.
  • Setting this to No makes Moodle use the the page specified in the field called "Password change URL" (see below).

Bear in mind that changing your LDAP passwords from Moodle might require a LDAPS connection (this is actually a requirement for MS-AD). In addition to that, the bind user specified above must have the rights needed to change other users' passwords.

Also, code for changing passwords from Moodle for anything but Novell eDirectory and Active Directory is almost not tested, so this may or may not work for other LDAP servers.

Password Format Specify how the new password is encrypted before sending it to the LDAP server: Plain text, MD5 hash or SHA-1 hash. MS-AD uses plain text, for example.
Password change URL Here you can specify a location at which your users can recover or change their username/password if they've forgotten it. This will be provided to users as a button on the login page and their user page. if you leave this blank the button will not be printed.

LDAP password expiration settings

Field name Value to fill in
Expiration
  • Setting this to No will make Moodle not to check if the password of the user has expired or not.
  • Setting this to LDAP will make Moodle check if the LDAP password of the user has expired or not, and warn them a number of days before the password expires. When the password has expired, a "Your password has expired" message is displayed, and if the user is able to change their password from Moodle, they are offered the option to do so.

Current code only deals with Novell eDirectory LDAP server and MS-AD.

So unless you have Novell eDirectory server or MS-AD, choose No here.

Expiration warning This value sets how many days in advance of password expiration the user is warned that her password is about to expire.
Expiration attribute. The LDAP user attribute used to check password expiration. This option takes a default value based on the User type value you chose above. So unless you need something special, you don't need to fill this in.
Grace logins This setting is specific to Novell eDirectory. If set to Yes, enable LDAP gracelogin support. After password has expired the user can login until gracelogin count is 0.

So unless you have Novell eDirectory server and want to allow gracelogin support, choose No here.

Grace login attribute This setting is currently not used in the code (and is specific to Novell eDirectory).

So you don't need to fill this in.

Enable user creation

Field name Value to fill in
Create users externally New (anonymous) users can self-create user accounts on the external LDAP server and confirm them via email. If you enable this, remember to also configure module-specific options for user creation and to fill in some instructions in auth_instructions field in Site administration > Plugins > Authentication > Manage authentication. Otherwise the new users won't be able to self-create new accounts.

Novell eDirectory and MS-AD can create users externally. You can also create users in RFC-2307 compliant servers.

Context for new users Specify the context where users are created. This context should be different from other users' contexts to prevent security issues.

Course creation

Field name Value to fill in
Creators The DN of the group that contains all of your Moodle creators. This is typically a posixGroup with a "memberUid" attribute for each user you want to be a creator. If your group is called creators, type cn=creators,ou=moodleusers,dc=my,dc=organization,dc=domain here. Each memberUid attribute contains the CN of a user who is authorized to be a creator. Do not use the user's full DN (e.g., not memberUid: cn=JoeTeacher,ou=moodleusers,dc-my,dc=organizations,dc=domain, but rather memberUid: JoeTeacher).

In eDirectory, the objectClass for a group is (by default) not posixGroup but groupOfNames, whose member attribute is member, not memberUid, and whose value is the full DN of the user in question. Although you can probably modify Moodle's code to use this field, a better solution is just to add a new objectClass attribute of posixGroup to your creators group and put the CNs for each creator in a memberUid attribute.

In MS Active Directory, you will need to create a security group for your creators to be part of and then add them all. If your ldap context above is 'ou=staff,dc=my,dc=org' then your group should then be 'cn=creators,ou=staff,dc=my,dc=org'. If some of the users are from other contexts and have been added to the same security group, you'll have to add these as separate contexts after the first one using the same format.

User account syncronisation

Field name Value to fill in
Removed ext user Specify what to do with internal user account during mass synchronization when user was removed from external source. Only suspended users are automatically revived if they reappear in ext source.

NTLM SSO

Field name Value to fill in
Enable If you want to use NTLM SSO (see details at NTLM_authentication), choose Yes here. Otherwise, choose No.
Subnet Specify the subnets of the clients that will use NTLM SSO (see details at NTLM_authentication).
MS IE Fast Path? If all of you clients (or most of them) are using MS Internet Explorer, you can set this option to bypasses certain steps of the SSO login and speed up login times. This only works with MS Internet Explorer, but deals with other browsers in a sensible way (they are automatically sent to the plain login page).

Data Mapping

Field name Value to fill in
First name The name of the attribute that holds the first name of your users in your LDAP server. This is usually givenName or displayName

This setting is optional

Surname The name of the attribute that holds the surname of your users in your LDAP server. This is usually sn.

This setting is optional

Email address The name of the attribute that holds the email address of your users in your LDAP server. This is usually mail.

This setting is optional

City/town The name of the attribute that holds the city/town of your users in your LDAP server. This is usully l (lowercase L) or localityName (not valid in MS-AD).

This setting is optional

Country The name of the attribute that holds the country of your users in your LDAP server. This is usully c or countryName (not valid in MS-AD).

This setting is optional

Language preferredLanguage

This setting is optional

Description description

This setting is optional

Webpage This setting is optional
ID Number

This setting is optional

Institution

This setting is optional

Department The name of the attribute that holds the department name of your users in your LDAP server. This is usully departmentNumber (for posixAccount and maybe eDirectory) or department (for MS-AD).

This setting is optional

Phone 1 The name of the attribute that holds the telephone number of your users in your LDAP server. This is usually telephoneNumber.

This setting is optional

Phone 2 The name of the attribute that holds an additional telephone number of your users in your LDAP server. This can be homePhone, mobile, pager, facsimileTelephoneNumber or even others.

This setting is optional

Address The name of the attribute that holds the street address of your users in your LDAP server. This is usully streetAddress or street'.

This setting is optional

Custom User profile fields

Any user profile fields created in Site administration > Users > Accounts > User profile fields should now automatically show up at the end of the Data mapping field list after the Address field. See example: ldapcustomuserprofilefields.jpg

Enabling the LDAP users sync job

The LDAP users sync job (\auth_ldap\task\sync_task) scheduled task (new in Moodle 3.0; previously there was a CLI script, see MDL-51824 for more info) is responsible for creating and updating user information, and suspending and deleting LDAP accounts.

After enabling LDAP server authentication, an administrator need to enable and configure the LDAP users sync job as follows:

  1. Go to Site administration > Server > Scheduled tasks and click the gear icon opposite LDAP users sync job.
  2. Select the desired frequency of running and enable the task by un-ticking the disabled checkbox.
Warning: It is important to make sure that all LDAP settings are working properly before enabling the LDAP users sync job (as well as backing up your database and moodledata folders), since incorrect LDAP configuration can result in users being wrongly deleted!


If you find that the script is not running through all of your users properly and you have over 1000 users in each LDAP container, this is because by default some LDAP stores such as MS AD only send back 1000 users at a time and PHP versions prior to 5.4 did not implement paged support for LDAP results. If you upgrade to PHP 5.4 or higher then Moodle will obtain all your users correctly. If you can't upgrade to PHP 5.4 you may be able to follow the instructions in http://support.microsoft.com/kb/315071 to set the Active Directory MaxPageSize setting to a number higher than your total number of users (both now and in future) to fix it. This is a forest-wide setting.

Active Directory help

Active Directory is Microsoft's directory service. It is included in Windows 2000 Server and later versions of their operating system. For more information about subjects below, please go here.

  • Warning: The PHP LDAP module does not seem to be present
  • LDAP-module cannot connect any LDAP servers
  • Getting correct CNs for Contexts and Creators
  • Getting the right user_attribute
  • Installing ldp.exe Server Tool
  • Example Active Directory Configuration
  • Child Domains and the Global Catalog in MS Active Directory
  • Enabling the Global Catalog
  • Active Directory with Moodle 1.8
  • MS Active Directory + SSL

Advanced Scenarios - Multiple servers or locations

For larger installations with multiple LDAP servers, or multiple locations (contexts) in a LDAP tree.

Making your LDAP directory connection resilient

  • Entering more than one name in the ldap_host_url field can provide some sort of resilience to your system. Simply use the syntax:
ldap://my.first.server; ldap://my.second.server; ...

Of course, this will only work if all the servers share the same directory information, if using eDirectory you would need to ensure your servers have viability of all relevant tree partitions, or if using Active Directory the servers are holding the same information you need though replication - see notes on a multi-domain environment if this applies.

There is one drawback in Moodle 1.5 - 1.6 implementation of LDAP authentication : the auth_ldap_connect() function processes the servers sequentially, not in a round robin mode. Thus, if the primary server fails, you will have to wait for the connection to time out before switching to the following one.

See also: Using multiple LDAP servers - Our students are on separate domain forum discussion

Using a multi-domain AD environment

  • If you're running Active Directory with multiple domains and you have users in more then one domain you will want to configure Moodle to look at your Global Catalog server. Specifically your top level domain Global Catalog server. Here is a simple example of this kind of Active Directory layout:
my.domain.ca (Root AD Domain)
| - dc1.my.domain.ca (Domain Controller)
| - dc2.my.domain.ca (Domain Controller)
|
| - - students.my.domain.ca (Sub AD Domain)
| - - - dc1.students.my.domain.ca (Domain Controller)
| - - - dc2.students.my.domain.ca (Domain Controller)
|
| - - faculty.my.domain.ca (Sub AD Domain)
| - - - dc1.faculty.my.domain.ca (Domain Controller)
| - - - dc2.faculty.my.domain.ca (Domain Controller)

In this example we have our top level domain (my.domain.ca) and two sub-domains. One sub-domain is for faculty accounts (faculty.my.domain.ca) and the other is for student accounts (students.my.domain.ca). Listed under each of those are two domain controllers.

Using the above example you'll want to use the following for accessing the Global Catalog over SSL:

ldaps://my.domain.ca:3269/

If you prefer to access your global catalog over a non-SSL connection you'll want to use:

ldap://my.domain.ca:3268/

We found if you didn't configure things this way you'd get errors like:

 [Thu May 26 15:23:53 2011] [error] [client 192.168.xxx.xxx] PHP Warning:  ldap_search() [<a href='function.ldap-search'>function.ldap-search</a>]: Search: Partial results and referral received in /xxx/xxx/moodle20/lib/ldaplib.php on line 241, referer: http://moodle.my.domain.ca/moodle20/login/index.php
 [Thu May 26 15:23:53 2011] [error] [client 192.168.xxx.xxx] PHP Warning:  ldap_first_entry(): supplied argument is not a valid ldap result resource in /xxx/xxx/moodle20/lib/ldaplib.php on line 248, referer: http://moodle.my.domain.ca/moodle20/login/index.php

Using multiple user locations (contexts) in your LDAP tree

There is no need to use multiple user locations if your directory tree is flat, i.e. if all user accounts reside in a ou=people,dc=my,dc=organization,dc=domain or ou=people,o=myorg container.

At the opposite, if you use the ACL mecanism to delegate user management, there are chances that your users will be stored in containers like ou=students,ou=dept1,o=myorg and ou=students,ou=dept2,o=myorg ...

Then there is an alternative :

  • Look at the o=myorg level with the ldap_search_sub attribute set to yes.
  • Set the ldap_context to ou=students,ou=dept1,o=myorg ; ou=students,ou=dept2,o=myorg.

Choosing between these two solutions supposes some sort of benchmarking, as the result depends heavily on the structure of your directory tree and on your LDAP software indexing capabilities. Simply note that there is a probability in such deep trees that two users share the same common name (cn), while having different distinguished names. Then only the second solution will have a deterministic result (returning allways the same user).

Using LDAPS (LDAP over SSL)

Enabling LDAPS on your directory server

Enabling LDAPS on your Moodle server

Enabling LDAPS on your server can be tricky and often it is hard to pinpoint where things are going wrong. There are also differences between Windows and Linux and even different versions and distributions of Linux.

If you have not done so already you will need to decide upon your approach to establishing an SSL connection to your directory server:

  • SSL connection with unverified self-signed certificate.

You can generate your own SSL certificate, and then instruct your Moodle server to ignore the fact that it is not valid. This setup is not as secure as others since you cannot be sure the server you are connecting to is not fake.

  • SSL connection with trusted self-signed certificate.

You can generate your own SSL certificate on your directory server, and then specifically trust this certificate by installing it on your Moodle server.

  • SSL connection with verified certificate from Internet-trusted certificate authority (CA)

In this approach the LDAP server has an installed certificate from an Internet-based CA, this means that your directory server would have an Internet address & host name. Your Moodle server must be trusting the certificate authority and have Internet access. This approach is not often used as it usually incurs a cost for the certificate, and it requires your directory server and Moodle server to be exposed to the Internet.

Linux servers

These instructions are for establishing a link using a trusted self-signed certificate.

Note: written for a Red Hat Enterprise Linux 6 server, other Linux distributions may differ, especially in the location of the SSL certificates and OpenLdap config files, but the core principals are the same.

To check that your directory server is online and accepting SSL connections on your LDAPS port (636), you can use try:

openssl s_client –connect <ldap server ip address>:636

Get your directory server’s certificate (.crt) and upload to Moodle server's ssl certificate directory, on RHEL6 this is at /etc/ssl/certs

Convert your ‘DER’ X509 certificate into a ‘PEM’ public key certificate.

openssl x509 -in my_server_certificate.cer -inform DER -out my_server_certificate.pem -outform PEM

Create certificate hashes using c_rehash

c_rehash

If c_rehash is not installed install with: yum install /usr/bin/c_rehash

Ensure you are able to access your LDAPS server by a DNS name, this may mean adding an entry to your host file (/etc/hosts)

<ldap server ip address>    my_server.mydomain.school

Verify your certificate to check that it is installed correctly

openssl verify -verbose -CApath /etc/ssl/certs /etc/ssl/certs/my_server_certificate.pem
/etc/ssl/certs/my_server_certificate.pem: OK

You should now be able to connect to your LDAPS server over SSL without any errors

openssl s_client –connect <ldap server DNS name>:636

Edit your OpenLDAP config, on RHEL6 this is located at /etc/openldap/ldap.conf

# Define location of a CA Cert
TLS_CACERT /etc/ssl/certs/my_server_certificate.pem
TLS_CACERTDIR /etc/ssl/certs

Finally, you may or may not need to restart Apache, before configuring Moodle to use ldaps://<server DNS name>

httpd -k restart

Windows servers

These instructions are for establishing a link using an unverified self-signed certificate.

You can tell PHP's OpenLDAP extension to disable SSL server certificate checking to do this you must create a directory called 'C:\OpenLDAP\sysconf\' In this directory, create a file called ldap.conf with the following content:

TLS_REQCERT never

(If you are using certain versions of PHP 5.3.x you may need to place the file at other locations, see PHP bug #48866)

Now you should be able to use ldaps:// when connecting to your LDAP server.

Appendices

Setting Resource Limits RedHat Directory Server

Operational attributes can be set for the bind user DN using the command-line. One can simply use ldapmodify to add the following attributes:

Attribute Name Description
nsLookThroughLimit Specifies how many entries are examined for a search operation. Giving this attribute a value of -1 indicates that there is no limit.
nsSizeLimit Specifies the maximum number of entries the server returns to a client application in response to a search operation. Giving this attribute a value of -1 indicates that there is no limit.
nsTimeLimit Specifies the maximum time the server spends processing a search operation. Giving this attribute a value of -1 indicates that there is no time limit.
nsIdleTimeout Specifies the time a connection to the server can be idle before the connection is dropped. The value is given in seconds. Giving this attribute a value of -1 indicates that there is no limit.
 LDAP Console Command-Line

 ldapmodify -h redhat_dir_server -p 389 -D "cn=directory manager" -w secretpwd

 dn: uid=MoodleAdmin,ou=system,dc=myschool,dc=edu
 changetype: modify
 add:nsSizeLimit
 nsSizeLimit: 1000
 

Any questions?

Please post in the Authentication forum on moodle.org.

See also

Forum discussions: