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

Question

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

Ingo-Stefan Sch3 · Answer

I might not have 'the right' answer but I think I can at least partially answer your question.

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 https://confluence.atlassian.com/adminjiraserver070/connecting-to-an-ldap-directory-749382818.html and https://confluence.atlassian.com/jira/diagrams-of-possible-configurations-for-user-management-229839938.html 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

* https://blogs.technet.microsoft.com/mir/2011/06/12/accessing-resources-across-forest-and-achieve-single-sign-on-part1/ and following docs
* evt. https://technet.microsoft.com/en-us/library/cc783351%28v=ws.10%29.aspx
* https://technet.microsoft.com/en-us/library/cc773178%28v=ws.10%29.aspx

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 https://confluence.atlassian.com/jira/managing-multiple-directories-229838552.html) 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

UPDATE

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

(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(userPrincipalName=*)(sAMAccountName=*)(!(displayName=Health*))(!(displayName=*service*))(samAccountType=805306368))

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.

Mike Beattie · Answer

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

Steve Rhodes · Answer

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.