-
Bug
-
Resolution: Fixed
-
Medium
-
2.7, 2.7.2
-
None
-
Standalone Application
Apache Tomcat/7.0.40
Ubuntu Server 12.04 LTS
Java: 1.7.0_45
First of all: We have installed the version 2.7.0. I can't find this one in your "Affects Version" list.
Most of the description you can find here in this answer: https://answers.atlassian.com/questions/296167/crowd-removing-group-from-user-with-in-username-results-in-error?page=1
We are using Crowd for custom applications. Underlying directory is Open-LDAP running on the same server as the crowd installation.
My last post in the answer identifies the main problem:
I tested with activated caching function for LDAP-Directory for a user with already existing group.
1. Removed Group from user
2. Error occurred but group was removed in the crowd web console
3. Looked direcly into LDAP. Group was still attached to the user!
4. Clicked on synchronisation
5. On crowd web console: Group was readded to user by synchronisation
So the problem seems to be with the LDAP connector.
It is customer requirement for this username format and very important that crowd supports this. Our customer bought the biggest license and wants to migrate from another system to crowd.
With this bug we have a showstopper!
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page"){kind=icon}
[CWD-3923] Removing group from user account with '#' in username results in error
Lutz Galich
added a comment - We tried to fix this by changing the spring-LDAP-jar directly in the WEB-INF/lib from version 1.3.1 to 1.3.2. After that we restarted the crowd-server.
Result: The bug is NOT fixed.
We know that this is not the common way to do this, but we need a hot fix for this bug!
Lutz Galich
added a comment - We tried to fix this by changing the spring-LDAP-jar directly in the WEB-INF/lib from version 1.3.1 to 1.3.2. After that we restarted the crowd-server.
Result: The bug is NOT fixed.
We know that this is not the common way to do this, but we need a hot fix for this bug! Lutz Galich
added a comment - Could you estimate the date of next Crowd release? This fix will be present in the next release of Crowd. With naive matching disabled, the only change is to upgrade Spring LDAP from 1.3.1 to 1.3.2.
On investigation, this is caused by a bug in the Spring LDAP library (LDAP-229 - "Default DN parser does not handle hash/sharp symbol correctly"). This fix is present in Spring LDAP 2.0 (which will be upgraded to in CWD-3824), but also a 1.3.2 point release.
A fix for the 2.7 branch would be to make and verify that upgrade.
Crowd 2.8 is not listed in the download area.
Apologies for the confusion. This is the current name for the development version, which is not yet publicly available.
Lutz Galich
added a comment - Crowd 2.8 is not listed in the download area. Is it a beta version? 
Avi Knoll (Inactive)
added a comment - I can confirm that on my setup (openldap-2.4.39), disabling Naive DN Matching does not fix the problem with Crowd 2.7.0 or 2.7.2. In fact, disabling Naive DN Matching results in the user not being shown as a member of the group at all.
Avi Knoll (Inactive)
added a comment - I can confirm that on my setup (openldap-2.4.39), disabling Naive DN Matching does not fix the problem with Crowd 2.7.0 or 2.7.2. In fact, disabling Naive DN Matching results in the user not being shown as a member of the group at all. Lutz Galich
added a comment - I disabled this option for the openLDAP directory and tried to remove a group from the user with #.
This results in the same error, also in log.
Furthermore we did a restart of the crowd server. This also results in the same error.
Lutz Galich
added a comment - I disabled this option for the openLDAP directory and tried to remove a group from the user with #.
This results in the same error, also in log.
Furthermore we did a restart of the crowd server. This also results in the same error. Crowd has two modes for matching DNs; strict and naive (Using Naive DN Matching).
Naive matching is generally faster, but relies on the directory to always provide the same representation of equivalent DNs; looks like this is a case where they differ.
If you disable 'Use naive DN matching' for your directory then the comparison will succeed.
> We know that this is not the common way to do this, but we need a hot fix for this bug!
Can you follow up with Support, please? They'll be better placed to take a look at your specific case.