Navigating Microsoft Entra ID Integrations for Slack, MongoAtlas, Salesforce, and More

In the era of rapid cloud technology advancement, where Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) are integral to numerous projects, the demand for seamless integration of diverse cloud services is undeniable. Microsoft, a major player in this landscape, invested considerable time in crafting the user-friendly Microsoft Entra ID service. However, despite meticulously laid-out instructions from vendors, specialists often encounter issues when configuring integrations with platforms such as Slack, Salesforce, or Datadog. Documentation falls short in providing answers to specific questions.

The Social Discovery Group team faced these challenges as well, and in this article, we will offer insights on how to navigate and resolve them.

In its portfolio of 50+ dating platforms, the Social Discovery Group utilizes various technologies and cloud services to guarantee their security and reliability. We have extensive experience in integrating and configuring different systems, including peer-to-peer connections between various clouds.

Microsoft Entra ID is a cloud solution for identity and access management, serving as a directory and authentication service operating in the cloud. Microsoft Entra ID offers authentication and authorization services for various Microsoft and non-Microsoft services. Within this article, we will explore the integration of the following cloud systems: Slack, MongoAtlas, ElasticCloud, Salesforce, and Datadog.

Slack

Due to the absence of a precise guide, we decided to create our own, detailing all the headaches that arose along the way. So, let's navigate to the "Enterprise Application" section in Azure.

It's necessary to create a new corporate application (this can be done in a few clicks). Next, access the application we've just created and configure Single Sign-On – SAML. Make changes from top to bottom:

1. Identifier: https://slack.com
2. Reply URL: https://<DOMAIN NAME>.slack.com/sso/saml (in case you have ent Grid – https://<DOMAIN NAME>.enterprise.slack.com/sso/saml )
3. Sign-on URL: https://<DOMAIN NAME>.slack.com/sso/saml/start
4. Logout URL: https:// <DOMAIN NAME>.slack.com/sso/saml/logout

Create a "Member" role (or choose another name). Next, create a test user in Microsoft Entra ID and add them to our application. Then, go to the Admin Center in Slack. Follow the steps: Slack Admin - Authentication - SAML configuration - Configure

The next step is to configure SAML. We recommend paying attention to the "Display Name" setting. Further, in the settings, uncheck "Update Profile on login," disallow changing the email address and Display Name.

There is also an option to customize the text on the login button and prohibit users from logging in using any other method except SSO. After this, you should be able to sign in to Slack using your Microsoft account. If any additional fields or settings are needed, this can be done through Azure AD Provision.

To add a new attribute, go to User Attributes and select Add New Mapping. Choose the desired source attribute that you want to be displayed in Slack and associate it with the corresponding Slack attribute.

After adding the necessary attributes and saving the settings, proceed to Provision on Demand to test the functionality. Upon a positive outcome, you will receive the following:

Next, you need to go to Slack and specify which attributes to display in the complete user profile and where to retrieve them. Go to Profiles and choose the information to be displayed and where it will be pulled from. In this case, SCIM corresponds to Azure AD.

Next, we recommend adding the necessary users from Active Directory to Slack to experience the seamless integration. We also want to bring attention to an issue encountered when removing users: if a user is manually deleted from Slack (via the Slack admin center), an error will persist, indicating that the user cannot be transferred to Slack due to insufficient permissions. This occurs because Entra ID retains information about users within the scope and assigns them a unique ID. Deleting and re-adding a user in Slack is perceived as a new user by Entra ID, leading to permission issues during updates.

Check the documentation here.

MongoAtlas

For MongoAtlas, the process follows a similar path. You'll also need to create a new corporate application; for ease, enter "MongoDB Atlas — SSO" in the search field. More detailed instructions can be found here.

Next, proceed to the Single Sign-On settings, where you'll need to input the following:

1. In the "Identifier" text field, enter the URL using the following template: https://www.okta.com/saml2/service-provider/<Customer_Unique>

2. In the "Response URL" text field, enter the URL using the template:

   https://auth.mongodb.com/sso/saml2/<Customer_Unique>

3. In the "Login URL" text field, enter the URL using the template: https://cloud.mongodb.com/sso/<Customer_Unique>

We recommend paying attention to the Attributes section and configuring it as shown in the screenshot below (it was essential to add "memberOf").

Next, on the "Setting up Single Sign-On with SAML" page, go to the "SAML Signing Certificate" section and find the XML metadata for federation. Select "Download" to download the certificate and save it locally (Federation Metadata XML). We will need it later in MongoDB Atlas.

In the "Setting up MongoDB Atlas — SSO" section, copy the respective URLs. Next, navigate to MongoDB Atlas -> Organization -> Settings -> Federated Authentication Settings.

Begin by adding the Microsoft Entra ID credential provider in Atlas. Input the respective URLs mentioned in the previous step from the Microsoft portal (Issuer URI, Login URL, Single Sign-On URL), upload the Identity Provider Signature Certificate, and configure the remaining settings as shown in the screenshot below.

Click "Next" and save the metadata file locally, as you will need to upload it later in Azure on the Single Sign-On configuration page.

