Error:
11:22:42,426 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] remote username [ KaaaE ] casing differs from local username [ kaaae ]. User details will be kept updated, but the username cannot be updated 11:22:42,426 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] remote username [ NPtest ] casing differs from local username [ nptest ]. User details will be kept updated, but the username cannot be updated 11:22:42,426 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] remote username [ PRconf ] casing differs from local username [ prconf ]. User details will be kept updated, but the username cannot be updated 11:22:42,427 QuartzWorker-1 WARN ServiceRunner [atlassian.crowd.directory.DbCachingRemoteChangeOperations] remote username [ RaSh ] casing
Steps to Reproduce:
1) Create a Crowd internal directory
2) Create a user in that directory named 'dbtte'
3) Add that user to the 'jira-users' group
4) Confirm that that user can log in to JIRA, assign them some issues, etc
5) Connect Crowd to an LDAP directory as a delegated auth directory
6) Create a user 'DBtte' in LDAP
7) Authenticate as the LDAP user via JIRA/Crowd
8) Create a 'jira-users' group for the LDAP directory
9) Add the 'DBtte' LDAP user to 'jira-users'
10) Delete the 'dbtte' internal user
11) Attempt to log in to Crowd
Other steps to reproduce (Crowd Internal Directory only)
- Create a user in Crowd which will be available to the Confluence application using the following details
- Email Address: CamelCaseTC1@test.test
- Active: Checked
- Username: CamelCaseTC1
- FirstName: CamelCaseTC1
- LastName: CamelCaseTC1
- Groups: Group1, Group2, Group3
- Within Confluence, force a Crowd Directory Sync & confirm that the user exists with the correct group memberships
- Back in Crowd, delete the previous user
- Create a user in Crowd which will be available to the Confluence application using the following details, but with the username.tolower() & an additional group membership
- Email Address: CamelCaseTC1@test.test
- Active: Checked
- Username: camelcasetc1
- FirstName: CamelCaseTC1
- LastName: CamelCaseTC1
- Groups: Group1, Group2, Group3, Group4
- Within Confluence, force a Crowd Directory Sync (or two) & wait for the hibernate SQL exception to appear
Workarounds
- Set all users and groups that experience this issue back to the original casing, specified in 'local username' or 'local groupname'.
- Disable the directory by unticking 'Active'. Create a new directory, copying the settings of the existing directory, and sync that. When you're satisfied that everything has come across correctly and you will not be missing any users/groups/memberships, remove the old directory.
- incorporates
-
CWD-3773 Directory synchronisation fails when the name of a group changes in case
-
- Closed
-
- is duplicated by
-
CWD-2893 When sAMAccountName casing does not match cn (User Logon Name (pre-Windows 2000) does not match User Logon Name), or casing of a user or group name has changed from original casing, synchs fail and access is affected
-
- Closed
-
- relates to
-
CONFSERVER-25022 Changing username case in LDAP causes external group memberships to disappear
-
- Closed
-
-
CONFSERVER-28190 Adding a user in Confluence to a group in a Read/Write JIRA User Directory results in failed synchronisation
-
- Closed
-
-
CONFSERVER-25646 Mixed case usernames can break connection between Confluence and JIRA for User Management
-
- Closed
-
-
JRASERVER-29025 Mixed case usernames breaks the connection between JIRA and LDAP for User Management
-
- Closed
-
The fix in Crowd was to convert members and groups to lowercase when deciding which memberships needed to be synchronised. Without that we could have tried to recreate memberships that already existed.