-
Suggestion
-
Resolution: Fixed
-
Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.
Hello everyone,
Thank you very much for your votes and comments on this suggestion. Your feedback is highly valuable for us and helps us to create a better product that is addressing your needs.
The Atlassian Crowd team is pleased to bring you Crowd 3.0, which comes with support for Microsoft Azure Active Directory (Azure AD) to let you bring your users and groups from Azure AD to Crowd. Azure AD works as a synchronizable directory, which means that new information will flow on a regular basis, or whenever you request it. Incremental synchronization and nested groups are also there, ready to go.
Since Crowd uses REST API to communicate with Azure AD, you don't need to subscribe to Azure AD Domain Services.
We highly recommend you to upgrade your current Crowd version to the latest one.
You can download Crowd 3.0 version from here.
Please read the upgrade notes for important information about this release before installing the newest version.
Thanks,
Marek Radochonski
Senior Product Manager, Crowd
mradochonski@atlassian.com
Summary
Some customers are looking to intergrate Atlassian products with Azure AD, which does not provide LDAP connectivity.
Providing this connectivity through our Crowd product would be a good way of servicing the needs of our customers that are looking ot move to hosted infrastructure.
Environment
Crowd, JIRA, Conflunce, with an Azure Active Directory.
Steps to Reproduce
N/A, there are no Marketplace Add-on's that currently support connectivity to Azure AD. This is something tghat may be achieved through the: OpenID Authentication for JIRA Add-on, but at this time, the documentation only states support for Google Apps.
Expected Results
Connectivity to Azure AD.
Actual Results
No options for User Management through Azure Active Directory Exist.
Notes
Cloud version of Microsoft AD: http://www.windowsazure.com/en-us/services/active-directory/
[CWD-3607] Provide support for Windows Azure Active Directory
@Kristian Nordman, Azure AD Domain Services - which is a paying option as of today - and LDAPS must be enabled in that case.
For those of you who don't want an extra cost on Azure or are not allowed by their security team to enable the LDAPS port, you might want to take a look at the [ODCC|https://marketplace.atlassian.com/plugins/com.cleito.odcc/server/overview] plugin (which comes with no extra cost on Azure and uses pure HTTPS requests to Microsoft Graph API).
Crowd can be setup using Azure AD. Follow the link PJ van Dyk used and then set it up as a regular AD. Make sure to use email as "user name attribute".
Azure does now provide LDAP connectivity - and has done for a while - when will Atlassian support it?
@Patrick, yes it has. Azure AD Users with the accountEnabled attribute set to false are considered as inactive in Crowd (they are marked as Blocked in Office 365 administration portal).
Awesome, this has support that it can also sync users back that are listed as disabled in Azure? That's what currently is missing from other add-ons.
Hi again,
I just wanted to let you know that our Office 365 Directory Connector for Crowd (ODCC) is now available on Atlassian Marketplace: https://marketplace.atlassian.com/plugins/com.cleito.odcc/server/overview
Hello everyone,
I guess some of you will be interested in ODCC, our new plugin for Atlassian Crowd: https://www.cleito.com/products/odcc/
ODCC stands for Office 365 Directory Connector for Crowd. It allows you to add your Office 365 / Windows Azure Active Directory to Atlassian Crowd as if it were a standard LDAP directory. The plugin uses Microsoft Graph API, so the connection between Crowd and Microsoft's Cloud is pure HTTPS (no LDAP!).
You can see it in action here: https://www.youtube.com/watch?v=SH8R_emN43U
Hope you'll like it!
Bruno
for the record, I knew about the ldap approach, thanks for the detailed howto. But I'm actually referring to OAuth, saml functionalities like they are currently being implemented in the cloud versions...
I managed to use ldap integration to connect my local Bamboo instance using LDAPS with Azure AD Domain Services.
Working well so far.
First setup LSAPS on Azure AD:
Second configure the ldap integration:
https://confluence.atlassian.com/bamkb/how-to-set-up-ldap-in-bamboo-729978786.html
Just watch out for Atlassian's documentation, they have contradicting statements on bamboo groups which could cause you headaches. Don't create "bamboo-admin" and "bamboo-user" groups in Azure AD but rather create your own groups that you can give the relevant access in bamboo.
You can create an OU in Azure AD as the documentation shows, but its a lot of effort. I opted to just nest all the groups I needed for bamboo in another group that I used to filter my ldap search query.
Below is a tweaked version of atlassian-user-custom.xml I used to get it working. It's a but different to the example in the documentation.
// <?xml version="1.0" encoding="UTF-8"?> <atlassian-user> <repositories> <!-- Default bamboo user repository (Put this first incase you have duplicate username for your main admin user so that you can always get in if integration fails)--> <hibernate name="Hibernate Repository" key="hibernateRepository" description="Hibernate Repository" cache="true"/> <!-- LDAP repository --> <ldap key="ldapRepository" name="Active Directory LDAP Repository" cache="true"> <!-- [HOSTNAME], the hostname to your LDAP, (i.e.: 192.168.10.71) [DISPLAY-NAME], i.e.: Sample User. A [PASSWORD], password to authenticate "The user that you will use to auth against AD" --> <host>ldap.example.com</host> <port>636</port> <!--?| in <security...> we are going to authenticate our LDAP configuration against a user in our Active Directory whereas, in this example we will be using "Sample User. A" as user --> <securityPrincipal>bamboo@example.com</securityPrincipal> <securityCredential>yourpassword</securityCredential> <securityProtocol>ssl</securityProtocol> <securityAuthentication>simple</securityAuthentication> <baseContext>DC=example,DC=com</baseContext> <!-- in <baseUserNamespace> we are going to specify where our users have been created in the Active Directory --> <baseUserNamespace>OU=AADDC Users,DC=example,DC=com</baseUserNamespace> <!-- in <baseGroupNamespace> we are going to specify where our groups have been created in the Active Directory --> <baseGroupNamespace>OU=AADDC Users,DC=example,DC=com</baseGroupNamespace> <userSearchAllDepths>true</userSearchAllDepths> <groupSearchAllDepths>true</groupSearchAllDepths> <usernameAttribute>sAMAccountName</usernameAttribute> <!-- in <userSearchFilter> we are going to get all users that are members of "bamboo-admin" and "bamboo-user" groups --> <userSearchFilter>(&(objectClass=person)(|(memberOf=CN=example-bamboo-admin,OU=AADDC Users,DC=example,DC=com)(memberOf=CN=example-bamboo-user,OU=AADDC Users,DC=example,DC=com)))</userSearchFilter> <firstnameAttribute>givenName</firstnameAttribute> <surnameAttribute>sn</surnameAttribute> <emailAttribute>mail</emailAttribute> <groupnameAttribute>cn</groupnameAttribute> <!-- in <groupSearchFilter> we are going to get all the groups specified in <baseGroupNamespace> (I did not create an OU here instead just nested all the groups I want use in bamboo inside this group) --> <groupSearchFilter>(&(objectCategory=group)(memberOf=cn=bamboo-group,OU=AADDC Users,dc=example,dc=com))</groupSearchFilter> <membershipAttribute>member</membershipAttribute> </ldap> </repositories> </atlassian-user>
Azure uses the same OU for Users and Groups: "OU=AADDC Users" if you wondered why I used that OU for groups.
Good luck.
@Joost: Yes I was hoping to use the free version instead of basic or permium. JIRA would be the only product we use it for. It looks like the major differences were mainly reporting.
@russel: we use premium, but I think sso should also work with basic version. (if that's what you mean)
Could you use the free version of Azure AD or did you need to send one of the premium versions of Azure AD?
we were forced to move bamboo from cloud to server due to eol for the cloud offering. All our other applications use the Azure AD sso, except for Bamboo Server. This is really annoying...
Nope, since I'm setting it up for a Non-Profit; Atlassian offers the server products for free but not the Cloud offerings, which is understandable.
Ah, yes! Sorry about that.
Would that functionality sway you to move to the cloud based version?
Just out of curiosity.
That functionality appears to only apply to Atlassian Cloud products, not the server products.
https://azure.microsoft.com/en-us/marketplace/partners/atlassian/atlassiancloud/
Looks like they offer this functionality now.
Is this so much different than regular Active Directory? So many users nowadays use Azure's AD.
IT guys from Atlassian,
How many votes you need, to prioirize this feature more to the foreground? The comments shows, that this is very urgent needed.
While not for Crowd, Atlassian released a SAML add-on for JIRA and Bitbucket Datacenter earlier this month at Summit 2016. This may help some of you. It has Azure AD support built-in.
+1
For us it is also a must have being able to authenticate against MS Azure AD.
Johan is correct. Fabians suggestion is the same as Boris's. It is fundamentally different from Azure AD Single Sign On, and NOT a workaround or a solution. Atlassian will need to build out the SSO support with Microsoft (and all the other vendors) eventually, it's just a matter of how long people have to suffer until they do.
Hi Fabian,
This is LDAPS to Azure AD domain services. LDAP always existed for the AD DS version.
Unfortunately, the Azure AD DS is an additional - paying - service which is still in preview.
What this thread is asking for is a way to authenticate Confluence against the users included in Azure AD, which is included in any Office 365 business subscription (afaik).
Disiclaimer: this is how I understood it, but I could be wrong.
Regards,
Johan
Microsoft has released LDAP access to Azure AD.
https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-admin-guide-configure-secure-ldap/
This is not resolved. We use Confluence cloud and just want direct cloud-to-cloud SSO the same way hundreds of other apps do, using OAuth as Rick mentioned.
I connected our Confluence to Azure AD last week - and it works perfektly fine!
Take a look at the following link: https://azure.microsoft.com/en-us/services/active-directory-ds/
I think this feature suggestion can be set to resolved.
For additional information: https://redmondmag.com/articles/2015/10/15/azure-active-directory-previews.aspx
Azure AD Domain Services provides managed cloud based domain services such as domain join, group policy, LDAP & Kerberos/NTLM authentication in the Azure cloud that are fully compatible with Windows Server Active Directory. With these services, you get the full value of Windows Server AD in the cloud domain, without having to deploy, manage, monitor and patch domain controllers.
Next month, I am going to migrate JIRA, Confluence and Bitbucket server to Azure. I expected that Atlassian products support Azure Active Directory.
However, they didn't support AAD but only Windows Activce Directory.
So, please support Azure Active Directory sooner rather than later.
I agree, this is a priority for us. Also, I do believe it could easily be integrated with Azure AD using the OAuth 2.0 / OpenID Connect. I really think this could be added as a native option just like Okta (although I am no expert in either).
Would be good to start with getting this ticket assigned.
is it correct to say if that Atlassian supports OAuth 2.0, it can be used with Azure AD?
Seems like it!
https://msdn.microsoft.com/nl-nl/library/azure/dn645545.aspx
As an system admin, i am really happy with their free Azure AD which can connect to multiple locally AD forests with special add-on software.
From Azure AD, we can also use Box.com, Google Apps, Sales Force and many other online websites we use..
I have been a long time supporter of Atlassian supporting OpenID Connect for SSO authentication to Atlassian Online.I have moved from Kodak to KodakAlaris. At KodakAlaris, we have standardized on Azure AD for B2Employee and B2Business. We use Jira Online and desperately want/need SSO to improve user experience and security. With AAD, SAML 2.0 or OIDC are federated SSO option. I have always considered Atlassian a leader but know that in this space Atlassian is way behind in supporting modern authentication standards. Crowd is not really a good solution unless it's only purpose in this context is to deliver the AAD Connector for Atlassian Online and is otherwise hidden and is not an extra licensing cost.
I want to chime in on this. Adding AAD-support to a Enterprise SaaS-product should be a priority task in 2016. Office 365 (with requires and drives Azure AD adoption) is currently eating up market shares, meaning that a lot of companies already has AAD deployed. Microsoft is positioning AAD as a SaaS-identity proxy to eliminate the need for deep LDAP integration to on premise servers.
Furthermore; AAD provides Multi Factor Protection as a built in feature, and for the premium tier it also provide self service password reset functionality that would be sweet to integrate with the Jira Service Desk.
So, don't wait for AAD to provide LDAP-support; it might likely not happen. You need to implement native support for AAD; trust me - it will be worth it. I'm currently advising customers on SaaS-tools, and AAD-support is becoming a "must" requirement.
Azure AD has now a feature called domain services, which permit LDAP access to Azure AD.
Unfortunately this feature only work in a private Azure Network, so you have to run your Jira product on a VM in your Azure Cloud.
My company is looking to migrate to Azure AD so being to authenticate our Atlassian products through Azure would be tremendous.
I wonder if they even got people working on CROWD or if they just haven't been bothered with shutting it down
@Bruno Vincent, indeed it is paid for. As is the plugin you are promoting. The security aspect you brought up is worth noting. If one feels unsure about opening their AD through an encrypted connection, connected with live data of their office365 users the "LDAPS -> Azure AD Domain Services" should be given considerable thought around the security implications. Just as would be needed with the plugin.