Introduction

The purpose of this document is to describe the implementation and configuration of the Azure cloud connector on a customer's internal network.

Implementation Steps

Step 0: Gather information from your Microsoft setup

Do you have a Microsoft Enterprise agreement (EA) or a Microsoft Customer Agreement (MCA)?

One tip is that the Microsoft Enterprise Agreement is a three-year commitment-based agreement, while the Microsoft Customer Agreement is a transactional agreement

If you’re an EA customer, you’ll always get legacy usage details records (see in the Field list). If you’re a Microsoft Customer Agreement customer, you'll always get modern usage details records. (see in the Field list)

Field list used by Sopht

Step 1: Create the application

Create an application: go into Microsoft Entra admin center, then in the left menu go to Application > App Registrations.

This application must be of the “Single tenant” type. It is not necessary to specify “Redirect URI”

More information about application account creation : https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app

<aside> ⚠️

Store the “Azure Application (client) ID” value generated for this application. It will be needed later

</aside>

2025-06-27 09.21.50 entra.microsoft.com 3b17160fc2d9.png

Step 2: Create the Access Key

Once the application is created, it is necessary to generate an authentication code. To do this, you must go through the “App Registrations” part of the Azure portal, select the application created for Sopht and finally go to the “Certificates and secrets” submenu.

Here it is necessary to create an authentication code using the “New client secret” button in the “Client secrets” tab. We advise to extend the validity to 1, or even 2 years. Note the validity period, you will need it later on.

2025-06-27 09.24.35 entra.microsoft.com f646e038c44b.png

<aside> ⚠️

Store the value Generated value, it is the Azure generated secret that will be needed later.

This information will not be displayed later, so if you forgot to copy it, you have to create another secret.

Be sure to copy the “Value” column. The Secret ID column is useless to Sopht.

</aside>

Step 3: Grant proper Roles

Option 1:  if you have few subscriptions you want Sopht to track

Option 2: if you have a lot of subscriptions you want Sopht to track

Step 4: [Optional] put in place anonymization

For confidentiality/security reasons you might want to put in place anonymization to send altered data to Sopht. This can be done for fields that contained sensitive information for you, but that is required by Sopht. To be noted, if those fields are identifiers, the anonymization algorithm should be the same applied on all sources, so that anonymized identifiers will remain consistent across sources. Fields to anonymize or filter out will depend on which azure data model you are using: the modern or legacy one.

If you want to only send some of the fields to Sopht, list the azure field names you want Sopht to fetch from the Field List at the top of this page, you will need them at a later step.

If you want to anonymize some fields, list the azure field names you want Sopht to anonymize from the Field List at the top of this page, you will need them at a later step.

Anonymization is done by hashing fields value with MD5. It can only be applied on CUR fields.

<aside> ⚠️

if you anonymize an identifier field, but want to make a link between Azure data and data from another source, for instance Azure inventory data and a CMDB, you need to make sure the ID in the other source will be hashed with the same algo, so that Sopht can match them.

</aside>

Step 5: [Optional] Configure Data filtering

You may want to send to Sopht only part of the data (= some of the cur lines). For instance if the subscription holds data for all country or all BUs, but you want Sopht only to monitor one country or one BU.

The configuration to filter data will depend on which azure data model you are using: the modern or legacy one.

Contact your CSM to setup a tech meeting to explain your needs.

Step 6: Gather validation data

Gather data that you will use to validate that Sopht is collecting all the data from the scope agreed upon, and only from that scope.

Provide us your monthly invoice amount for the past few months. We will check it against our data to validate that we have all the data we need.

Also, if you did not provide a list of subscriptions to filter on, provide us with the list of subscriptions that we should get data from for those months. It can help us investigate if there is an issue in the configuration of the access rights.

Step 7: ask for Sopht API key

Ask Sopht to send you the two following API keys:

Step 8: Check the configuration

You should have gathered the following information

Application must have 2 assigned role for subscription:

Optional (possible filters):