Can't Log Into Crowd If One Or More LDAP Directories Are Down
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Symptoms
The LDAP Directory exhibits one or more of the symptoms below;
One of the LDAP Servers is down and the Admin is not able to login to the Crowd console.
The LDAP Server details provided to Crowd have changed and the Admin can't login to the Crowd console.
The LDAP Application(s) that were authenticating against the LDAP Server in Crowd are not able to login users.
The connection details for the LDAP server have changed.
Cause
Currently, Crowd's authentication system will work only if all the directories assigned to an application are available. If an Internal Directory and an LDAP Connector Directory are assigned to an Application and the LDAP Server goes off-line or has its IP address changed, Crowd will stop authenticating all the users for that Application (even the ones from the Internal Directory that is still available).
Resolution
This issue has been resolved as of Crowd 2.2.2 CWD-1177 - If one directory mapped to an application fails, the entire app should not be unusable.
If the LDAP Server is going down for maintenance or will have its Connector details changed (URL, IP Address, User DN password, etc), before starting, un-assign the Directory from the Application.
If you notice that the LDAP is down or had its connection details changed, please restore the LDAP server or return its original connection details in order to be able to log into Crowd (if the LDAP Directory was assigned to the Crowd Console Application) and un-assign the directory.
If you have no success fixing the problem on the LDAP side, delete the Crowd Client Application relationship:
Before using the SQL commands below, please ensure that you've backed up your Crowd database.
For Crowd 1.6.1 and earlier:
a. Run the following queries to discover the Crowd Application and the LDAP Directory IDs:
1
2
3
select * from FROM APPLICATION;
select * from FROM DIRECTORY;
b. Shutdown Crowd and then run the queries in the same order that they are displayed:
1
2
3
4
5
delete from APPLICATIONDIRECTORYPERMISSION where APPLICATIONID = XXXX and DIRECTORYID = YYYYYY;
delete from APPLICATIONGROUPS where APPLICATIONID = XXXX and DIRECTORYID = YYYYYY;
delete from APPLICATIONDIRECTORIES where APPLICATIONID = XXXX and DIRECTORYID = YYYYYY;
Replace XXXX by the Crowd Client Application ID and YYYYYY by the LDAP Directory ID
c. Restart Crowd.
For Crowd 2.0.0 and later:
a. Run the following queries to discover the Crowd Application and the LDAP Directory IDs:
1
2
3
SELECT * FROM cwd_application;
SELECT * FROM cwd_directory;
b. Find the APP_DIR_MAPPING_ID at table CWD_APP_DIR_MAPPING using the IDs from steps 1 and 2
1
Select id From cwd_app_dir_mapping Where application_id = ZZZZ and directory_id = WWWW;
c. Shutdown Crowd and then run the queries in the same order that they are displayed:
1
2
3
4
5
DELETE FROM cwd_app_dir_operation WHERE app_dir_mapping_id = QQQQ
DELETE FROM cwd_app_dir_group_mapping WHERE application_id = ZZZZ AND directory_id = WWWW
DELETE FROM cwd_app_dir_mapping WHERE application_id = ZZZZ AND directory_id = WWWW
Replace ZZZZ by the Crowd Client Application ID, the WWWW by the LDAP Directory ID and the QQQQ by the APP_DIR_MAPPING_ID.
d. Restart Crowd
Was this helpful?