Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-3607

Provide support for Windows Azure Active Directory

    • 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.

      Atlassian Update - 18 August 2017

      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

            agknn added a comment -

            @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.

            agknn added a comment - @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.

            @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).

            Bruno Vincent added a comment - @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).

            agknn added a comment -

            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".

            agknn added a comment - 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?

            Adam Sanders added a comment - 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).

            Bruno Vincent added a comment - @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.

            Patrick van der Rijst added a comment - 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

            Bruno Vincent added a comment - 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

            Bruno Vincent added a comment - 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...

            Joost Van den Cruyce added a comment - 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...

            PJ van Dyk added a comment -

            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:

            https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap

            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>(&amp;(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>(&amp;(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.

             

             

            PJ van Dyk added a comment - 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: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap 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>(&amp;(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>(&amp;(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. 

            Jira Administrator added a comment - @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)

            Joost Van den Cruyce added a comment - @russel: we use premium, but I think sso should also work with basic version. (if that's what you mean)

            +1

            Could you use the free version of Azure AD or did you need to send one of the premium versions of Azure AD?

             

            Jira Administrator added a comment - 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...

            Joost Van den Cruyce added a comment - 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...

            jared1820597353 added a comment -

            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.

            jared1820597353 added a comment - 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. 

            Jira Administrator added a comment - Ah, yes! Sorry about that. Would that functionality sway you to move to the cloud based version?  Just out of curiosity. 

            jared1820597353 added a comment -

            That functionality appears to only apply to Atlassian Cloud products, not the server products.

            jared1820597353 added a comment - That functionality appears to only apply to Atlassian Cloud products, not the server products.

            Jira Administrator added a comment - 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.

            Patrick van der Rijst added a comment - Is this so much different than regular Active Directory? So many users nowadays use Azure's AD.

            Ashton added a comment -

            +1

            Ashton added a comment - +1

            ucas_wills added a comment -

            +1

            ucas_wills added a comment - +1

            Kal Heer added a comment -

            +1

            Kal Heer added a comment - +1

            adiedler added a comment -

            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.

            adiedler added a comment - 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.

            +1

            Jonathan Basse added a comment - +1

            +1

            David Ferguson added a comment - +1

            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.

            Dave Theodore [Coyote Creek Consulting] added a comment - 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.

            Adam added a comment -

            +1

            Adam added a comment - +1

            +1

            Syscom added a comment -

            +1

            Syscom added a comment - +1

            +1

            Kakeru Ibuta added a comment - +1

            +1

            +1

            Philipp Lamp added a comment - +1

            +1

            Peter Stranne added a comment - +1

            +1

            Orlando Kelly added a comment - +1

            fdesterke added a comment -

            +1

            fdesterke added a comment - +1

            Kind of silly this isn't supported yet.

            Deleted Account (Inactive) added a comment - Kind of silly this isn't supported yet.

            +1
            For us it is also a must have being able to authenticate against MS Azure AD.

            Michael Orthey added a comment - +1 For us it is also a must have being able to authenticate against MS Azure AD.

            +1

            +1

            Stij Vijncke added a comment - +1

            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.

            Jerry Wiltse added a comment - 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

            Johan Van Noten added a comment - 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

            fabian added a comment -

            fabian added a comment - 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.

            Jerry Wiltse added a comment - 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.

            with Oauth? With waht tech then, we don't like to use ldap..

            Rick Beemterboer added a comment - with Oauth? With waht tech then, we don't like to use ldap..

            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.

            Deleted Account (Inactive) added a comment - 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.

            ILYUNG added a comment -

            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.

            ILYUNG added a comment - 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.

            +1

            Guy Woolliams added a comment - +1

            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.

            Jerry Wiltse added a comment - 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..

            Rick Beemterboer added a comment - 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.

            Steve Braunschweiger added a comment - 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.

            Magnus Tjerneld added a comment - 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.

            Julien Deloubes added a comment - 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.

            This would be great! thank you

            Greg Austin added a comment - This would be great! thank you

            We would like Azure AD SSO as well.

            Jason Frehner added a comment - We would like Azure AD SSO as well.

            My company is looking to migrate to Azure AD so being to authenticate our Atlassian products through Azure would be tremendous.

            Lee Walswick added a comment - My company is looking to migrate to Azure AD so being to authenticate our Atlassian products through Azure would be tremendous.

            @Diogo: Yeah, same here.

            Karsten Hilgers added a comment - @Diogo: Yeah, same here.

            We have a very much need for this. Our user base is all on Azure AD.

            Diogo Lemos added a comment - We have a very much need for this. Our user base is all on Azure AD.

            I wonder if they even got people working on CROWD or if they just haven't been bothered with shutting it down

            Christian Winther added a comment - I wonder if they even got people working on CROWD or if they just haven't been bothered with shutting it down

            I note that Atlassian have never bothered to comment on this request.

            Paul Tetley added a comment - I note that Atlassian have never bothered to comment on this request.

              Unassigned Unassigned
              hhung Helen Hung (Inactive)
              Votes:
              225 Vote for this issue
              Watchers:
              164 Start watching this issue

                Created:
                Updated:
                Resolved: