encoding problem when accessing LDAP


Thread 19687 (and 19884) describes a problem with a forward slash "/" within the userDN:
2006.05.03 16:14:54 In LdapManager.checkAuthentication(userDN, password), userDN is: "CN=Parsell\, Joshua (AJ-East Engineering/Technology),OU=Org Users"...
All my user accounts ... are failing to log in, even though they are found by the initial LDAP search.

Thread 19871 describes problems with a password which contains one ore more "!":
His new password contained the character '!'. To be able to login again he had to change his password to remove the exclamation point (and he was successful).


LDAP / Wildfire


March 11, 2008, 9:13 AM
Mrinal Kalakrishnan
September 14, 2006, 4:22 AM

I'm experiencing this issue as well. My server is running Wildfire 3.1.0 beta, and using shared groups from an Active Directory LDAP server. Does 3.1.0 beta have the same fix as well?

Joe Sherman
September 8, 2006, 7:36 PM

I am still experiencing issues related to this problem... All of my users presense updates to not get broadcasted or atleast the client doesn't update... In order to see accurate presense info you must log off the client and then back on... I have seen this behavior with both Spark (2.0 and 1.0.4) and Exodus... THis has been plagueing me since I started using shared LDAP groups... This time when moving to the newest version I shut down Wildfire unistalled in completely then re-installed a clean version of 3.0.1, and setup the server from scatch... I still have the same issue... Please help...

Gaston Dombiak
July 12, 2006, 2:09 AM

1) Groups can now be retrieved for users whose CN have escaped characters (e.g. comma)

2) Tried to log in using a passwords that contain ! and worked fine under openLDAP. Need further investigation. May be related to something else?

3) AD does not allow DNs to include forward slashes (/). Suggested to remove that special char.

Les Bowen
June 23, 2006, 1:58 AM

and are different bugs. I have no commas in any of my cn fields, and presence updates are not received. The problem goes away when I disable the LDAP configuration. This is a different bug. Similar results, but a different cause. Possible interrelated, but ultimately different.



Gaston Dombiak