SOLVED: Crowd/Jira/Confluence integration with Azure AD for SSO (design & fail)
Asked by Peter Meuser:

I am exploring ways to integrate Jira, Confluence etc. with SSO to AzureAD. My idea so far is to use the direct directory integration of Crowd with Azure AD to provision users and groups. SSO auth with Atlassian tools should happen with snap-ins like "Microsoft Azure Active Directory single sign-on for JIRA".

This article seems to point in the same direction:

<https://community.atlassian.com/t5/Crowd-questions/Authenticate-Azure-AD-users-against-Crowd-and-Atlassian-products/qaq-p/849794>

Has anybody get such an setup already up and running?

So far I fail already in my test setup with the following error message when trying to sync Crowd with AAD:

2019-02-19 09:31:45,005 Caesium-2-4 INFO \[microsoft.aad.adal4j.AuthenticationAuthority\] \[Correlation ID: b28eb4bb-e5f4-4433-bb59-c4881b655d50\] Instance discovery was successful  
2019-02-19 09:31:46,520 Caesium-2-4 ERROR \[atlassian.crowd.directory.DbCachingDirectoryPoller\] Error occurred while refreshing the cache for directory \[ 1277954 \].

Thanks a lot for your input!

Peter


Answers:
author: Peter Meuser
body: If anybody is interested: Works as expected! You can use all "bells and whistles" of Azure AD authentication as:

1. Azure MFA (and other conditional access related protection)
2. Password-free authentication with Authenticator app
3. (USB) Token key MFA with third-party products like Duo security
4. Support for external IDs (B2B guests)

Very cool stuff.

Would be nice to see Atlassian having an official documentation on that.

comments: author: Joost van Orsouw
body: Hi Peter,

Maybe you can help us out;

* We had an internal Atlassian environment for which we used a SAML SSO plugin to authenticate against Azure, wich is working fine
* The user directory was directly retrieved from our internal AD
* We are now migrating to a hosted environment which will not have access to our internal AD
* By installing Crowd, we managed to setup the User directory against Azure AD, and we can now see the users in our tooling (tested with Jira \& Confluence)
* We would like to replace the SAML SSO plugins by the Crowd SSO plugin, in which Crowd would authenticate against Azure, just like in your setup.
* Now we are however totally stuck within the documentation on how to move on from here.

Can you give us some pointers and/or share details of your setup? It would be much appreciated!

Kind regards,

Joost


author: Peter Meuser
body: Joost, I am using on-prem Crowd to sync accounts from Azure AD to Jira/Confluence. For Jira/Confluence auth happens with Microsoft's SSO plug-ins for AAD. I know, that the cloud version of Crowd supports SAML, but have never tried to use this for SSO.

Peter


author: Joost van Orsouw
body: Ok, thanks for your reply. We were hoping that Crowd would be able to replace any additional SSO plugins, but it seems to be only in addition then. The MS plugins are not available for Bitbucket \& Bamboo as far as I know. That would then mean that users need to use Jira or Confluence before going to Bitbucket or Bamboo to have a full SSO experience. We will do some testing with this setup, and I'll let you know how it went.

kind regards,

Joost


author: Peter Meuser
body: I bumped into Crowd Data Server 3.4 with SSO 2.0. This might also be an SSO option with Azure AD completely build on Atlassian modules. Beside Jira and Confluence, it also supports Bitbucket Any experiences so far?


author: Joost van Orsouw
body: We did shortly look into that, and loaded a datacenter license. However, the system add-on in Jira and Confluence was reporting to be an incompatible version (which should not have been the case) , and could not be set up.

