Login error when changing password. 2 User Directories

[v_grytsay]

Hi gyus! i need help...

User was migrated from Jira internal directory to LDAP Delegated Authentication, after migration login with domain account was successful

The user has changed the password of the domain account, when logging in with the changed password the following error occurred:

2020-12-22 16:30:57,290 https-jsse-nio-8443-exec-2 anonymous 990x6673x1 klteq3 192.168.139.45 /rest/gadget/1.0/login login : 'username' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie.
2020-12-22 16:30:57,290 https-jsse-nio-8443-exec-2 anonymous 990x6673x1 klteq3 192.168.139.45 /rest/gadget/1.0/login The user 'username' has FAILED authentication. Failure count equals 1 

When logging in with the old domain password, the error is:

2020-12-22 16:32:04,236 https-jsse-nio-8443-exec-9 anonymous 992x6715x1 klteq3 192.168.139.45 /rest/gadget/1.0/login The user 'username' has FAILED authentication. Failure count equals 2
2020-12-22 16:32:09,032 https-jsse-nio-8443-exec-13 anonymous 992x6716x1 - 192.168.193.48 /rest/remote-link-aggregation/1/aggregation HttpSession created [4ict6v] 

When viewing a user in Jira, the system says that the user is in two directories:

Screenshot of directories:

[Ismael Jimoh · Accepted solution]

Hi @v_grytsay 

Let me translate some of the errors I see here:

2020-12-22 16:30:57,290 https-jsse-nio-8443-exec-2 anonymous 990x6673x1 klteq3 192.168.139.45 /rest/gadget/1.0/login login : 'username' tried to login but they do not have USE permission or weren't found. Deleting remember me cookie

The above means the user does not have a valid application license. My suspicion is your LDAP configuration isn’t adding the newly created users to groups that grant them Jira licenses. Review your configuration here and you can find out which groups are allowed application access by checking the Application Access page as a Jira administrator. (Due to the different directory, Jira cleared the browser cookie)

Also note that group membership will need to be reapplied as users are still technically considered somewhat different.

2020-12-22 16:32:04,236 https-jsse-nio-8443-exec-9 anonymous 992x6715x1 klteq3 192.168.139.45 /rest/gadget/1.0/login The user 'username' has FAILED authentication. Failure count equals 2
2020-12-22 16:32:09,032 https-jsse-nio-8443-exec-13 anonymous 992x6716x1 - 192.168.193.48 /rest/remote-link-aggregation/1/aggregation HttpSession created [4ict6v]

Yes it will fail because that is not the password for same username in your LDAP. Fix the default group for users in your Ldap configuration to solve the problem here.

A simple hint, JIRA will pick a user based on username from the directory in the highest position, however, JIRA would still not grant the user the same permissions unless the user in both directories have the same group membership. Either by mapping the users to the same group from the AD or if you go with Delegated, mapping the users to internal groups. It wouldn’t automatically carry over.

[v_grytsay]

Indeed, the user has lost access to the group that provides access to the application. added the user a group manually and the user is logged in.

should i add user in the group every time when he changes his password? :( 
default group for ldap assigned

 

[Radek Dostál]

Them changing a password has zero effects on user directories or groups. It's most likely just a coincidence making you think or something that they think and told you.

It's all about which user directory the user belongs to first from top to bottom. If they have an account in both directories and you switch the order, they will have to use a different password and it will be a different account. Some content mapping for the user will remain but some won't - they are different accounts as far as Jira is concerned.

[v_grytsay]

Is it possible to remove a user from the Jira internal directory? 

[Radek Dostál]

It is - it's basically the same as far as any other user directory goes, internal or external. The only difference between them is that internal directory is just built-in, and can't be removed itself, but other than that an account is "treated" the same way regardless of the directory it's in. (And again to re-iterate, if the same username exists in multiple directories, you will only be able to use the one that's from the first directory top to bottom, and it will have different group membership and userkey, different accounts at the end of the day.)

I do not however want to recommend deleting it if you do not come to the decision yourself after weighting in the possible effects - because it could result in the user losing some content mapping, I do not know perfectly well the exact userkey/username relationship mapping and what happens to it, other than that it worked for us without issues and we didn't see nor have been reported to any missing mapping afterward. There are too many factors like the difference in content-user mapping, some things use userkey mapping(think of this like a unique account id), some username(which can be duplicate per directory). For any 3rd party plugin that you use, the mapping could be either the userkey or username, depends how the vendor coded them.

[Radek Dostál]

Just to add though, you may want to keep a service account in internal directory (and only that), because when LDAP goes down everybody without an active session will get locked out. A service account, because it exists only in internal directory, and not in ldap one, can log in regardless of the directory order. So with that you would be able to log in and modify the ldap directory settings, like a different server, authentication account, etc.

Without an internal service account, any such directory updates would require manual updates in the database.

[Radek Dostál]

My advice would be to delete the redundant user in the internal directory (assuming that they should only use LDAP for authentication) - in general a user should only exist in a single directory, if they exist twice or more things will get messy with what is mapped where.

In an environment I work in we used to solve these problems in a surprisingly easy way, however because this is not from what I know officially approved or recommended approach, I do need to stress out that you may want to test this first if possible:

 - switch user directories so that Internal directory is first in order

 - search for the user in Users

 - this should show you the user registered in Internal directory

 - delete it

 - you should now see the user under LDAP (this instance of user was not visible before, but since internal one was deleted, it is now the only user with that username)

 - switch directories back in the same/wanted order

They should be able to log in via ldap now.

From what I remember this also mapped previous content like comment author / assignee and so forth, but did not migrate group membership (as Ismael pointed out). This was a long time ago since I last saw the problem so again, you should only do this if the user has no previous content and/or if you verify that their previous content will get remapped (if you have a test instance available?).

[Ismael Jimoh]

@Radek Dostál I would not recommend this because if there is an outage of the LDAp which takes time to fix, users get locked out.

Instead of that with proper configuration and understanding how Jira handles user, groups and group membership, they can configure it in a way where when there is an outage that takes time to fix for the LDAP, they could login with the local internal admin user(who exists only in the internal directory) and switch directory order.

This way users who already exist will not have to all be grinder to a halt till a solution is found.