by Emma Richardson.
Did you select to update existing accounts in the upload csv page? On the preview page, does it throw any errors?
↧
Re: Changing to OpenID authentication with csv
↧
MNET authentication generates identity theft problem
by David Bogner.
We have got the following configuration for our Moodle installations. We use one Moodle installation as Identity Provider (IdP). This instance is just used for storing all the user profiles. Then we have several remote instances. These are connected to the IdP instance.
Right now everything is fine, because on the IdP we use only manual authentication and e-mail based self registration. So all users stored in mdl_user have a unique username.
But that will change. We are going to activate an LDAP user authentication on the IdP. That has as consequence: the field username in mdl_user will not be unique anymore. Still no problem, because Moodle can handle that (identifying users with combining username and mnethostid or auth method).
But now to the problem: Having the same username for different users on the IdP will result in the following problem on remote hosts: In order to identify a user, Moodle uses 2 things
username
mnethostid
But there will now be different users, that fulfill these criteria. Example:
User A: username = myusername, authentication: LDAP
User B: username = myusername, authentication: local
These 2 users are still identified as 2 different users on the IdP, but will share a user account on the remote platform. Users who find out the username of an admin can now easily gain admin rights too.
We have about 25.000
users on our platform and the additional LDAP authentication will add
3000 more users. Any solution or workaround for this problem is
highly appreciated. Link to the Moodle installation (IdP): http://onlinecampus-profil.virtuelle-ph.at/
↧
↧
Re: MNET authentication generates identity theft problem
by gabriel rosset.
Hi David,
I'm afraid you need to develop a patch for now.
Even if there is an event fired when an account is duplicated by MNet into a remote moodle site (only in recent Moodle version, see : https://tracker.moodle.org/browse/MDL-53401), this will not be enough to completely handle the MNet landing process.
↧
Re: MNET authentication generates identity theft problem
by David Mudrák.
Still no problem, because Moodle can handle that (identifying users with combining username and mnethostid or auth method).
I don't think this is a right assumption. Moodle relies on "mnethostid + username" be unique. There is even a unique index in the users table created like that. The mnethostid is an identifier of the user's home server, a server acting as the user's IdP. So in your case all your LDAP users will have the same mnethostid so they all have to have unique username.
↧
Re: MNET authentication generates identity theft problem
by David Bogner.
Thank you David and Gabriel. So the real problem will be combining LDAP authentication with exisiting e-mail based self registration and manual accounts. It is very likely, that the newly connected LDAP system contains usernames which are identical to already existing usernames in Moodle.So I will try to outline what happens, when we activate the LDAP authentication, where some of the usernames are the same.
- Existing user in Moodle has auth method manual, username: myusername
- LDAP user: does not have a Moodle account yet, as LDAP was activated later on and accounts are not synced
2 scenarios:
- Manual login is on top of the list in "Manage authentication" and will be used first for auth process
- LDAP login is used on top of the list in "Manage authentication" and will be used first for auth process
The result of the authentication process for these 2 scenarios would be
- User with manual login can log in. The LDAP user with the same username will never be able to log in.
- When the LDAP-user tries to log in, credentials will be checked on the LDAP server, or will there be first a lookup in mdl_user, if the user already has an account created in mdl_user? In that case this will not be different than 1.)
If the auth process is checking first credentials on LDAP and then tries to move the user data from LDAP to Moodle, then either the existing manual account will be overwritten, or ther will be a conflict between the auth method from the manual user and the LDAP user.
So coming to a conclusion:
Activating LDAP after already having created Moodle internal accounts, is not possible without having potentially conflicting (identical) usernamesWhat to do in such a situation?
The problem is, that the additional users connected via LDAP are users from a teachers network, that should use their LDAP accounts for authentication against a new Moodle instance, ideally connected to the existing IdP.
Right now I only see 2 solutions:
- Not connect LDAP and require all the users to create yet another account for Moodle
- Activate LDAP only on the Moodle platform the teachers network will use and not on the Moodle instance used as IdP (That will probably result in confused users, authenticating once with the IdP, another time with LDAP and then wondering where all the course enrollments have gone....)
- Not provide SSO for the new Moodle instance of the teachers network.
- Program some sort of workaround (username prefix, etc.)
Any other solution would be highly appreciated.
Kind regards,
David
↧
↧
Re: Delete multiple users
by Hitesh Patel.
Please follow these steps. Go to...
Site Administration>Users>Accounts>Bulk User Actions
Add to selection the users you want to delete from Available list to to Selected list.
Choose Delete against With selected users and press Go.
Thank you!
↧
Re: MNET authentication generates identity theft problem
by gabriel rosset.
Hi David,
I'm in a case quite close than yours, personnaly I would recommend you to make a little local plugin which pre-synchronize all your LDAP users in your Moodle IdP. Like this you could be able to completely define your user federetion policy (merge manual account with LDAP account if necessary or update manual account username, etc.)
By this way all your LDAP users will be pre-recorded in your IdP and for example you could consider to forbid some of them to jump over MNet (see admin menu > Moodle Network > SSO access).
Hope this helps.
↧
Re: MNET authentication generates identity theft problem
by David Bogner.
Hi Gabriel,
thank you for that advice. In fact I have discovered, that it will be easier to manage: All the users of the LDP-authentication use the following username:
firstname.lastname@example.com
There are no currently no users with a username containing @example.com. So the challenge will be to prevent manual accounts and e-mail based self registration accounts to use @example.com in their usernames. This guarantees unique usernames.
I just have to look, if we modify the moodle core a little bit or if the validation of newly created usernames can be overriden via a local plugin.
Kind regards,
David
↧
Re: CAS SSO and retrieving user profile attributes
by Philippe Siwinski.
Hi Richard,
I have the exact same question, did you get more knowledge about this situation ?
I have seen an old page that mentions plans for a custom CAS plugin (without ldap) that retrieve CAS attributes :
Future: Custom CAS Plugin with Attribute Support
Can anyone provide some direction ?
Thanks, Philippe
↧
↧
Importing same user with different username auth/db
by Stephan Tedesco.
We are having Moodle 1.9 and are importing users from database using the auth/db plugin. Because the users in the database were coming from different domains of the Active Directoryand the usernames were not unique, we adapted while ago the plugin in Moodle, so the users were being imported as follows:
domainname/username
$sql = $select ." FROM {$this->config->table}" ." WHERE CONCAT(DOMAINS, CONCAT('/', {$this->config->fielduser})) = '".$this->ext_addslashes($extusername)."'";For example, the user John Smith, who is coming from the emea domain of the AD with the username john.smith, was imported as:
emea/john.smith
This was done in order to prevent users with the same username in different AD-domains to be imported in Moodle as one user.
Now our university "cleaned" the Active Directory and will use one global domain, which will be globaluni. In this case we will not need to create users from the external database table with the domain-prefix, as every user will have unique name in it.
When the next sync between the database table and Moodle takes place it will do the following:
deleteall users from the old domains, because they will be unrecognizable (for exampleemea/john.smithwill be deleted in Moodle, because he is not in the new database with that name)createnew users from the new global AD-domain (for exampleglobal/john.smithwill be created)
How to prevent the deletion and to add the new usernames to the correct profiles? Is that possible only manually - adding the new username to the old profile and deleting the new one, so the next sync will affect the old profile and wont create new?
Thanks for suggestions, as the change in the userdata was confirmed to us on short notice...↧
Re: CAS SSO and retrieving user profile attributes
by Richard Trout.
Hi Philippe
Sadly I couldn't find anything or anyone to help me, so I dug in further by myself.
It seems to me that the CAS (SSO) plugin was in more common use earlier in Moodle's lifetime, and why it was in core. CAS has evolved, but the Moodle plugin hasn't.
From what I could tell, the plugin really expects to be used in conjunction with LDAP, as it is the only method it supports to retrieve the user attributes for the Moodle profile. I found CAS works well for authentication. But without parsing user attributes (or retrieving via LDAP) the user is prompted to re-enter the information themselves. It doesn't appear like this is a use-case that Moodle has a good workflow for without modification.
So if you can use CAS _and_ LDAP it would be good, without LDAP you really have to do your own research.
I think SAML
I saw that plugin too, but you'd need to find who was involved with it. In open source projects, some things are often abandoned and that was the assumption I made.
I found CAS works well for authentication.
Regards, Richard.
↧
Re: CAS SSO and retrieving user profile attributes
by Dave Perry.
Touching on the SAML point, if you have Shibboleth IdPs in your infrastructure then you can use that. I know you can tie Shibboleth IdPs to CAS, but have no experience of this or which way(s) round that goes.
We use Shibboleth for eResources and Google Apps (whatever it's called now) SSO, and I have proved it works on a test site (passing through all the attributes I configured our IdP to release). Admittedly that uses LDAP as its attributes/credentials source.
But until we have our Shibboleth picking up AD logins from the desktop, we're sticking with AD authentication for moodle as that's SSO from the desktop (unless you're on a Mac - we aren't using the Kerberos Apache plugin and the Macs don't talk NTLM).
↧
Re: How to use multiple LDAP servers with Moodle 1.8
by Michael Lynn.
We are successfully using the clone script with Totara 2.7.6 (Moodle 2.7.9). It works really well.
A problem we have is that sometimes users have duplicate names in the different domains:
Example (names anonymised):
ldap - domain1\jsmith1 (Jonathan Smith)
ldap2 - domain2\jsmith1 (James Smith)
Jonathan Smith logs in and their account in Moodle is created.
When James Smith comes along their account isn't created in Moodle and they are logged in as Jonathan Smith.
This is because the username must be unique.
Question 1:
Am I right in saying that there is no way to map or modify the username created to include some other attribute e.g. country code in the Moodle username?
It might solve the problem if the username was generated with the country code as a prefix:
e.g. uk_jsmith1, us_jsmith1 etc.
We are using NTLM so the username is derived from SAMAccountName.
I can't see how we could even customise the authentication plugin because in auth.php in user_signup() $user->username is already populated with no access to other properties such as countrycode (mapped to c in the Active Directory attributes).
↧
↧
Re: Importing same user with different username auth/db
by Iñaki Arenaza.
If you already have a list of the mappings from the old usernames to the new ones (as you state that there were some usernames used in more than one domain, when the cleaning took place some or all of those usernames got renamed to new ones), you can create a CSV file with the renaming details, and then use the "Upload CSV file" authentication plugin to rename all the users in a single batch.
Moodle 1.9 is *really* old (and out of support, even security support, since a loooong time), but as far as I remember it already had all the functionality you need for this renaming. Have a look at https://docs.moodle.org/19/en/Upload_users#Allow_renames and https://docs.moodle.org/31/en/Upload_users#Allow_renames to see how it works.
That way, the new sync will already see the new usernames, and will keep them untouched (unless you have configured the auth/db plugin to update some other user details like email, country, etc.).
Saludos.
Iñaki.
Moodle 1.9 is *really* old (and out of support, even security support, since a loooong time), but as far as I remember it already had all the functionality you need for this renaming. Have a look at https://docs.moodle.org/19/en/Upload_users#Allow_renames and https://docs.moodle.org/31/en/Upload_users#Allow_renames to see how it works.
That way, the new sync will already see the new usernames, and will keep them untouched (unless you have configured the auth/db plugin to update some other user details like email, country, etc.).
Saludos.
Iñaki.
↧
accounts created with duplicate email by different authentication methods
by Paul Nijbakker.
Hi,
We are testing a combination of LDAP and Shibboleth authentication and assumed that users who are already enrolled in Moodle with an LDAP authenticated account would not be able to log in via Shibboleth, because that would create an account with identical email address, which is not allowed in our Moodle 3.1 installation. However, we find in our tests that Moodle does not block the creation of accounts with duplicate email addresses, even though it is not allowed in the authentication settings, which would lead to users with multiple accounts.
Am I missing something? How can I enforce that an authentication plugin cannot create accounts with the same email address as an existing account created via another authentication plugin?
Rgrds,
Paul.
↧
Re: accounts created with duplicate email by different authentication methods
by Emma Richardson.
Have you tried reordering the authentication methods. If LDAP is above Shibboleth in the authentication management list, then Moodle should search it first.
However, if your users have different usernames for each method this will cause an issue and I do not think there is a way to stop an LDAP user from logging in with Shibboleth.
You might try the use email as username option - that might stop it but they would still have to try and log in with their email address instead of their username.
↧
Migrating LDAP to Shibboleth
by Ben Steeples.
Hi all,
Has anyone successfully migrated from using LDAP to Shibboleth? Did you document this process?
We are currently exploring this option for on-site SSO, but we are puzzled as to how best to replace the LDAP CLI Sync script to pre-load accounts into Moodle. Our current thinking is to run the LDAP sync script as before but bounce the accounts between LDAP and Shibboleth authentication at a database level (updating the mdl_user table).
Any thoughts gratefully received.
Thanks,
Ben
↧
↧
Re: Migrating LDAP to Shibboleth
by Marcus Green.
What is your reason for moving away from LDAP? Are you going to move to pure Shibboleth or a product that wraps Shibboleth (e.g. OALA)
↧
Re: Migrating LDAP to Shibboleth
by Ben Steeples.
We're moving away from LDAP to Shibboleth to get 'proper' single-sign-in. ie. users should only be asked to sign in once and their credentials follow across multiple services; rather than the current situation of using the same credentials multiple times. It also means that other external services which rely on Shibboleth (via Moodle) should me more seamless.
We're going for pure Shibboleth via shibd and Apache with mod_shib.
↧
Re: Importing same user with different username auth/db
by Stephan Tedesco.
Thank you for the reply Iñaki,
I will test it and give you feedback, so we have the problem documented in the forums.
Cheers,
S
↧