-
Suggestion
-
Resolution: Fixed
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/
- relates to
-
- Closed
- mentioned in
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page")
Page
No Confluence page found with the given URL.
-
Page
Failed to load
-
Page
Failed to load
-
Page
Failed to load
-
Page Loading...
-
-
-
-
[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.
@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.