AD serach failing with Unable to find User Mapping

[Rick Szczodrowski]

I added some new groups into the Active Directory last week in preparation for using a those new groups to restrict Confluence access.

None of them are showing up in group searches within Confluence even though all tests for LDAP connectivity work ok.

I have run the connection tests and also disabled and enabled the Active Directory in User Directories without any success.

All syncs seems to work, but when I check the log I can see:

Unable to find user mapping for hassenh

It turns out that a number of AD user entries cause issues and java exceptions when queried

Nothing appear to be wrong with these entries in the AD though :-(

[AnnWorley]

Hi Rick,

I understand you are facing a couple of issues. One is that groups you created in AD are not synchronizing over to Confluence. For this,  please double check that the groups are within the search scope of the AD User Directory. They will need to be beneath the Base DN (and additional Group DN if any) and meet the requirements of the group filter you have set up under Group Schema Settings in the User Directory.

The other issue seems to be that users are not in the user_mapping table. For an explanation of the error "Unable to find user mapping for <user>" please see: User unable to login and searching for this user yields NPE error

The guide linked above recommends manually adding the users to to the user_mapping table. In some cases, if your User directory is "Read Only" rather than Read Only with Local groups you will be better off recreating the User Directory with the same settings and disabling (and later deleting) the existing User Directory. This will create a new cache, which will likely include all the user_mapping entries.

If you are using local groups to manage permissions, the memberships will be lost when you recreate the AD User directory.

I look forward to hearing whether the AD groups are in the scope of the Confluence User Directory search, and how you decide to proceed with the user mapping issue.

Thanks,

Ann

[Rick Szczodrowski]

Hi Ann

We are currently working on a clone of the system and have discovered the following:

We built a new Confluence server and exported and imported the Data Base from our 10-user test system which had both JIRA and Confluence installed on it. That may have been the start of our issues. But anyway, If I follow the suggested documentatoin and issue this command:

SELECT * FROM user_mapping where lower_username is null;

I get 21 rows from this table with null lower_username fields
and this query:

select u.* from user_mapping u where u.username in (select nullrecord.username from user_mapping nullrecord where lower_username is null) order by u.username;

I get 39 rows with all except for 2 of those as the duplicates with null entries.

We are re-trying the fixes from the document (CONFSERVER-36018) but in a different orde to see if we can get a  clean system.

My steps will be to delete the external AD directory connections (which seems to drop the users from the cwd_users table) then to stop Confluence, run the set of SQL deletes (for v5.7 and above)  restart Confluence, re-add the AD Directory connection and see if the synchronisation gives us any grief.

The last attempt was not done in that order and resulted in a working synchronisatin but scrolling through the users list ended up eventually crashing with a java error and we are not sure it is related to this.

So we are starting again shortly, I will let you know what happens  :-)

[AnnWorley]

If you recreate the User Directory you don't need to add the users manually to user_mapping. The sync of the new directory should do that. My understanding is that you have missing records, rather than duplicates as described in Duplicates in the People Directory due to duplicates in the user_mapping table

[Rick Szczodrowski]

Hi Ann,

We successfully cleared the invalid mappings using the "workaround 1" from that document and were left with a single duff entry where the lowercase name did not match the username in the mappings table. And in fact the lowercase name it did have, will belong to another user when the synchronisation kicks in. So we copied the username to the lower_username field as it was all lowercase anyways. restarted confluence and redefined the AD directory link and the sync is now working flawlessly...for now :-)

[AnnWorley]

That's a huge relief to hear - thanks for updating the Community so others who run into similar issues can benefit!