LDAP Sync like data center

[ramyaallena]

Hi,

We are trying to move from data center to jira cloud. We are using an identity provider which is configured for SAML single sign-on authentication in our Data Center. And our jira is also connected to an external LDAP directory to populate users and group memberships.

To achieve the same in cloud, do we need to have Atlassian Guard? I went through the documentation but want to get confirmation from people who are using it. 

And Is there any other alternative solution to achieve the sme in cloud?

Documentation :
https://support.atlassian.com/migration/docs/atlassian-guard-and-cloud-migrations/

https://www.atlassian.com/software/access

Thanks

Allena

[Ed Letifov _TechTime - New Zealand_ · Accepted solution]

Hello, @ramyaallena 

1) Yes, you will need Atlassian Guard, as a gateway to "the whole Cloud", that is:

• integrated for SAML SSO (clearly should be possible since you already do SAML) with your IdP; and
• integrated for User Provisioning with your IdP, do review the list of IdPs that support this: 
  https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/ 

2) You may want to check some answers I've provided earlier on how to configure SSO and User Provisioning correctly for Azure AD/Entra ID even if your IdP is different:

• https://community.atlassian.com/t5/Atlassian-Access-questions/Integrate-Azure-AD-with-Atlassian-Cloud/qaq-p/1852575#M3417
• https://community.atlassian.com/t5/Atlassian-Account-questions/SAML-SSO-with-Azure-AD-does-not-work-when-using-quot-Continue/qaq-p/2085502
• https://community.atlassian.com/t5/Jira-Service-Management/Azure-AD-login-and-incoming-email-not-matching-up/qaq-p/1821809#M88619

Specifically, in the case of Azure AD/Entra ID, the documentation published (by Atlassian?) to the Microsoft documentation site completely omits a very important detail about setting "Matching Precedence" correctly and could, and indeed has been, misunderstood by the admins. And to complicate this, the default value of that being set to the "User Principal Name" is wrong too in a general enterprise use case, since UPNs can change – it should instead be the Object ID.

3) Getting Guard will imply you will have to verify your domain and claim accounts first.

This usually reveals many historical accounts from your domain that somehow made it Cloud (by accessing someone else's instances, or Trello, or University, or this very Community). Make sure you review and deactivate the inactive ones.

Our app User Management for Jira Cloud allows you to do this based on the last login date.

With the current version you can query managed users via Organisation source and deactivate or export account ids into CSV and remove product access groups.

You can get similar information from CSV exports that Atlassian provides, limit to users you want to deactivate or un-license in bulk and then use that as a CSV filter for a bulk operation.

See Getting Started with User Management for Jira Cloud and our FAQ.

If you have any questions please reach out to our 24x7 support

[Ashwini_More _miniOrange · Accepted solution]

Hi @ramyaallena

To provision users in Jira Cloud, you can opt-in for the miniOrange LDAP Sync connector which doesn't require Atlassian Guard. Here is how the solution works:

1. Connect the external LDAP to the miniOrange IAM solution as per this document:  Link

2. Connect miniOrange SCIM Solution to Jira via Jira SCIM App.

You will need Atlassian Guard to connect with your identity provider for SSO purposes.

Please reach out to us over the service portal here for more details and end-to-end setup.

PS: I work for miniOrange, one of the Top SSO vendors in the Atlassian marketplace.