powered by Jive Software

LDAP username trimming


I have successfully installed and configured Jive using an internal database and now have changed my config to use an existing LDAP database.

For anyone wanting another perspective on a linux install (debian Sarge) my docs are here http://www.corenetworks.com.au/doku.php?id=jive_messenger_and_java

This LDAP database uses a users full email address as the login name. From what I can tell, Jive (or Jabber in general) requires a username without the @domain component as the Jabber client adds that itself.

So my question is how can I use the user@domain login name from the LDAP database? Can Jive trim the username user@domain (that the LDAP database has s the username) so it recognises the user when the Jabber client passes “user@domain” to it?

Currently if I try to login with user@domain through the Jabber client, it will pass user@domain@domain to JIVE which doesnt like it at all.

If I try and login using user@domain, Jive is only looking for “user” which it never finds

Debian Sarge

Pandion client


any suggestions appreciated.



The typical way to deal with this issue is JID escaping. Basically, it escapes the @ symbol so that it’'s not confused with the real @ symbol in a normal address. We already have decent support for JID escaping in the LDAP code (although there may be bugs). However, your client may need to do the escaping as well, at least for the case you describe below. You may want to contact the Pandion authors to discuss.



Thanks Matt, I m really interested in solving the problem as effectivly as I can now rather than waiting for a fix that might take a while but I will keep that in mind.

What I ended up doing was using the cn name field which would seem like the normal thing to do but in this case makes a tiny bit of extra work in keeping the information correct.

This extra amount of work pales into insignificance when I look at the quality of the final product I am able to use at no cost thanks to the Jive team.

thanks again



Glad you were able to find a workaround!