Inconsistent/ intermittent user permissions and login issues
Problem
Users face intermittent permissions/ login issues. This can occur for all Atlassian applications the symptoms may include:
Symptom 1
Users are added/removed during every other user directory synchronization.
Symptom 2
Users are show with permissions set correctly, however they can't login. For instance in FishEye/ Crucible you may see that the user has no access even though they belong to a group which has permissions.
Cause
Atlassian Applications do not currently support connecting to load-balanced AD/LDAP servers. Synchronizing between AD/LDAP servers is not supported. Microsoft Active Directory does not replicate the uSNChanged attribute across instances. For that reason, we do not support connecting to different AD servers for synchronization.
Many companies have a single DNS entry (mydomain.mycompany.com) that points to a load balancer that directs traffic to one of many directory servers. (Or, some companies might use DNS round robin.) However, neither the use of DNS round robin nor use of an actual load balancer is supported by Atlassian applications – both approaches to load balancing direct traffic to different servers, which would violate this limitation.
Currently, Atlassian applications only supports connecting to a single directory server, not different (load-balanced) servers.
Related Product Suggestions:
- CONFSERVER-23073Getting issue details... STATUS
- JRASERVER-24133Getting issue details... STATUS
- CONFCLOUD-23073Getting issue details... STATUS
- FE-7017Getting issue details... STATUS
- BSERV-11111Getting issue details... STATUS
Workaround
These workarounds may not help depending on your exact scenario. Please make sure you test these workarounds before implementing them on your production instance. The only sure way to prevent this is to move away from a load balanced AD/ LDAP user directory.
Symptom 1
- Disable the incremental synchronization if possible.
- Attempt to connect directly to one of the LDAP nodes. You may gain some users and lose others depending on which node has the uSNChanged property.
- Delete and recreate the user directory.
- Move the internal directory to the top of the user directory list and add the affected users to a group created in the internal directory. Make sure you have a user in the internal directory you can login with otherwise you may get locked out.
- Move to a Delegated Directory type which will remove the synchronizations from the equation.
- The caveat is that users must login for the first time via the UI in order to synchronise user groups and permissions. This means that if you have users who have access keys in their user profile, they will not be able to push using those access keys until they login via the UI or perform an HTTP(s) git operation.
- The caveat is that users must login for the first time via the UI in order to synchronise user groups and permissions. This means that if you have users who have access keys in their user profile, they will not be able to push using those access keys until they login via the UI or perform an HTTP(s) git operation.
Symptom 2
- Delete and recreate the user directory.
- Move the internal directory to the top of the user directory list and add the affected users to a group created in the internal directory.
Resolution
Move away from a load balanced LDAP/ AD server.