14 March 2011, 14:46

Greetings!
         This summer we're planning to change the LDAP account username reference in Moodle away from sAMAccountName to allow standardization on email address for login. We have a mix of accounts there (mostly LDAP-generated, but some locally-created ones), but we're only doing this for the LDAP-created accounts. We have a SSO-driven Mahara installation which leverages only one-way XMLRPC authentication (Moodle->Mahara), so there is absolute parity between the two systems as to account usernames.
        I'm intending to get a simple AD list of sAMAccountName's from our domain with their associated email addresses, and just run a simple replacement query in Moodle for any record it finds in AD. Is this all I need to do in Mahara? Will SSO continue to work fine? Does anyone know of any "gotcha's" I might be facing with this?
       Thanks!
                  Jeff

14 March 2011, 16:06

...I just did a perfunctory test, updating a single account by hand in the database to see what happened. It worked perfectly in Moodle. However, Mahara created a new account when I came across, with a truncated email address (29 characters) as the username. The original email address had 34 characters. The Mahara database shows 100 characters for the max length of usr/username, so something seems to be happening in code...

20 March 2011, 11:42

Hi Jeffrey,

something's happening in the code :-). In function get_new_username() (lib/user.php) the username is trimmed to 30 characters (or less, if it collides with existing names). According to the commit where the database field is enlarged to 100 characters, this is so it can add '.deleted.<deletion-timestamp>' to the username when that user is deleted.

Anyhow, when users roam from remote systems to mahara, they are identified by the 'remote username'. That remote username is stored in 'auth_remote_user' table, and it's related to a local username (table 'usr') via the 'localusr' filed (it's a foreign key to the usr.id field).

So you could keep local usernames in Mahara unchanged if you wish (I'd change them too), but you'll need to change the remote usernames in Mahara to match Moodle's ones.

This is exactly what we did a few months ago, when we normalised our LDAP users (we had used several naming conventions over time, and it was a real mess). So we had to rename all of them in Moodle and Mahara too (they can only login in Mahara via Moodle SSO, so we had the same problem you have now).

Saludos.
Iñaki. 

20 March 2011, 21:20

Iñaki:
       Thanks so much, once again, for your help.
       I was afraid of that. I would agree, I want Moodle and Mahara in total agreement. So I should run the query on both "auth_remote_user" and "usr," right? What I'm reading from your remarks is that I could just run the upgrade on "auth_remote_user" and I would be OK with authentication, but that the username stored in "usr" would no longer be meaningful. I'm thinking that, if I ever decided to support direct login into Mahara with LDAP, that'd require the same username in both places,. right? (Not positive I'd want to do that, but I'm trying to think ahead.)
       I notice that "remoteusername" in "auth_remote_user" has a field size of 255 characters, so I'm not understanding why the data design provides for 100 characters in the "username" field of "usr." Seems like the easiest solution would be to increase the data size of the latter to match the former, and then modify the function to expand the allowable length of the created username. But I'm guessing that has implications in other places as well. 
       I'm afraid I'm going to have some really big usernames. Our student email format is [email protected], which has 26 characters without a name at all. And I've got some big student names.
       By the way, how much text does the time stamp add? Is this Unix datetime format? We're pretty early in our deployment, so I haven't actually deleted any accounts. (We're actually still working on an "end of life" management design.)
       Should this be submitted to the bug feature/tracker area? At this moment I have a little time...we plan on running the updates late May against our test server, and against production mid-June. But it's late March...don't want to get caught. And if this is a change that needs to be committed to the full install, I'm thinking now's the time. I would prefer that - I'm not excited about protecting code and data modifications against future upgrades.
       Thanks again.
                    Jeff

11 April 2011, 14:21

I found this in the bug tracker (https://bugs.launchpad.net/mahara/+bug/548165), and updated that to reflect my need here. It shows the bug as unassigned, incomplete, and (before I added to the bug tracker entry) expired. I'm now under a time crunch on this, so I'm hoping someone is watching who might be able to help! By the discussion in the bug tracker entry, it would seem non-controversal and maybe even simple...

Thanks.

11 April 2011, 18:47

Hi Jeffrey,

I've replied on the tracker and I will take care of it.

Cheers,

Francois

15 June 2011, 20:50

Just a thank-you...we upgraded to 1.4, ran the username migration, and everything seems to be running great. Thanks so much for helping to push this through!

16 June 2011, 13:06

We are running an instance of Moodle 1.9 and Moodle 2.  Our connection to Mahara from 1.9 is as a Network Server.  We've turned on the ePortfolio option in Moodle 2 and have it pointing to the same Mahara instance.  When we select the Mahara link in Moodle 2 it creates a second user account and adds a 1 after the name.  Any assistance on how to resolve this would be greatly appreciated.

Thanks,

Ellen

16 June 2011, 14:24

Hi Ellen

We have a similar setup, a Moodle 1.9 and a Moodle 2.0 (both using the same AD/LDAP authentication) connected to a single Mahara 1.4

We followed the instructions in this thread: http://mahara.org/interaction/forum/topic.php?id=2254

Needed to add the following to config.php

$cfg->usersuniquebyusername = true;

BUT do be aware of the warning that goes with it

                // When turned on, this setting means that it doesn't matter 
                // which other application the user SSOs from, they will be 
                // given the same account in Mahara.
                //
                // This setting is one that has security implications unless 
                // only turned on by people who know what they're doing. In 
                // particular, every system linked to Mahara should be making 
                // sure that same username == same person.  This happens for 
                // example if two Moodles are using the same LDAP server for 
                // authentication.
                //
                // If this setting is on, it must NOT be possible to self 
                // register on the site for ANY institution - otherwise users 
                // could simply pick usernames of people's accounts they wished 
                // to steal.