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

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.