Uploaded image for project: 'Openmeetings'
  1. Openmeetings
  2. OPENMEETINGS-144

When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 2.0.0 Apache Incubator Release
    • None
    • ldap authentication

    Description

      When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).

      The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
      This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
      This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.

      Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.

      What do you think ?

      Attachments

        1. UidCnHash.diff
          2 kB
          Thibault Le Meur

        Activity

          People

            solomax Maxim Solodovnik
            lemeur Thibault Le Meur
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: