Requesting help configuring authentication for users from a trust domain in a seperate forest

Dear All,

I have the following setup at the moment:

  • DomainA (where confluence is looking for users who are member of a group for access)
  • Domain B (trust domain in where a few users reside who also need access to confluence)
  • There is a domain trust so DomainA trusts Domain B (for example: I can authenticate to the confluence servers, which resides in DomainA and authenticate as a user from DomainB
  • I have setup a domain local AD group in DomainA where 1 user of DomainB is member of.
  • Confluence looks at the domain local AD group to give people access (this currently only works for users who reside in DomainA, not DomainB.
  • When looking at group membership, confluence only sees the members from DomainA, not      from DomainB.

The user from DomainB cannot login, and this is what we would want to achieve.

I searched answers and documentation but could not find any solution regarding this so hopefully someone here can help me.

Kind Regards,
Michel van Kooi

3 answers

While I cant answer your question you may want to add some more tags so that more people see this question. At least add active-directory. Can also try searching and browsing the Topics sections. This may also be a problem in JIRA, Stash and Crowd for example.

Did you ever find an answer to this as I am having the same issue?

We are in the same situation as you are, with a larger number of trusting Active Directory Domains the one or either way. From the explanation on how JIRA (and subsequent Confluence, Bitbucket and Co) handles LDAP (and AD) connections and synchronization, explained in and handles a) synchronization and b) authorization we found that the scenario we planned - and you described - should work. Especially if you had checked the Follow Referrals in User Directories -> Advanced Settings.

For those, not that familiar with the issue, good readings would be

to get some background about the scenario we are talking about. Trusted/Trusting Domains.

In our case we found after nights of working through log-files, Atlassian Product documentation and so forth, that even though Java could handle the scenario very well, it seems as either Atlassian isn't aware about this or we have been just to stupid to get it running - I would rather bet on the latter... However, we did neither see a Referral from our AD (a good sign? or just too many long working days?) nor saw Jira/Confluence following one.

Our solution for now to get everything running and have 'the masses' finally get their beloved and wished tools -  and before we are going to open a support case and moving forth and back - we just added all Domains to the synchronization task (hence, all our Atlassian products now able to authenticate against the right domain). We had to create similar groups in each Domain (a pain in the as.. but thanks to Powershell a doable thing) and added users to them (the groups).

Lucky as we are we didn't come across the problem of having the same user (login/id/..) twice, since in such case Atlassian products choose the first occasion of a user (see and that implies a number of issues from that.

  • which is definitely why you want to setup the directoeis synchronization with User Name Attribute as userPrincipalName instead of sAMAccountName for this work-around.

I know this isn't the answer you may looked for, but at least a work-around. Even though, this one is more complex and hence can be only temporarily because maintenance seems to become an "ugly" task.

If you meanwhile found a better solution - please share it with us.

Best regards,

Ingo-Stefan Schilling


  • At least with Windows 2012 R2 and Windows 2016 Domains, switching from sAMAccountName to userPrincipalName will bring you into some LDAP trouble sad... however - there is a solution which looks like:


    The less important part is displayName=Health* and * service *. The first is to filter Exchange HealthMailboxes from the result and we use service in our user names for service accounts which will for now not use Atlassian tools to login. In other words, everything else is needed to get a clean, error free list, the rest is just filter local topology.

  • You may, when changing to userPrincipalName, want to change Read- and Search- Timeout and make it longer, same for Synchronisation interval.
  • In addition, it may - and that's not a Java but Atlassian specialty - happen that you get a number of extremely crude error messages (after everything is working for a while), e.g. "Can't resolve host" etc.. Before you try to nail down the error for hours, first delete the connector and do a new setup. Most of the times, this is the solution - don't ask me why.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 12, 2019 in Confluence

Confluence Admin Certification now $150 for Community Members

More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...

925 views 2 13
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you