Is Crowd data center needed when users are in Azure AD?

[Stephen Hodgson]

Crowd has been invaluable in the past to allow a centralized place to edit groups/permissions and to allow for authentication back to multiple LDAP directories as well as the internal directory.  However, in the near future we should have all users in Azure AD and at that point it seems that Crowd was written out of the solution by Atlassian since Azure AD SAML SSO was baked directly into each application instead of keeping it centralized in Crowd.

Am I missing something here or is Crowd just no longer part of the solution in this environment?

[Ed Letifov _TechTime - New Zealand_ · Accepted solution]

Hello, @Stephen Hodgson 

I think, the only two reasons to keep Crowd around in this situation:

• if some of the groups/permissions are additional to what you have in AD/AAD, usually this implies a smaller department that does not want to go via corporate IT on every nitty-gritty user-group-related change
• if you have other applications integrated for SSO with Crowd

Please note the "baked-in SSO" will happily talk to Crowd DC, that can then talk to AAD,  effectively fronting it, same as it was previously talking to AD.

See: Upgrades added to Crowd Data Center’s Azure AD integration 

Atlassian seems to highlight the ability to sync groups to the applications selectively. For one of our clients, about 23 groups were actually being used in Jira, but AD/AAD was pushing 8k+

So really, this is a matter of preference

[Stephen Hodgson]

@Ed Letifov _TechTime - New Zealand_,

Thanks for the reply.

I had found the help page that the blog post you linked points to (https://confluence.atlassian.com/crowd/configuring-azure-active-directory-935372375.html) while I was looking into this prior to posting.  The critical missing piece here is that what is described is not SAML SSO from Crowd to Azure AD.  SAML SSO to Azure AD would allow us to enforce conditional access rules (including MFA) on the Azure AD side.

[Ed Letifov _TechTime - New Zealand_]

Yes, that's correct. What is described is basically "user provisioning" from Azure to Crowd.

If you want Azure to enforce conditional access rules then the "baked-in SSO" should hook to Azure directly.

As I mentioned, Crowd can still stay in the background and provide authorization information i.e. groups including those coming from AAD, but also local (to Crowd) ones.

[kaushal shah]

Hi @Stephen Hodgson,

As per your question, it seems like you are want to continue using Crowd for the stated reasons and want to integrate Azure AD with Crowd to enforce the security policies on the Atlassian users. I am delighted to say that we have a solution that fulfills your requirement.

You can use the miniOrange Crowd SAML SSO plugin to integrate SAML SSO with Azure AD and use the miniOrange crowd connectors to extend the SAML functionality to the Crowd-connected applications. By using the above plugins, all the users will be redirected to Azure AD for user authentication + MFA and you can still use Crowd to manage all your users.

It would be better if you can reach out to us at atlassiansupport@xecurify.com  or raise a ticket here to discuss this in detail.

P.S.- I work for miniOrange, an Atlassian Gold Marketplace partner. 

Thanks,
Kaushal  

[Stephen Hodgson]

Thanks for the reply, but paying extra for functionality that is already provided (in a strange way) by Atlassian doesn't make sense to me.

Also, I'm not wild about inserting a 3rd party into the authentication process.