Note: You are currently viewing documentation for Moodle 3.4. Up-to-date documentation for the latest stable version of Moodle is likely available here: Manage authentication.

Manage authentication: Difference between revisions

From MoodleDocs
(content moved from Authentication)
Line 1: Line 1:
Location: ''Administration > Users > Authentication > Manage authentication''
Location: ''Administration > Users > Authentication > Manage authentication'' (or ''Administration > Users > Authentication''  prior to Moodle 1.9)




[[Image:Authentication manage 19.png|thumb|center|Manage authentication menu]]
==Setting the authentication method==
[[Image:authentication plugins.png|thumb|Choosing an authentication plugin in Moodle 1.8 (only shows top of Authentication page)]]
To set the authentication method:


Once the site administrator has mapped out [[Authentication|Authentication methods]], then the next step will be to manage the active authenticitation plugins and set some common settings.
#Access ''Administration > Users > Authentication > Manage authentication''.
#On the Manage authentication page, click on the closed eye icon to enable your chosen [[Authentication|authentication plugin(s)]]. In Moodle 1.8 onwards, you can choose to use more than one authentication plugin (see Multi-authentication below). Use the up/down arrow icons to arrange the plugins in order, with the plugin handling the most logins at the top of the page.
#If you have chosen [[Email-based self-registration]] and wish potential users to be able to create their own accounts, select "Email-based self-registration" from the self registration drop-down menu in the common settings section. Potential users will then be presented with a "Create new account" button on the login page.
#If you have courses with guest access, set the Guest login button to show.
#Click the "Save changes" button.
#Click on Settings opposite the authentication plugin(s) you have chosen.
#Configure the required settings and click the "Save changes" button.


==Default Plugins==
==Multi-authentication==
{{Moodle 1.8}}From Moodle 1.8 onwards, multi-authentication is supported. Each authentication plugin may be used to find a username/password match. Once found, a user is logged in and alternative plugins are not used. Therefore the plugin which handles the most logins should be moved to the top of the page in order that less load is put on authentication servers.


==Common settings==


One of the first things you need to consider when setting up your Moodle site is user authentication i.e. enabling people to login to your Moodle site.
===Self registration===


Authentication methods (also known as authentication plugins) include:
If you wish users to be able to create their own user accounts, i.e. self-register, then select Email-based self-registration from the drop-down menu.


*[[Manual accounts]]
Warning: Enabling self registration results in the possibility of spammers creating accounts in order to use forum posts, blog entries etc. for spam. This risk can be minimized by limiting self registration to particular email domains with the allowed email domains setting (see below). Alternatively, self registration may be enabled for a short period of time to allow users to create accounts, and then later disabled.
*[[No login]] There is no editing on this setting via the "Manage authentication" page (see user profile)
*[[Email-based self-registration]]
*[[CAS server (SSO)]]
*[[External database authentication|External database]]
*[[FirstClass authentication|FirstClass server]]
*[[IMAP authentication|IMAP server]]
*[[LDAP authentication|LDAP server]]
*[[Moodle Network|Moodle Network authentication]]
*[[NNTP authentication|NNTP server]]
*[[No authentication]]
*[[PAM (Pluggable Authentication Modules)]]
*[[POP3 server]]
*[[RADIUS authentication|RADIUS server]]
*[[Shibboleth]]
*[[NTLM authentication|NTLM/Integrated Authentication (3rd party plugin)]]


==Common Settings==
Note: The [[Email-based self-registration]] authentication plugin must be enabled to allow users who previously self-registered to login. Selecting Email-based self-registration as the self registration method allows potential users to self register.


===Self registration===
===Guest login button===
registerauth
Default: Email-based self-registration
Choose which auth plugin will handle user self-registration.


===Guest login===
You can hide or show the guest login button on the login page. Hiding the guest login button disables [[Guest role|guest access]] to the Moodle site, however logged-in users can still enter any courses which allow guest access without being required to enrol.
buttonguestloginbutton
Default: Show
You can hide or show the guest login button on the login page.


===Alternate Login URL===
===Alternate login URL===
alternateloginurl Default: Empty


If you enter a URL here, it will be used as the login page for this site. The page should contain a form which has the action property set to 'http://localhost/login/index.php' and return fields username and password. Be careful not to enter an incorrect URL as you may lock yourself out of this site. Leave this setting blank to use the default login page.
This should be used with care, since a mistake in the URL or on the actual login page can lock you out of your site. If you do mess it up, you can remove the entry from your database (table mdl_config) using, e.g., phpmyadmin for mysql.