We did install the MS add-on, and though it works, it is not the most beautiful solution out there. What we would like, is to have any user being redirected to the SSO when accessing the Jira/Confluence pages. With the MS Add-on, users still need to click the logon button, or use the direct SSO link. Compared to that the configurability of our current [plugin](https://marketplace.atlassian.com/apps/1212130/saml-single-sign-on-sso-jira-saml-sso?hosting=server&tab=overview) is much nicer, so we will keep using that. With the combination of Crowd and the SAML SSO plugin, we have everything working, but we are still looking at another route, that would not require Crowd.

So what we are now trying to do, is setup a SLDAP server within Azure, and connect that as a user directory. This way we avoid the need for Crowd, simply for connecting to Azure. We will post an update when we have tried that.

kind regards


author: Peter Meuser
body: Joost, SLDAP within Azure means Azure AD Domain Services (AAD-DS), right? This approach would not allow you to have SSO with AAD neither AAD Conditional Access / MFA / password-free sign-in options. Is this what you are looking for?


author: Christian Reichert (resolution)
body: Hi Joost,

thanks for speaking highly about our [SAML Single Sign On Plugin.](https://marketplace.atlassian.com/apps/1212130/saml-single-sign-on-sso-jira-saml-sso)

I am not sure if you have seen this, but in the newer Versions our Plugin supports direct [User Synchronisation](https://wiki.resolution.de/doc/saml-sso/latest/all/user-and-group-synchronisation-user-sync/azure-ad-configuration) with with Azure AD (and Okta, GSuite).

There may be no need for SLDAP. If you share your exact use case/requirements, I may be able to give you a bit more advice.

If you don't want to share your topology in a public Forum, you can also do this in a support case: <https://resolution.de/go/support>

Cheers,  
Christian

Full disclosure: I work for [resolution GmbH, a marketplace vendor](https://marketplace.atlassian.com/vendors/1210947/resolution-reichert-network-solutions-gmbh).


author: bromoserwfm
body: [@Peter Meuser](/t5/user/viewprofilepage/user-id/2701883) , I'm unclear on what you're saying - how specifically did you manage to get Crowd to handle MFA-enabled Azure AD users? You seem to be suggesting that you are using the native Crowd Azure AD connector, but I've confirmed only non-MFA users are currently able to login using the connector in Crowd 3.5.

Edit: I see that you used the (never updated nor supported) Microsoft plugin to provide SSO for Jira/Confluence. That explains how you got this working - sorry for missing your post.


author: Warwick Bambrook
body: Hi,  

Can anyone tell me if this solution is available without Crowd? We are looking to connect Jira and Confluence to AzureAD and would like to use AD groups for authorization and SSO for authentication.  

I did some trials of the SSO, but couldn't get the LDAP to sync for the groups/roles access.

regards

Warwick


author: Peter Meuser
body: Crowd sync error with AAD solved:

<https://community.atlassian.com/t5/Crowd-questions/Invalid-Login-Error-and-no-sync-with-Azure-Active-Directory/qaq-p/809117>


author: Peter Meuser
body: Please have a look at the recently introduced value "user.localuserprincipalname" for an additional claim in SSO section of your AAD enterprise app setting.


author: KO89
body: [@Peter Meuser](/t5/user/viewprofilepage/user-id/2701883)

Hello, I was able to set up SSO using the free plugins as well. However, you made a point that plugins have "Support for external IDs (B2B guests)". Can you verify this to be true? Currently, my internal users work fine but my B2B users sync to crowd with a #EXT#dosinvest.onmicrosoft.com added to the end of the userprincipalname.. this makes it impossible to use the plugin. Do you have any experience with this?

Thank you

comments: author: Stephen Neil
body: Hi Peter, did you manage to address this? We may be observing a similar issue with external users and the plugin

(It is working for external Gmail users with a MS live account, but failing for other users with their own external AzureAD accounts - those accounts can successfully access other resources on our Office365 area, e.g. SharePoint, so we know their external SSO accounts are working...just not through JIRA)


author: Peter Meuser
body: Please have a look at the recently introduced value "user.localuserprincipalname" for an additional claim in SSO section of your AAD enterprise app setting.


author: Stephen Neil
body: Much appreciated for the pointer there [@Peter Meuser](/t5/user/viewprofilepage/user-id/2701883) - claim added and awaiting feedback


author: Owens K
body: Thanks for the update, going to test and hope for the best.


author: Stephen Neil
body: [@Peter Meuser](/t5/user/viewprofilepage/user-id/2701883) , thanks for your help here - updating the SSO claim value has worked and our external users now have access! Much appreciated.


author: Owens K
body: [@Stephen Neil](/t5/user/viewprofilepage/user-id/2550729) You can confirm the new claim value truncates the #ext#xxx.onmicrosoft.com from the principal name?


author: Stephen Neil
body: Hi [@Owens K](/t5/user/viewprofilepage/user-id/3588615) we use Crowd to sync our AD users with JIRA.

In AD the external guest account username is *username@externaldomain.com*

The synced username in JIRA is *username_externaldomain#EXT#@mydomain.onmicrosoft.com (their email address on the JIRA user record is username@externaldomain.com)*

After updating the Unique User Identifier claim value in the JIRA SSO app to "user.localuserprincipalname" I can confirm that our external users have been able to sign in at the SSO screen using *username@externaldomain.com*


author: Owens K
body: Awesome, thanks [@Stephen Neil](/t5/user/viewprofilepage/user-id/2488) . I'll give it a go in my environment as well.


author: Owens K
body: For anyone who may need this, I can confirm as well that the claim "user.localuserprincipalname" works for the Atlassian application if using external guest accounts.


author: Oleksandr Zharnovskyi
body: [@Joost van Orsouw](https://community.atlassian.com/t5/user/viewprofilepage/user-id/1570395) could you please share a brief setup doc?  
thank you!


author: Joost van Orsouw
body: Regarding our final setup;

* We completed the setup by using SLDAP in Azure
* Using SLDAP takes away the need for crowd
* After the user directory for SLDAP was created, we did a sync which worked fine
* When setting up the directory we also set a default group (eg Jira-Users) for users that have successfully authenticated
* SLDAP was beneficial to us, since we could setup the user directory exactly the same as we did when the environment was still internally hosted and connected to AD
* [@Christian Reichert (resolution)](/t5/user/viewprofilepage/user-id/595496) ; we tried the Azure Sync of your plugin together with your support team, but the sync was very slow and we had issues with the username (we use firstname.lastname instead of e-mail). Because of the different format user search produced duplicate results, and tickets were not connected to the new user format. Since it was a new feature, we decided to wait until it has developed further
* After the user directory is in place, you can use a paid plugin, or the free one from MS to setup a SAML connection with Azure
* We have setup conditional access with MFA and everything
* [@Tony Liu](/t5/user/viewprofilepage/user-id/3218686) ; above setup works perfectly for us. If needed I think I can share to setup documentation after anonymizing it

Kind regards,

Joost

comments: author: Peter Meuser
body: Joost, if you do not rely on Crowd on-prem, this is a valid approach, too.

"SLDAP for Azure" means, you have enabled the additional product "Azure AD Domain Services", right?

It would be nice to see, that Atlassian supports Azure AD beside AD in all their products, so that Crowd, AAD-DS, third-party tools which all add complexity are not required anymore.


author: Tony Liu
body: [@Joost van Orsouw](/t5/user/viewprofilepage/user-id/1570395) , Thank you so much for sharing your experience. Yes, it'd be greatly appreciated and helpful if you could send your setup doc. What's the best way I send my email address to you?


author: Joost van Orsouw
body: Give me some time tomorrow, and I'll create a short setup guide for it. Maybe we can post it here, otherwise I will share a link

kind regards

Joost


author: Alex G
body: [@Joost van Orsouw](/t5/user/viewprofilepage/user-id/1570395) could you please share a brief setup doc?  
thank you!


author: James Tam
body: [@Joost van Orsouw](/t5/user/viewprofilepage/user-id/1570395)

Are you using on-prem Atlassian products or Cloud? If on Cloud, is this setup for AzureAD SSO with Atlassian possible without subbing to Atlassian Access?

Thanks!


author: Tony Liu
body: Hi Peter,

On your Feb 19 post, you said:

\>\>\>If anybody is interested: Works as expected! You can use all "bells and whistles" of Azure AD authentication as:

1. Azure MFA (and other conditional access related protection)
2. Password-free authentication with Authenticator app
3. (USB) Token key MFA with third-party products like Duo security
4. Support for external IDs (B2B guests)

Very cool stuff.

Would be nice to see Atlassian having an official documentation on that.

\>\>\>

Are you integrating Crowd with Azure AD? We are about to integrate Atlassian with AAD, but if following the instructions on this doc: <https://confluence.atlassian.com/crowd/configuring-azure-active-directory-935372375.html>

It says "Crowd doesn't support multi-factor authentication.You'll need to disable it for your users in Azure AD, or they will not be able to log in to Crowd or any integrated applications. ".

Would you care to share more details what you did?

Thanks

Tony Liu

comments: author: Peter Meuser
body: Tony, the trick is, that you don't use Crowd for SSO. The approach that I have followed is to install SSO plug-ins for AAD from Microsoft on Jira and Confluence. These support of course all AAD supported sign-in methods incl. conditional access and MFA. Crowd is just used as central user directory for Jira and Confluence. You can sync users between Crowd and AAD and then from Crowd to Jira/Confluence. This is how it works for me in a PoC for a larger environment.


author: Tony Liu
body: Peter, Thank you and thank you for the quick response.

Regards,

Tony


author: Christian Reichert (resolution)
body: Hi Peter,

the Alternative to this can be one of the commercial Plugins like ours. For example with our Plugin you can synchronise Users straight into Confluence / Jira and also do all the authentication via SAML.  

So depending on our exact setup you could get some of these benefits:

* No need for Crowd (Licensing + Server + Operational costs)
* As SSO is the only Way for Users to login, most of our customers see this as business critical and hence want a Solution that has official \& commercial support.
* As a Top vendor we have to deliver compatible versions to the newest Atlassian products within 14 days of release (usually it's within hours, as we get access to Beta releases).
* Our plugin supports a variety of additional features, that very often are reuqired in enterprise deployments (multiple IdPs, single logout, encryption, group/user filtering \& transformations just to name a few).
* Our Plugins are available for all Atlassian Products not just Jira/Confluence.

In short there are multiple Ways to get to a working solution - you need to judge depending on your use case, which one suits you better.

Here are our plugins on the marketplace: <https://marketplace.atlassian.com/vendors/1210947/resolution-reichert-network-solutions-gmbh>

We are not the only choice, there are more: <https://marketplace.atlassian.com/search?query=saml>

Here is the Setup for Azure AD described: <https://wiki.resolution.de/doc/saml-sso/latest/all/setup-guides-for-saml-sso/azure-ad/azure-ad-with-user-sync>

Cheers,  
Chris


Tags: active-directory

azure

confluence

jira

microsoft

sso