Moodle

LDAP authentication plugin might create multiple users in moodle database for one real user.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 1.8, 1.9.2
  • Fix Version/s: None
  • Component/s: Authentication
  • Labels:
  • Environment:
    PHP 5.2.1
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE

Description

Windows LDAP server (a.k.a. Active Directory) does not differenciate alphabet of multi-byte character from alphabet of single-byte character. At least, Japanese Windows LDAP server does not differenciate them.

Under this environment, an user who inputs user name in the alphabet of multi-byte characters is successfully authenticated by LDAP server even though his or her user name actually consits of alphabet of single-byte characters in LDAP. In this situation, LDAP authentication plugin of moodle creates an user record for user name in the alphabet of multi-byte characters into moodle database when an user inputs user name in alphabet of multi-byte characters.

That is, an user record in moodle database might be created duplicatedly.

I attached my patch that fixes the problem, it might look like dirty though.

Attachments

  1. File
    auth-ldap-sync-fix-case-18.diff
    24/Dec/08 7:58 PM
    0.7 kB
    Iñaki Arenaza
  2. File
    auth-ldap-sync-fix-case-19.diff
    24/Dec/08 7:58 PM
    0.7 kB
    Iñaki Arenaza
  3. File
    auth-ldap-sync-fix-case-20.diff
    24/Dec/08 7:58 PM
    0.7 kB
    Iñaki Arenaza
  4. File
    duplicate_usernames_removal.sql
    25/Jan/08 11:13 PM
    2 kB
    Paul Ortman
  5. Text File
    ldap-auth-20081015-01.patch
    15/Oct/08 1:48 AM
    1.0 kB
    Motoyuki OHMORI

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Petr Škoda (skodak) added a comment -

What ldap version did you use? I am getting single byte platform Windows encoding for v2 and utf-8 for version 3.

I have looked at the patch and I do not understand why not just return false if cn and username do not match. I am not sure if we should trust LDAP server that behaves the way you describe.

Show
Petr Škoda (skodak) added a comment - What ldap version did you use? I am getting single byte platform Windows encoding for v2 and utf-8 for version 3. I have looked at the patch and I do not understand why not just return false if cn and username do not match. I am not sure if we should trust LDAP server that behaves the way you describe.
Hide
Permalink
Motoyuki OHMORI added a comment -

Hi, Petr,
Thanks for your care.

I am using LDAPv3 with UTF-8.

You are totally right. I should not trust LDAP server, and I think that just returning false is better than trusting LDAP server as you said.

When I wrote patch, I was in a hurry and I did not consider a lot...

Show
Motoyuki OHMORI added a comment - Hi, Petr, Thanks for your care. I am using LDAPv3 with UTF-8. You are totally right. I should not trust LDAP server, and I think that just returning false is better than trusting LDAP server as you said. When I wrote patch, I was in a hurry and I did not consider a lot...
Hide
Permalink
Petr Škoda (skodak) added a comment -

Thanks for the info! I will look into it more tomorrow...

Show
Petr Škoda (skodak) added a comment - Thanks for the info! I will look into it more tomorrow...
Hide
Permalink
Motoyuki OHMORI added a comment -

I attached safer version of patch that consider the encoding type of LDAP server.

Show
Motoyuki OHMORI added a comment - I attached safer version of patch that consider the encoding type of LDAP server.
Hide
Permalink
Iñaki Arenaza added a comment -

Beware of this patch!. It incorrectly assumes that usernames are mapped to the Common Name attrbute, which is not always true. We should actually check the value of $this->config_userattribute instead. As ldap_find_userdn() already retrieves this value when it searches for the user DN, we can simply return it (though this might impact other places where we use ldap_find_userdn() and don't need this attribute at all).

Saludos. Iñaki.

Show
Iñaki Arenaza added a comment - Beware of this patch!. It incorrectly assumes that usernames are mapped to the Common Name attrbute, which is not always true. We should actually check the value of $this->config_userattribute instead. As ldap_find_userdn() already retrieves this value when it searches for the user DN, we can simply return it (though this might impact other places where we use ldap_find_userdn() and don't need this attribute at all). Saludos. Iñaki.
Hide
Permalink
Paul Ortman added a comment -

I believe I'm running into this type of issue as well. In my situation I've got a custom Perl script that adds users into the PostgreSQL database based on some specific LDAP entries. For 98% of the entries this works great and when the user logs in to Moodle which is pointed at LDAP authentication, everything is fine and their prepared username is used. However for a limited number of users, all of which seem to have nothing "special" about their usernames, something creates a new account in the Moodle PostgreSQL database with the exact same username, but obviously different id. This then really messes up the enrollments already in place.

If I delete the spontaneous account, it will be regenerated the next time the user logs in.

I have to delete the generated account and have to re-enroll the students in their course using the spontaneous accounts that appeared. Luckily I'm able to do that with a SQL script I wrote that detects the spontaneous accounts b/c they don't have their "institution" field set the same way the generated accounts do. I'll attach that script if it is helpful. I also have a snapshot of the database that has several accounts with duplicate usernames.

Show
Paul Ortman added a comment - I believe I'm running into this type of issue as well. In my situation I've got a custom Perl script that adds users into the PostgreSQL database based on some specific LDAP entries. For 98% of the entries this works great and when the user logs in to Moodle which is pointed at LDAP authentication, everything is fine and their prepared username is used. However for a limited number of users, all of which seem to have nothing "special" about their usernames, something creates a new account in the Moodle PostgreSQL database with the exact same username, but obviously different id. This then really messes up the enrollments already in place. If I delete the spontaneous account, it will be regenerated the next time the user logs in. I have to delete the generated account and have to re-enroll the students in their course using the spontaneous accounts that appeared. Luckily I'm able to do that with a SQL script I wrote that detects the spontaneous accounts b/c they don't have their "institution" field set the same way the generated accounts do. I'll attach that script if it is helpful. I also have a snapshot of the database that has several accounts with duplicate usernames.
Hide
Permalink
Paul Ortman added a comment -

This is the SQL script I use on a PostgreSQL database to eliminate accounts with duplicate and identical username fields. It is fairly specific to my institution.

Show
Paul Ortman added a comment - This is the SQL script I use on a PostgreSQL database to eliminate accounts with duplicate and identical username fields. It is fairly specific to my institution.
Hide
Permalink
Paul Ortman added a comment -

I should have also noted that my situation is slightly different than the original reporter's. We use an OpenLDAP server, PostgreSQL database, and Linux hosting with PHP 5.2. The problem occurred with both 1.8 through 1.9b3.

Show
Paul Ortman added a comment - I should have also noted that my situation is slightly different than the original reporter's. We use an OpenLDAP server, PostgreSQL database, and Linux hosting with PHP 5.2. The problem occurred with both 1.8 through 1.9b3.
Hide
Permalink
Motoyuki OHMORI added a comment -

I realized that even 1.9.2+ (2007101522) still has same problem.

Therefore, I fixed my previous patch for 1.9.2+.
In addition, now, this patch does not assume that CN is usename and uses $this->config->user_attribute.

If anyone can evaluate the patch, I will much appreciate.

Motoyuki OHMORI <ohmori@chikushi-u.ac.jp>

Show
Motoyuki OHMORI added a comment - I realized that even 1.9.2+ (2007101522) still has same problem. Therefore, I fixed my previous patch for 1.9.2+. In addition, now, this patch does not assume that CN is usename and uses $this->config->user_attribute. If anyone can evaluate the patch, I will much appreciate. Motoyuki OHMORI <ohmori@chikushi-u.ac.jp>
Hide
Permalink
Iñaki Arenaza added a comment -

Hi Paul,

I think I have found the root of your problem (I think Motoyuki OHMORI's is a different problem though). If you are using auth_ldap_sync_users.php to synchronize your users, and you have a database which is case-sensitive when doing comparisons (Postgres and Oracle at least), and any of your users has the vale of the username attribute in mixed-case (like 'John Smith'), the you get duplicate users.

This is because we don't make sure the username attribute value is 'lowercased' after we retrive it from the LDAP server and before we insert it into the database.

We've had this same issue recently in one of our installs with Postgres and the attached patch fixes it, so I'm going to commit the attached patch into 1.8, 1.9 and HEAD anyway. If you could try the patch and see if it fixes you issue too I would be grateful.

Saludos. Iñaki.

Show
Iñaki Arenaza added a comment - Hi Paul, I think I have found the root of your problem (I think Motoyuki OHMORI's is a different problem though). If you are using auth_ldap_sync_users.php to synchronize your users, and you have a database which is case-sensitive when doing comparisons (Postgres and Oracle at least), and any of your users has the vale of the username attribute in mixed-case (like 'John Smith'), the you get duplicate users. This is because we don't make sure the username attribute value is 'lowercased' after we retrive it from the LDAP server and before we insert it into the database. We've had this same issue recently in one of our installs with Postgres and the attached patch fixes it, so I'm going to commit the attached patch into 1.8, 1.9 and HEAD anyway. If you could try the patch and see if it fixes you issue too I would be grateful. Saludos. Iñaki.
Hide
Permalink
Paul Ortman added a comment -

To be honest I've not seen this problem rear it's head recently for us. Although clearly conditions have changed (namely some of our visiting Chinese scholars have since left and we haven't run into multibyte encoding for a while) we haven't seen this problem in the last 6 months at least.

Show
Paul Ortman added a comment - To be honest I've not seen this problem rear it's head recently for us. Although clearly conditions have changed (namely some of our visiting Chinese scholars have since left and we haven't run into multibyte encoding for a while) we haven't seen this problem in the last 6 months at least.
Hide
Permalink
Rosalyn Metz added a comment -

I recently saw in the users list, 4 different users, i noticed that the font was slightly strange for 3 out of the 4 user names. when i went into mysql and pulled up the users (just out of curiosity) it was apparent that it was in some other character set.

i'm using moodle 1.9.4. i have a funky architecture and my newer instances of moodle (1.9.9) aren't showing this problem, but that's most likely because i'm using cas authentication.

i felt like reporting this to be a good citizen, not because i actually need something done (since its not rearing its ugly head for me anymore).

Show
Rosalyn Metz added a comment - I recently saw in the users list, 4 different users, i noticed that the font was slightly strange for 3 out of the 4 user names. when i went into mysql and pulled up the users (just out of curiosity) it was apparent that it was in some other character set. i'm using moodle 1.9.4. i have a funky architecture and my newer instances of moodle (1.9.9) aren't showing this problem, but that's most likely because i'm using cas authentication. i felt like reporting this to be a good citizen, not because i actually need something done (since its not rearing its ugly head for me anymore).
Hide
Permalink
Michael de Raadt added a comment -

Thanks for reporting this issue.

We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported.

If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed.

Michael d;

lqjjLKA0p6

Show
Michael de Raadt added a comment - Thanks for reporting this issue. We have detected that this issue has been inactive for over a year has been recorded as affecting versions that are no longer supported. If you believe that this issue is still relevant to current versions (2.1 and beyond), please comment on the issue. Issues left inactive for a further month will be closed. Michael d; lqjjLKA0p6
Hide
Permalink
Michael de Raadt added a comment -

I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

Show
Michael de Raadt added a comment - I'm closing this issue as it has become inactive and does not appear to affect a current supported version. If you are encountering this problem or one similar, please launch a new issue.

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.