===Forgotten password URL===
===Forgotten password URL===
forgottenpasswordurl Default: Empty


If you enter a URL here, it will be used as the lost password recovery page for this site. This is intended for sites where passwords are handled entirely outside of Moodle. Leave this blank to use the default password recovery.
{{Moodle 1.9}}If your lost password handling is performed entirely outside of Moodle (for example, only by a help desk), you can set the url of that service here. Anybody pressing a "lost password" link in Moodle will be redirected to this URL. Note that this will disable '''all''' of Moodle's lost password recovery options regardless of authentication method(s) in use.
 
===Allowed and denied email domains===
 
Authentication may be restricted to particular email domains when using [[Email-based self-registration]] so that, for example, only students with a university email can login.
 
(Note: Prior to Moodle 1.9, the allowed and denied email domains settings can be found in ''Administration > Server > [[Email settings|Email]]''.)


===Instructions===
===ReCAPTCHA===
auth_instructions Default: Empty


Here you can provide instructions for your users, so they know which username and password they should be using. The text you enter here will appear on the login page. If you leave this blank then no instructions will be printed.
[[Image:New account form with captcha element.png|thumb|New account form with CAPTCHA element]]
A CAPTCHA is a program that can tell whether its user is a human or a computer. CAPTCHAs are used by many websites to prevent abuse from bots, or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs.


===Allowed email===
{{Moodle 1.9}}From Moodle 1.9.1 onwards, spam protection may be added to the [[Email-based self-registration]] new account form with a CAPTCHA element - a challenge-response test used to determine whether the user is human.
domainsallowemailaddresses  Default: Empty


If you want to restrict all new email addresses to particular domains, then list them here separated by spaces. All other domains will be rejected. eg ourcollege.edu.au .gov.au
ReCAPTCHA keys can be obtained from http://recaptcha.net by [https://admin.recaptcha.net/accounts/signup/?next= signing up for an account] (free) then entering a domain. The public and private keys provided can then be copied and pasted into the ''recaptchapublickey'' and ''recaptchaprivatekey'' fields in the manage authentication common settings, and the changes saved.


===Denied email===
In addition to setting reCAPTCHA keys, email-based self-registration should be set as the self registration authentication plugin in the manage authentication common settings and the reCAPTCHA element should be enabled in the [[Email-based self-registration]] settings.
domainsdenyemailaddresses  Default: Empty


To deny email addresses from particular domains list them here in the same way. All other domains will be accepted. eg hotmail.com yahoo.co.uk
==Locking profile fields==
To prevent users from altering some fields (e.g. students changing profile information to inappropriate or misleading information), the site administrator can lock profile fields.


[[Image:Authent-data-map-fname.jpg|Data Mapping Options]]
*These fields are optional. You can choose to pre-fill some Moodle user fields with information from the LDAP fields that you specify here.  If you leave these fields blank, then nothing will be transferred from LDAP and Moodle defaults will be used instead.  In either case, the user will be able to edit all of these fields after they log in.
*'''Update local''': If enabled, the field will be updated (from external auth) every time the user logs in or there is a user synchronization. Fields set to update locally should be locked.
*'''Lock value''': If enabled, will prevent Moodle users and admins from editing the field directly. Use this option if you are maintaining this data in the external auth system.
*'''Update external''': If enabled, the external auth will be updated when the user record is updated. Fields should be unlocked to allow edits.  Note: Updating external LDAP data requires that you set '''binddn''' and '''bindpw''' to a bind-user with editing privileges to all the user records. It currently does not preserve multi-valued attributes, and will remove extra values on update.


If you are using a mixture of authentication types (such as IMAP and manual), then the fields you lock in the authentication options will only apply to the type of authentication indicated by the drop down box at the top of the screen.  Remember to test the field locking by logging in with the proper type of account!  If you test with a manual account but have set the field locking to apply to IMAP accounts, you will not be able to tell if it worked!


==See also==
==See also==

Revision as of 18:45, 31 July 2008

Location: Administration > Users > Authentication > Manage authentication (or Administration > Users > Authentication prior to Moodle 1.9)


Setting the authentication method

Choosing an authentication plugin in Moodle 1.8 (only shows top of Authentication page)

To set the authentication method:

  1. Access Administration > Users > Authentication > Manage authentication.
  2. On the Manage authentication page, click on the closed eye icon to enable your chosen authentication plugin(s). In Moodle 1.8 onwards, you can choose to use more than one authentication plugin (see Multi-authentication below). Use the up/down arrow icons to arrange the plugins in order, with the plugin handling the most logins at the top of the page.
  3. If you have chosen Email-based self-registration and wish potential users to be able to create their own accounts, select "Email-based self-registration" from the self registration drop-down menu in the common settings section. Potential users will then be presented with a "Create new account" button on the login page.
  4. If you have courses with guest access, set the Guest login button to show.
  5. Click the "Save changes" button.
  6. Click on Settings opposite the authentication plugin(s) you have chosen.
  7. Configure the required settings and click the "Save changes" button.

Multi-authentication

Template:Moodle 1.8From Moodle 1.8 onwards, multi-authentication is supported. Each authentication plugin may be used to find a username/password match. Once found, a user is logged in and alternative plugins are not used. Therefore the plugin which handles the most logins should be moved to the top of the page in order that less load is put on authentication servers.

Common settings

Self registration

If you wish users to be able to create their own user accounts, i.e. self-register, then select Email-based self-registration from the drop-down menu.

Warning: Enabling self registration results in the possibility of spammers creating accounts in order to use forum posts, blog entries etc. for spam. This risk can be minimized by limiting self registration to particular email domains with the allowed email domains setting (see below). Alternatively, self registration may be enabled for a short period of time to allow users to create accounts, and then later disabled.

Note: The Email-based self-registration authentication plugin must be enabled to allow users who previously self-registered to login. Selecting Email-based self-registration as the self registration method allows potential users to self register.

Guest login button

You can hide or show the guest login button on the login page. Hiding the guest login button disables guest access to the Moodle site, however logged-in users can still enter any courses which allow guest access without being required to enrol.

Alternate login URL

This should be used with care, since a mistake in the URL or on the actual login page can lock you out of your site. If you do mess it up, you can remove the entry from your database (table mdl_config) using, e.g., phpmyadmin for mysql.

Forgotten password URL

Template:Moodle 1.9If your lost password handling is performed entirely outside of Moodle (for example, only by a help desk), you can set the url of that service here. Anybody pressing a "lost password" link in Moodle will be redirected to this URL. Note that this will disable all of Moodle's lost password recovery options regardless of authentication method(s) in use.

Allowed and denied email domains

Authentication may be restricted to particular email domains when using Email-based self-registration so that, for example, only students with a university email can login.

(Note: Prior to Moodle 1.9, the allowed and denied email domains settings can be found in Administration > Server > Email.)

ReCAPTCHA

New account form with CAPTCHA element

A CAPTCHA is a program that can tell whether its user is a human or a computer. CAPTCHAs are used by many websites to prevent abuse from bots, or automated programs usually written to generate spam. No computer program can read distorted text as well as humans can, so bots cannot navigate sites protected by CAPTCHAs.

Template:Moodle 1.9From Moodle 1.9.1 onwards, spam protection may be added to the Email-based self-registration new account form with a CAPTCHA element - a challenge-response test used to determine whether the user is human.

ReCAPTCHA keys can be obtained from http://recaptcha.net by signing up for an account (free) then entering a domain. The public and private keys provided can then be copied and pasted into the recaptchapublickey and recaptchaprivatekey fields in the manage authentication common settings, and the changes saved.

In addition to setting reCAPTCHA keys, email-based self-registration should be set as the self registration authentication plugin in the manage authentication common settings and the reCAPTCHA element should be enabled in the Email-based self-registration settings.

Locking profile fields

To prevent users from altering some fields (e.g. students changing profile information to inappropriate or misleading information), the site administrator can lock profile fields.

Data Mapping Options

  • These fields are optional. You can choose to pre-fill some Moodle user fields with information from the LDAP fields that you specify here. If you leave these fields blank, then nothing will be transferred from LDAP and Moodle defaults will be used instead. In either case, the user will be able to edit all of these fields after they log in.
  • Update local: If enabled, the field will be updated (from external auth) every time the user logs in or there is a user synchronization. Fields set to update locally should be locked.
  • Lock value: If enabled, will prevent Moodle users and admins from editing the field directly. Use this option if you are maintaining this data in the external auth system.
  • Update external: If enabled, the external auth will be updated when the user record is updated. Fields should be unlocked to allow edits. Note: Updating external LDAP data requires that you set binddn and bindpw to a bind-user with editing privileges to all the user records. It currently does not preserve multi-valued attributes, and will remove extra values on update.

If you are using a mixture of authentication types (such as IMAP and manual), then the fields you lock in the authentication options will only apply to the type of authentication indicated by the drop down box at the top of the screen. Remember to test the field locking by logging in with the proper type of account! If you test with a manual account but have set the field locking to apply to IMAP accounts, you will not be able to tell if it worked!

See also