Okay, so for a few weeks I have been successfully running an Openfire installation which is grabbing user data from a local OpenLDAP directory server. This has worked fine for several weeks. However, upon cloning the instance (we’re running on Amazon EC2) suddenly everyone finds themselves unable to connect to the new server – 100% authentication failures.
Upon investigation, it is revealed that this is because Openfire is now only able to read some LDAP attributes but not others, for reasons which I am unable to determine. Specifically:
It can read the default “cn” and “sn” attributes and find users properly.
It cannot read the default “uid” or the custom “preferredLogin” attributes of LDAP entries at all. Since we use the “preferredLogin” attribute as a way of handling usernames without exposing their actual UID, obviously this presents us some challenges. (cn and sn contain real names and thus aren’t unique across 2000+ members, making them unusable as JIDs.)
I am kind of at my wit’s end since this WAS working and it clearly isn’t a BASIC LDAP issue – as noted, I can clearly find user entries with certain attributes, LDAP groups are found correctly (based on cn and their specific objectClass), etc.
I enabled debugging but the stuff that prints is full of hexcode and the ASCII portion of the log is not readable or useful. Example:
0…cl…dc=“example”,dc=“com”… …8…preferredLogin…christian…objectClass…companyPerson0…prefer redLogin…0…2.16.840.1.1137188.8.131.52
I don’t really know what that string means, but the only immediate irregularity I note is that the objectClass (companyPerson) has an extra 0 appended for no reason. However, this error exists whether I filter user searches by objectClass or not so that’s probably a red herring.