User from Active Directory (AD) Not Synchronizing to Jira
Platform Notice: Data Center Only - This article only applies to Atlassian apps 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
Summary
Symptoms
A user exists in the Active Directory (AD) and can be found using an LDAP browser, but they are not appearing in Jira.
Full synchronizations with the User Directory server complete without errors in the logs.
*******************
SYNCHRONIZING START
*******************
2024-11-19 17:29:06,804+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] FULL synchronisation for directory [ 10000 ] starting
2024-11-19 17:29:06,851+0000 CrowdUsnChangedCacheRefresher:thread-2 INFO [c.a.c.d.synchronisation.cache.UsnChangedCacheRefresher] found [ 0 ] remote groups in [ 32ms ]
2024-11-19 17:29:08,429+0000 CrowdUsnChangedCacheRefresher:thread-1 INFO [c.a.c.d.synchronisation.cache.UsnChangedCacheRefresher] found [ 3033 ] remote users in [ 1610ms ]
2024-11-19 17:29:08,601+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 3033 ] users for delete in DB cache in [ 172ms ]
2024-11-19 17:29:08,601+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned for deleted users in [ 172ms ]
2024-11-19 17:29:08,726+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanning [ 3033 ] users to add or update
2024-11-19 17:29:08,726+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] scanned and compared [ 3033 ] users for update in DB cache in [ 125ms ]
2024-11-19 17:29:08,726+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronised [ 3033 ] users in [ 125ms ]
2024-11-19 17:29:08,741+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 0 ] groups for delete in DB cache in [ 15ms ]
2024-11-19 17:29:08,741+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] scanning [ 0 ] groups to add or update
2024-11-19 17:29:08,741+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteChangeOperations] scanned and compared [ 0 ] groups for update in DB cache in [ 0ms ]
2024-11-19 17:29:08,741+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DirectoryCacheImplUsingChangeOperations] synchronized [ 0 ] groups in [ 0ms ]
2024-11-19 17:29:08,788+0000 Caesium-1-4 INFO ServiceRunner [c.a.crowd.directory.DbCachingRemoteDirectory] FULL synchronisation complete for directory [ 10000 ] in [ 1984ms ]
2024-11-19 17:29:13,911+0000 https-openssl-nio-443-exec-186 url: /secure/admin/ViewLogging!markLogs.jspa; user: john.doe INFO john.doe 1049x9008592x3 irkcac 192.168.1.25 /secure/admin/ViewLogging!markLogs.jspa [c.a.j.util.log.LogMarker]
*****************
SYNCHRONIZING END
*****************
Diagnosis
Verify User Visibility in AD:
Confirm the user exists in the AD using an LDAP browser (e.g., Softerra LDAP Browser) and has all required attributes (e.g., sAMAccountName, mail, etc.).
Ensure the user is within the scope of the configured User Directory base DN.
Check for Internal Directory Conflicts:
Search Jira for an existing Internal Directory user with overlapping attributes (e.g., the same email address).
Note any differences in usernames between the Internal Directory and AD accounts.
Inspect LDAP Filter:
Review the User Directory configuration in Jira to identify the LDAP filter being applied.
Example filter: (&(objectCategory=Person)(sAMAccountName=*)(!(memberOf=cn=UserPWDNeverExpires,ou=ControloUsersDisabled,OU=Groups,DC=pt)))
This filter:
Includes objects with objectCategory=Person.
Requires a non-empty sAMAccountName.
Excludes users who are members of a specific group (e.g., UserPWDNeverExpires).
Ref.: https://confluence.atlassian.com/kb/how-to-write-ldap-search-filters-792496933.html
Perform an LDIF Export:
Use an LDAP browser to export an LDIF file with the same filter used in Jira.
Check if the user appears in the export. If not, the filter or group membership may be excluding them.
Ref.: https://confluence.atlassian.com/jirakb/how-to-export-ldif-with-microsoft-ldifde-420970805.html
Analyze Logs:
Mark the logs with timestamps or tags (e.g., SYNCHRONIZING START and SYNCHRONIZING END) during a full synchronization and review for subtle errors or skipped users.
Cause
The most likely cause is that the user is being excluded by the LDAP filter in the User Directory configuration. For example:
The user is a member of a group explicitly excluded by the filter (e.g., memberOf: CN=UserPWDNeverExpires,OU=ControloUsersDisabled,OU=Groups,DC=pt).
This results in the user being omitted from synchronization, even though the AD connection and full synchronization appear successful.
Additional potential causes:
Internal Directory Conflict: The presence of an Internal Directory user with the same email address may interfere with synchronization logic, though this is less likely if usernames differ.
Scope Issue: The user might reside outside the base DN configured in Jira, though this is unlikely if they are visible in an LDAP browser under the same directory.
Solution
Resolution
Validate the LDAP Filter:
Check the filter in the Jira User Directory configuration (e.g., (&(objectCategory=Person)(sAMAccountName=*)(!(memberOf=cn=UserPWDNeverExpires,ou=ControloUsersDisabled,OU=Groups,DC=pt)))).
Confirm whether the user’s group membership (e.g., UserPWDNeverExpires) is causing exclusion.
Test the Filter:
Perform a search in an LDAP browser using the same filter and base DN as Jira.
Example search:
Base DN: OU=Users,OU=LIS OU,DC=ANA,DC=pt
Filter: (&(objectCategory=Person)(sAMAccountName=*)(!(memberOf=cn=UserPWDNeverExpires,ou=ControloUsersDisabled,OU=Groups,DC=pt)))
Export the results to an LDIF file and verify if the user is included.
Adjust Group Membership:
If the user is excluded due to group membership:
Remove the user from the excluded group (e.g., UserPWDNeverExpires).
Perform a full synchronization in Jira and verify the user now appears.
Handle Internal Directory User (Optional):
If an Internal Directory user exists with the same email:
Deactivate or delete the Internal Directory user to avoid conflicts.
Ensure the AD user is correctly synchronized afterward.
Confirm Resolution:
Search for the user in Jira to confirm they are now visible and can log in.
Monitor logs during the next synchronization to ensure no related issues persist.
Was this helpful?