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