Active Directory Users Cannot Login to JIRA

[Eugene Moryl]

the user can log into other instances of jira (current version 7.7.1) all of which are setup with AD and LDAP in the same configuration.  (e.g.:  the user can log into our test and dev instance running the same version and configured identically as production).   Cache on all browsers have been cleared.  

[Andy Heinzer]

Hi Eugene,

If I understand the problem here you have users in Jira that exist in an external directory, but that in this particular Jira instance, all the users that originate from that LDAP directory are unable to login to Jira here.

If the Jira configurations are truly identical, then my thought is that perhaps this dev instance of Jira has some different network configuration that could prevent Jira from correctly communicating with this LDAP server.   If Jira cannot communicate with this LDAP, that would explain why Jira cannot authenticate these users.  If this is the cause though, we should see errors in the logs of Jira when users try to login.  Try navigating to the $JIRAHOME/logs/ folder.  There is both a security log and an atlassian-jira.log that could potentially show us more information in regards to why this might not be working. 

I would be interested to learn more about any specific errors that are generated in these logs at the time an LDAP user attempts to login to Jira here.   These might tell us more about what the next steps are to troubleshoot this.

If we are still not getting a clear reason as to why this login is failing, I would recommend trying to follow the further troubleshooting steps listed in the KB: Unable to login to JIRA applications.

1. Please set com.atlassian.jira.login & com.atlassian.jira.login.security to DEBUG in Administration > System > Troubleshooting and Support > Logging and Profiling.
2. Have the user (attempt to) login.
3. Set those log levels back to the WARN so they don't spam the logs.

With DEBUG logging set for those two packages in Jira, the logs will provide much more information about why those logins are failing.   I suspect you won't need to do the DEBUG logging steps to track down why this is happening, but I offer this as a set of next steps in case the first ones are not clearly indicating the problem here.

Andy

[David Shapiro]

It is not the case that all users using the user directory service for ldap cannot login.  It is that "one" user cannot login.

We identified in previous comment that there is an AD group called Contracts that has a similarly named group in a different domain called contracts (note the lower case first letter and that it is in a different domain).  

The theory is that user changed her password and it attempted to sync the AD information for her and ran into this conflict as she is a member of one of these groups.  It also was the case that on 4/3 there was a database space issue (see the support zip logs and you will see that).  The idea is that these are somehow related. 

We got permission to rename one of the groups from contracts to Contracts Portugal and we did a re-indexing.  I am not sure if Eugene has heard back from the user yet on whether that helped.

Regardless, it is good information on how to increase the logging if we still have the issue.

[David Shapiro]

I just saw we had confirmation for the user she still cannot login.  We will look at the logging setting to increase logging and see if it shakes anything to the surface.

[David Shapiro]

I enabled the logging, but the user logging in did not show up in the log.  What she got was a User unknown or password incorrect textbox during logging into Jira.  

I had expected the resolution of the group conflict to resolve this.  On a hunch, and an idea Eugene and I had talked about earlier, I removed the user from the remaining group called "Contracts" and had her try again, and it worked. 

She was able to login. 

Idea 2:  The group could not resolve that it was no longer in conflict with that user still in it.  Removing her from it removed that conflict and synced contracts and then the user separately, allowing her to login. 

[David Shapiro]

This seems like a bug...

[Andy Heinzer]

With debug logging set for those two packages, all login attempts should appear in the $JIRAHOME/log/atlassian-jira-security.log   A failed login could show as an anonymous user, but typically I would expect the username to appear in the logs here at that time.

As for why removing that one user from this specific group in LDAP would have changed this login behavior in Jira, I cannot explain that with the information I have at this time here.   I just don't know enough about your specific environment and your settings.  If this user was getting synced over to Jira, what groups was it a member of according to Jira?  Was it member of a group that granted application access?  If not, that would explain one possible reason why that user could not login.   However as for why removing this particular group would have changed the login behavior does not seem to be clear to me here yet, unless of course your application access is granted to users via this 'contracts' group.

If this was the case, then the log file above should have shown a 'AUTHORISATION_FAILED' error message when this user tried to login.   Since we don't see that here, it does not seem clear to me that this is the case.

Could you tell us more about your environment?

1. Do you have multiple user directories in Jira?
2. If yes to #1, does this user exist in more than one user directory?
3. If yes to #1, what is the specific order here (top to bottom)?
4. Also for this LDAP user directory in Jira, could you share with us the settings on how Jira will select users and groups?

This is determined by the base dn, user dn, group dn, as well as the user object filter, and the group object filter.   Perhaps the user account was not even being synced over because of the way your object filter is set to find users in LDAP.  But without knowing your specifics, this is more of a hunch.

You could try to change things back, resync the directory in Jira, and then try to run a SQL query to see if the user exists in Jira, such as

select * from cwd_user where lower_user_name = 'exampleuser';

Just note that the lower_user_name field will always be in lowercase.   If you do not see this user specific user when changing the 'exampleuser' to their username in Jira after changing the group in LDAP and then syncing in Jira, this is a clear indication to me that the user account is not being selected based of the LDAP filter Jira is using.  If you're getting multiple entries for this SQL query, it's important to note the directory_id as having the same username in multiple directories is possible, however Jira will only honor the credentials from the highest ordered directory in which that specific username appears.

[David Shapiro]

Andrew,

I wrote an extensive email response with all the ldap related information, but it is not showing here.  That is a bit much to put together, especially when that information should be in the support zip. 

Anyway, as much as I would like to write out all that information again, I want to remain firm that the ldap settings are fine.  It is not related to number of user directories or the order they are in I am sure as we have the exact settings in the other environments via (export/imports). 

This is clearly related to a conflict between the two AD groups and this particular user having been in one of those groups.

This has been proven by removing her from that group allowing her to login.  The removal has also shown that it stopped the duplicate error message as related to the group.  These two were in a tangled web scenario that did not allow the sync for this user to work.

Please consider that there is an issue with how the AD sync handles this particular duplicate group issue.  

This should probably go to development and get listed as needing an improvement to deal with this type of scenario.

[Andy Heinzer]

Hi David,

I accept that there might be a bug here.  However in order for me to file a bug ticket, I need to have detailed set of steps that document how to recreate this problem.   So far, I don't have a complete picture as to why removing that AD user from this particular group suddenly then allows this user to login to Jira.

I understand there was another group by the same name, but with different casing here.   However Jira grants application access by group membership.   Is either of these duplicate groups one that grants application access to Jira?  Or are these subgroups where the parent grants application access.   I still have not been able to determine exactly why the steps you took had this outcome.

If you want to create a suggestion type issue, you are actually able to do this yourself within the JRASERVER project of the https://jira.atlassian.com/projects/JRASERVER/issues

While researching this kind of problem some more I came across this documented bug: https://jira.atlassian.com/browse/JRASERVER-66599

In that case there were two groups on the LDAP side named 'Test Group' and 'Test Group ' (with an extra space).  In that case there was a pretty specific error thrown:

Caused by: java.sql.SQLException: Cannot insert duplicate key row in object 'dbo.cwd_group' with unique index 'uk_group_name_dir_id'. The duplicate key value is (Test Group, 10100).

If your Jira logs are showing a similar message here when this was not working for that user, then perhaps this existing bug ticket is what should be used to track this issue.   However if your error message is different here, I would want to know more about what specific error is thrown in the atlassian-jira.log during the sync.