Next, add, map, and validate the domain, for example, using the corresponding TXT records generated in MongoDB Atlas. After that, link your domain with the credential provider and move on to the most interesting part: role configuration.

We've created the following roles as an example, each with specific permissions granted to projects. Then, you need to map these roles to Azure roles. Go to "App roles" for your application, create, and add roles with values exactly matching the names you just assigned to these roles in MongoAtlas.

Afterward, add users to the application in the Microsoft Entra ID Enterprise Application and assign them the appropriate roles. Activate "Sign in with Azure SSO" in the Federation Management section in MongoDB Atlas and verify the correct functioning of the configured settings.

Refer to the documentation here for more detailed instructions.

Elastic Cloud

Let's move on to the integration with Elastic Cloud. The fundamental steps for creating an application in the Enterprise Application Entra ID are similar to the previous ones. There, you can find information on where to obtain the Identifier or Logout URL. However, we encountered an issue with attributes, so we'll provide a screenshot of our working configuration.

We created two roles - a reader and a superuser.

Here, you can create as many roles as you need. Role settings in Elasticsearch are configured in Role Mappings and look as follows:

Now comes the interesting part. Two things need to be done: add Azure SSO configuration for Kibana and Elasticsearch. To achieve this, follow these steps:

1. Navigate to the editing section of your Elasticsearch Cloud deployment to update the elasticsearch.yml configuration. Add the following lines:

   
   

“ xpack:

security:

authc:

realms:

saml:

saml-azure-ad:

order: 2

attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"

attributes.groups: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"

attributes.name: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"

attributes.mail: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

idp.metadata.path: "APP Federation metadata URL"

idp.entity_id: "Azure Entra ID Identifier"

sp.entity_id: "Kibana endpoint"

sp.acs: "Kibana endpoint/api/security/v1/saml"

sp.logout: "Kibana endpoint/logout" “

After adding and modifying the values highlighted in red to match your configuration, click "Save." Elastic Cloud will validate all changes and initiate the cluster update. This process may take a few minutes.

2. Following the successful completion of the previous step, you need to edit the kibana.yml configuration to allow logins from Microsoft Entra ID in addition to the default login. To do this, add the following lines to the settings:

“ xpack.security.authc.providers:

saml.saml1:

order: 0

realm: saml-azure-ad

description: "Log in with Azure Entra ID"

basic.basic1:

order: 1 ”

After completing the previous two steps, another login option should be available on your Kibana login page. Next, proceed with adding users to the application in the Microsoft Entra ID Enterprise Application and assigning them the necessary roles.

Refer to the documentation here for more information.

Salesforce

Integration with Salesforce was a bit more complex than the previous ones. The initial steps are similar, but attention should be given to the Provisioning section. There are nuances regarding specifying admin credentials under which account synchronization will occur, and enabling Attribute Mapping is necessary.

Here is an example of our configuration settings in the screenshot. We didn't encounter any significant issues with attributes, but we'll also provide a screenshot of the ones we used.

In Salesforce itself, there weren't any particular nuances, and we proceeded with the following steps as outlined in this guide.

Datadog

During the integration with Datadog, we also encountered some issues. The primary documentation that guided us can be found here. For troubleshooting nuances, we referred to this guide.

Everything started smoothly, and initially, it seemed like there wouldn't be any issues. As usual, we created a new Enterprise Application in Microsoft Entra ID.

In the "Set up Single Sign-On with SAML" section, pay attention to the location you selected for your Datadog account. In our case, it was the Europe region.

As mentioned earlier, for MongoAtlasDB, we add the additional attribute "memberOf" for role mapping.

Save all the settings and download the Federation Metadata XML. Upload this file into the SAML settings in Datadog. Here is a convenient link for reference. Datadog SAML Settings (replace "EU" with the appropriate domain zone if your location differs). It should look like the screenshot below.

In the organization's Login Methods settings, keep only what is necessary (in my case, I disabled password login and Google Authenticate). Add roles in Azure in the application registration for Microsoft Entra ID.

Here comes the most interesting part. Navigate to SAML Group Mappings -> Role Mappings in Datadog and add the key, value, and role. It seems straightforward. See the screenshot below.

But it doesn’t work, and it keeps giving the error "There are no AuthNMappings for this user".

For quite a while, we tried to understand what we were doing wrong, reviewing all the documentation, logs, and troubleshooting pages. Unfortunately, there was no mention of this anywhere. In the end, the solution is simple: follow the configuration shown in the screenshot below.

In the KEY field, enter the string: http://schemas.microsoft.com/ws/2008/06/identity/claims/role

After doing this, everything started working successfully.

"This is just a small part of the systems that we integrated with Microsoft Entra ID. We hope that the insights shared here will serve as a helpful resource, streamlining your integration processes and saving valuable time. In conclusion, the following advantages of using Microsoft Entra ID can be highlighted: Single Sign-On, which doesn’t require entering the password multiple times; no additional components required; ease of configuration and administration; group policies and groups; device registration; and high-level security.