Our Jira SD is configured to sync with an LDAP repository. Users from the repository from time to time become "Inactive". After manual re-sync everything gets back to normal.
I was taking a look through the other support case you have for this issue and I found a number of log entries like so:
2019-08-30 22:52:06,731 Caesium-1-2 WARN ServiceRunner [c.a.c.d.ldap.mapper.UserContextMapper] Failed to map attribute <gidNumber> from context with DN <uni=abc1234,ou=People,o=XYZ University,c=US> java.lang.NullPointerException
It's not clear to me if this is a factor in the problem with syncing failing occasionally, but it is so filling the logs that I think it would be best to address that issue first and then see if we can gather updated logs about this sync problem. I found related KB to help with that log message Directory synchronization throws "Failed to map attribute <gidNumber>" From that KB there are steps you can take to avoid or hide that error in the logs:
This WARN message is usually harmless, but there are two ways to solve this issue:
- Make sure that the LDAP user being referred in the WARN message has the
Or, you can use a LDAP filter, as the following example, to only return LDAP users that have the
Perhaps following the 2nd resolution step here might help avoid the source problem, but even if it does not, then by eliminate this kind of error message from the logs will help us to better see other errors/warning in the logs when Jira does attempt to sync.
Also, going forward, since we know you have a support case for this issue, it would probably be best to work on this issue there in the other support portal. We would prefer to not duplicate troubleshooting efforts here if possible. Then once we have a solution on that support case, it would be helpful to Community to update this thread with the steps needed to correct this scenario. That way other users that might have the same problem could potentially find the same solution.
Thank you for looking into it. Unfortunately neither solution for resolving gidNumber issue would work for us, because all our entries do not have this attribute.
I am surprised that Jira is trying to map this attribute given that we have selected to sync users only, without group membership.
We will try to resolve this in the support case and if I will update this thread if it will be resolved. I've asked this question here when we did not yet have support contract.
I understand that you have Jira connected to an external LDAP user directory, and that sometimes these users are marked as inactive. We have seen this problem in Jira before in support. It tends to happen in environments that have a very large number of users/groups to sync over.
To troubleshoot this issue, I would recommend a two-pronged approach to start:
Aside from that approach, we would want to take a closer look at the logs when this happens, say in the $JIRAHOME/log/atlassian-jira.log file. This should have records of the sync process, such as start time, completion, and possibly number of records to sync over. Perhaps with more information we can better advise you on this topic.
Many thanks for your response.
1. We only synchronize about 1000 users from LDAP. Don't sync any groups. Is this considered "very large"? According to Jira, the sync itself takes only about 4 seconds.
2. We sync once every 10 hours (600 min), so the interval is much more than the default.
All inactive users become active again after manual synchronization, however auto-sync does not make them active.
No, 1000 users is not really considered large. And taking 4 seconds to sync seems reasonable given that size. I'm surprised to hear that you might be encountering these kinds of problems syncing ~1000 users and no groups. I take it that you must be using read only with local groups. This way you can at least grant these users group membership needed in Jira to then grant application access. This is helpful to know because we at least know we are not using the LDAP groups here to sync. Maybe there is something else happening in your configuration here.
In your case, I would actually think that the opposite trend for sync interval could be beneficial here. If a sync fails for an unknown reason, what suspect is happening is that those users are getting removed but failed to be added back because the sync fails for a yet unknown reason. In turn, users could have to wait up to 10 hours before another sync might be attempted which would restore them. Given the size of your userbase, it seems like resetting the interval back to 1 hour (60 minutes) might be better here. Unless this sync is putting a high overhead/strain on the LDAP server, it feels like this might help avoid the problem in general.
While we might be able to learn more about this problem if we can look at the $JIRAHOME/log/atlassian-jira.log file at a time when this sync fails, an alternative approach could be to move away from using the syncing LDAP directory type altogether, and instead create a delegated LDAP directory within Jira. This does not sync users, but instead when a user attempts to login, it looks up that user account in LDAP and adds them to Jira if they provide the correct credentials. More details in What is the Difference between Connector and Delegated LDAP User Directories?.
Thank you for your response.
We are using "read-only with local groups mode".
I am not sure that changing interval will help in this case, mostly because i happened to check on it a few minutes after auto sync was performed (according to the "Last synchronized..." message) and there still were some inactive users. Also the same message is always says that the sync completed successfully.
Would you help me to find answer to the following questions:
We cannot use delegated LDAP because we would like to be able to use users who have not (yet) logged in to Jira SD (for approvals, assignments etc).
I have changed some of the timeouts yesterday and so far no users were marked inactive. Maybe it has fixed the issue.
Thank you very much.
I will try to answer your questions here as best I can:
Why is there a mechanism to make users inactive? What purpose it supposed to serve?
If Jira fails to complete a sync to the LDAP server, it does not know what users actually exist there. Since Jira is then actually dependent on being able to contact that user server (LDAP) to authenticate these accounts, it needs to be able to see which users exist there. Another reason this mechanism exists is to make sure that users don't remain active in Jira, when that user has been disabled/deleted from LDAP. It certainly appears that a failed sync is behaving much like a set of users that are simply not found in LDAP.
How manual and auto syncs are different? - Why would manual sync fix the issue but not the auto?
Auto syncs are being run on a schedule within Jira. This happens based on the settings in that user directory configuration in Jira. This sync is being run by the scheduled services in Jira. But a manual sync is called by a Jira admin, it is also not run on a set interval, but instead it runs right now. I think one of the major differences in the way these two are different in your environment could be just the time of day each sync runs.
I could see a scenario when say the LDAP server becomes unresponsive say for a nightly maintenance, Jira's automatic sync process could fail when the server becomes unresponsive here. If that happens, with a large sync interval like yours of 10 hours, a single sync failure means users would be unable to login for up to 10 hours. It's possible that the next sync will probably succeed to correct this, but it's more likely that an admin will manually sync it to correct it before that time.
Extending the timeouts seems like a good next step here. Please let me know if you run into any more trouble here.
Announcing safe customer notifications in Jira Service Management as a building block for compliance and privacy needs At Atlassian, we understand the increasing need to be assured that your data i...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events