No errors thrown in the UI when user attribute update fails with objectClass <-> Attribute mismatch (Custom objectClass)

XMLWordPrintable

    • 1
    • Severity 3 - Minor
    • 0

      This is easily reproducible in Apache Directory Server 1.5 (occurs in all other directory types as well, but we will use the Apache DS example here)

      The user objects in Apache DS are normally created with the following object classes:

      1. inetOrgPerson
      2. organizationalPerson
      3. person
      4. top

      When you create a Apache DS connector in Crowd, Crowd automatically sets the user object class to inetOrgPerson. If you change the user object class from inetOrgPerson to say, organizationalPerson, this issue will then be observed when you edit user attributes such as first name, last name, email, etc. (does not occur with password changes).

      Editing a LDAP user's firstname or lastname will result in a Update Successful response in the UI, but in actual fact, the firstname and last names are not updated in either Crowd, nor the LDAP repository. We should have seen LDAP Error 65 thrown here, due to the attribute <-> object Class mismatch but we do not.

            Assignee:
            Unassigned
            Reporter:
            Foo Sim (Inactive)
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: