Moodle
  1. Moodle
  2. MDL-9405

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

    Details

    • Type: Bug Bug
    • Status: 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
    • Rank:
      1769

      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.

      1. auth-ldap-sync-fix-case-18.diff
        0.7 kB
        Iñaki Arenaza
      2. auth-ldap-sync-fix-case-19.diff
        0.7 kB
        Iñaki Arenaza
      3. auth-ldap-sync-fix-case-20.diff
        0.7 kB
        Iñaki Arenaza
      4. duplicate_usernames_removal.sql
        2 kB
        Paul Ortman
      5. ldap-auth-20081015-01.patch
        1.0 kB
        Motoyuki OHMORI

        Activity

        Hide
        Petr Škoda 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 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
        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
        Petr Škoda added a comment -

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

        Show
        Petr Škoda added a comment - Thanks for the info! I will look into it more tomorrow...
        Hide
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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
        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.

          People

          • Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: