Jira delegated authentication with two Active Directory OUs

Question

I need to configure two Jira user directories so that accounts from two separate Active Directory OUs can authenticate to Jira.

If I configure a single delegated authentication directory with the parent OU as the Base DN, users from both child OUs can log in successfully.

For security reasons, however, I cannot use the parent OU. I need two separate directories:

Directory 1:

Base DN: OU=DHA Users,DC=dhadev,DC=local

Directory 2:

Base DN: OU=Admin Accounts,OU=Domain Administration,DC=dhadev,DC=local

Both directories use the same LDAP server and service account, and both use:

Username attribute: sAMAccountName

The standard user directory works correctly, but users from the Admin Accounts OU receive "Invalid username or password" when attempting to log in.

If I instead point a single directory at the parent OU containing both sets of accounts, the admin accounts authenticate successfully. This suggests that the credentials themselves are valid.

The Jira users already exist, so I am not using Copy User on Login.

Has anyone successfully configured Jira delegated authentication with two directories pointing to different OUs in the same Active Directory domain? Is there anything specific regarding directory order, Base DN, LDAP searches, or delegated authentication that could cause the second OU to fail?

Mihai_LeanZero · Answer

Hi @Jake Veenstra,

To make Copy User on Login work around the case Arek describes, move Directory 2 above Directory 1. Jira uses "the first occurrence of the user" (https://confluence.atlassian.com/adminjiraserver/managing-multiple-directories-938847057.html), so the admins then get created in Directory 2 on first login. DHA users aren't found there, and Jira moves on to Directory 1.

Group membership is read only from that first directory too. I'd add the admin groups under Default Group Memberships on Directory 2, or the admins log in without their permissions.

To confirm first, set DEBUG on com.atlassian.crowd and com.atlassian.seraph.auth, log in once and look for "has FAILED authentication" in atlassian-jira.log (https://confluence.atlassian.com/jirakb/how-to-find-the-cause-of-a-failed-user-login-with-debug-logging-1456342672.html). Keep an internal admin account handy before you reorder.

Arkadiusz Wroblewski · Answer

Hi @Jake Veenstra

Josh covered the main points.

One thing to be careful about: Atlassian supports migrating users between delegated directories, but the built-in migration tool moves all users, not individual accounts.

https://confluence.atlassian.com/adminjiraserver0914/migrating-users-between-user-directories-1385108340.html

Before making any changes, verify which directory owns the failing accounts. Simply enabling Copy User on Login won't necessarily fix an account already present in a higher-priority directory.

Best,

Arek🤠🧙‍♂️

Josh · Answer

Hi @Jake Veenstra, since the admin accounts log in fine when one directory covers the parent OU, the likely cause is which directory each existing Jira user belongs to, not LDAP.

In Jira, every user belongs to one directory. When a username exists in more than one directory, Jira uses the one that comes first in the directory order. With delegated authentication, Jira checks the password against the LDAP server using the settings of the directory that holds that user.

If the admin accounts were created while the single parent-OU directory was in place, they probably still belong to Directory 1 (or whichever directory got them first). Directory 1's Base DN is now OU=DHA Users, so the bind or search for an admin user finds nothing under that OU. The result is "Invalid username or password", even though the password is correct.

What I would check:

1. User management > Users: open one failing admin account and see which directory it lists. If it is not Directory 2, that is your answer.

2. In Directory 2, use "Test settings" with one of the admin usernames and its password. If that passes, the settings are fine and only the user-to-directory link is wrong.

3. Check that the "Additional User DN" field is empty in Directory 2. If it is set, it is added to the Base DN, and OU=Admin Accounts can end up searched in the wrong place.

4. Check the order of the two directories, in case the same usernames exist in both.

To fix it, the admin users need to exist in Directory 2. You can create them there (and remove the duplicate from the other directory), or turn on "Copy User on Login" for Directory 2 only. Do this in a test instance first, because moving a user to another directory can affect group membership and app access.