If a user tries to log in to Confluence before the record is synchronized with LDAP, then the user is not properly indexed and might not be searchable

Issue Summary

When an user is created in the LDAP and he/she tries to log in to Confluence before a directory synchronization occurs, then the user might not be properly indexed.

As a result, the user will not be available to many services relying on the Lucene index, such as searching, space permissions, page restrictions and others.

Some of the symptoms that could be noticed by Confluence users are:

• Affected users don't appear in the search results.
• Affected users can't be mentioned in pages.
• Affected users can't be searched in the macro configuration panel.
• Affected users can't be assigned to Space Permissions nor to Page Restrictions.
• Affected users can authenticate to Confluence and navigate through Spaces and Pages, as well as create content.

Environment

This bug only occurs if you are using a connector to an LDAP, such as a MS AD.
The issue was reproduced using a test instance of MS AD, but it might happen if you are using any other LDAP supported in Confluence.

The bug is described with a direct connector to AD, but it can be reproducible when there's an external Crowd between Confluence and the LDAP.

This bug was validated on Confluence 6.13.8 and on 7.0.2.
This affects both the Server and Data Center deployments.

Steps to Reproduce

The steps to reproduce are separated in different scenarios that could trigger the bug.

Scenario 1 – new user

In this scenario the user never existed in AD, and then was properly created in the AD and the user tried to log in before a directory synchronization occurs.

Below are the steps to reproduce the bug.

1. Install a Confluence vanilla instance.
2. Configure a connector to AD.
   • Make sure the Update group memberships when logging in option is set to Every time the user logs in.
3. Confirm the initial synchronization worked successfully.
4. In AD, create a new user that is not member of the confluence-users group.
   • The user must not be part of any group that gives the can-use global permission.
5. Log in as the target user before a directory synchronization occurs.
   • The authentication is successful, but the user cannot navigate on Confluence and will receive a Not Permitted page, since the user is not part of the confluence-users group.
   • At this point, the user is added to the Lucene index not as a licensed user.
     
6. In AD, add the target user to the confluence-users group.
7. Log in to Confluence with the target user again before a synchronization occurs.
   • This time the user is able to authenticate and navigate on Confluence.

Expected Results

Confluence triggers an update on the Lucene index, marking the associated record (Lucene document) as a licensed user, since now the user is part of the confluence-users group.
The user is searchable and appears in the People Directory.

Actual Results

The user profile is properly updated in the user directory, but the information in the Lucene index is not updated.
That means the user is not searchable and cannot be found in the People Directory.

Running the directory synchronization will not update the user in the Lucene index, unless something changes on the AD side.

Scenario 1a – new user

In this scenario the user is properly created in AD and logs in after a directory synchronization occurs.

Below are the steps to reproduce the bug.

1. Install a Confluence vanilla instance.
2. Configure a connector to AD.
   • None of the AD groups should confer can-use access.
   • Make sure the Update group memberships when logging in option is set to Every time the user logs in.
   • Make sure the directory in Confluence is configured to auto-add users to "confluence-users"
3. Create a new user in AD
4. Confirm the initial synchronization worked successfully
5. User should appear on the "Users" screen but should NOT be searchable in the index (cannot be at-mentioned, etc.). This is expected.
6. Log in as the new user
7. The authentication is successful and the user has access.
8. At-mention the user, or search for them in the People Directory

Expected Results

After logging in, the user is re-indexed as a licensed user since they belong to the confluence-users group, and as such and can be mentioned and found in the People Directory.

Actual Results

The user is not re-indexed as a licensed user, and so cannot be found in any feature that uses the index. Running the directory synchronization will not update the user in the Lucene index, unless something changes on the AD side.

Scenario 2 – disabled user

In this scenario, the user already existed in AD and was previously (properly) synch'ed with Confluence.
The user is then disabled in AD and then enabled again – a similar problem occurs if the user is deleted in AD and then re-added..
If the user tries to login before the next directory synchronization, then the bug occurs.

Below are the steps to reproduce the bug.

1. Install a Confluence vanilla instance.
2. Configure a connector to AD.
   • Make sure the Update group memberships when logging in option is set to Every time the user logs in.
3. Create an user in AD as part of the confluence-users group.
4. Force a directory synchronization in Confluence.
5. Log in to Confluence as that user.
   • The user should be able to authenticate and navigate through Confluence.
6. In AD, disable the user.
7. Force a directory synchronization in Confluence.
   • At this point, the Lucene index should be updated with this information and the user will not be searchable nor appear in the People Directory.
     
8. Enable the user in AD, but do not trigger a directory synchronization in Confluence.
9. Try to log in as the target user in Confluence.
   • The log in is successful and the user can navigate in Confluence.

Expected Results

Confluence triggers an update on the Lucene index, marking the user record as active, since now the user is enabled in the directory.
The user is searchable and appears in the People Directory.

Actual Results

The user profile is properly updated in the user directory, but the information in the Lucene index is not updated and the user still shows as inactive.
That means the user is not searchable and cannot be found in the People Directory.

Running the directory synchronization will not update the user in the Lucene index, unless something changes on the AD side.

Notes

• Subsequent directory synchronizations (manual or automatic) will not trigger an update of the user's profile unless something changes on the user's attributes.
  • In other words, the affected user will not be re-indexed if nothing changes on the AD side.
  • This is true whether the directory is configured with full or incremental synchronization.
• In a Data Center instance there may be an additional symptom on which all the use cases work fine in some nodes, but it doesn't work on other nodes – for example, an user can be mentioned in all nodes, except one.
  • This could happen if a re-index was manually triggered in specific nodes, which would update the Lucene index with proper information.
• This issue is also reproducible when connecting Confluence to Jira for User Management. If a user is deactivate in Jira, and reactivated later, the user will not be searchable if the user logs in Confluence before a directory synchronisation happens in Confluence side.

Workaround

Try to modify the user details, forcing indexing of that specific user:

1. Go to Cog icon > User management and search for the affected user.
2. Access the user profile and click on Edit Details.
3. Add any sample text to the About Me attribute and click on Submit.
4. After a couple of minutes, check if the user can be searched.

If the above doesn't work, try to force user indexing for all users.

1. Access <Confluence Base URL>/admin/force-upgrade.action
2. In Upgrade task to run select userIndexingUpgradeTask.
3. Click on Force Upgrade.

This will trigger an user indexing task – if using DC, it will be triggered on all nodes of the cluster.

If this doesn't resolve the issue, then it could be a different bug causing it and a full reindex may help.