Configurer Azure AD et SharePoint pour les identités managées

L'utilisation d' Azure AD, de SharePoint et de Power Platform exige de plus en plus de sécurité et de configurations plus précises. Pour automatiser des processus tels que la gestion de documents, l'intégration de Dataverse ou la préparation de la création et de la gestion d'utilisateurs dans Azure AD à partir de données SharePoint, l'utilisation des mêmes identifiants ne suffit plus.

Depuis mars 2025, Microsoft a renforcé la sécurité d' accès aux tables de documents SharePoint depuis Dynamics 365 et les applications pilotées par modèle , notamment via Power Automate ou les appels d'API Dataverse. Par conséquent , pour assurer la continuité et la sécurité de nos activités, nous devons utiliser une application enregistrée sur Azure, des identités gérées et des informations d'identification fédérées .

Contexte : Pourquoi avez-vous besoin d’une application Azure pour accéder à SharePoint ?

Lorsqu'une solution métier dans Dynamics 365 ou Power Platform utilise la table de documents SharePoint , elle le fait souvent en dehors de la grille de documents traditionnelle d'une application pilotée par modèle. Cela implique d'accéder à SharePoint via des flux Power Automate, des plug-ins, des connecteurs personnalisés ou des appels directs à l'API Dataverse, autant de méthodes qui nécessitent des autorisations étendues sur les sites et les bibliothèques.

Jusqu'à récemment, cet accès pouvait s'appuyer sur des mécanismes hérités moins contraignants, mais Microsoft a décidé de le supprimer en mars 2025 afin de renforcer la sécurité de l'environnement. Concrètement, si vous ne préparez pas la nouvelle configuration, vous risquez de rencontrer des problèmes tels que des blocages dans les flux de travail, des intégrations incapables de lire ou d'écrire des documents, ou des défaillances soudaines dans les automatisations.

La solution consiste à créer et configurer une application dans Azure (Microsoft Entra ID) qui servira d'identité centralisée pour les intégrations, à lui attribuer les autorisations SharePoint appropriées et à la lier à Dataverse à l'aide d'identités managées et d'informations d'identification fédérées . Vous pourrez ainsi continuer à exécuter des automatisations qui, par exemple, lisent des listes SharePoint, gèrent des documents ou servent même de base à des processus qui créent ou gèrent ensuite des utilisateurs dans Azure AD à partir de ces informations.

Enregistrement d'une application dans Azure avec des autorisations sur SharePoint

La première étape de cette configuration consiste à enregistrer une application dans Azure (identifiant Microsoft Entra) qui représentera vos automatisations lorsqu'elles devront communiquer avec SharePoint. Cette application fonctionnera avec des autorisations d'application (non déléguées), ce qui lui permettra de fonctionner indépendamment d'un utilisateur connecté.

Pour commencer, connectez-vous au portail Azure avec un compte disposant des autorisations nécessaires pour gérer les inscriptions d'applications et les paramètres d'Entra ID. Une fois connecté, accédez à la section « Inscriptions d'applications » , généralement située dans Microsoft Entra ID ou directement sous « Services Azure ». C'est ici que vous créerez l'identité que Dataverse utilisera pour accéder à SharePoint.

Cliquez sur « Nouvelle inscription » et donnez à l’application un nom explicite afin qu’elle puisse être facilement identifiée comme celle qui gère l’authentification auprès de SharePoint (par exemple, un nom lié à Power Platform ou à l’organisation). Dans la section « Types de comptes pris en charge » , sélectionnez l’option qui limite l’accès aux « Comptes de cet annuaire d’organisation uniquement », car l’application fonctionnera au sein de votre locataire.

Une fois l'assistant terminé, appuyez sur « Enregistrer » pour finaliser la création de l'application. Sur l'écran récapitulatif de l'application enregistrée, dans la section « Informations de base » ou « Essentiels » , vous trouverez deux valeurs essentielles : l' « ID d'application (client) » et l' « ID d'annuaire (locataire) ». Ces identifiants GUID seront indispensables ultérieurement pour lier l'application à Dataverse et configurer les identités gérées.

Notez et sauvegardez soigneusement l' ID de l'application (clientId) et l'ID du répertoire (tenantId) , car vous les utiliserez tous deux lors de la création des enregistrements d'identité gérés dans Dataverse et lors de la définition des informations d'identification fédérées qui généreront le jeton correct pour SharePoint.

Ensuite, vous devez accorder à l'application les autorisations nécessaires pour l' API SharePoint . Dans le menu de navigation de l'application, accédez à « Autorisations API » et sélectionnez « Ajouter une autorisation ». Choisissez le service SharePoint et, lorsque le type d'autorisation vous est demandé, sélectionnez « Autorisations d'application », ce qui permet à l'application de fonctionner de manière autonome, sans intervention de l'utilisateur.

Dans la liste des autorisations disponibles, recherchez et sélectionnez « Sites.FullControl.All » . Cette autorisation accorde à l’application un contrôle total sur tous les sites SharePoint du locataire, ce qui est idéal pour les scénarios où Power Platform gère intensivement les documents, les dossiers et les métadonnées. Une fois sélectionnée, cliquez sur « Ajouter des autorisations » pour l’ajouter à l’application.

Une fois l'autorisation ajoutée, l'étape cruciale demeure : l'octroi du consentement de l'administrateur . Sur le même écran d'autorisations, vous trouverez l'option « Accorder le consentement de l'administrateur pour <nom du locataire> » . Effectuez cette action avec un compte disposant de privilèges d'administrateur général ou équivalents, afin que l'autorisation SharePoint soit activée et que l'application puisse l'utiliser en production.

Création d'identités gérées dans le Dataverse

Une fois l'application Azure prête et les autorisations SharePoint adéquates, l'étape suivante consiste à connecter cette identité à Dataverse à l'aide d'enregistrements d'identité managés . Cela permet à l'environnement Power Platform d'utiliser cette application pour générer des jetons et accéder à SharePoint en toute sécurité.

Ce processus implique la création d'enregistrements dans les tables internes de Dataverse, et plus précisément dans la table « managedidentity » , qui représente chaque identité gérée associée à un environnement. Vous pouvez effectuer cette opération via l' API web de Dataverse , en utilisant des outils tels que Postman, Insomnia ou tout client HTTP permettant l'envoi de requêtes authentifiées.

Dans la table managedidentity Vous devrez insérer une nouvelle ligne avec une série de champs spécifiques. Le champ applicationid doit contenir le GUID du ID de l'application (client) que vous avez obtenue lors de l'enregistrement de l'application dans Azure. Parallèlement, le champ tenantid stockera le GUID de ID d'annuaire (locataire) du même dossier de candidature.

Outre ces identifiants, d'autres champs de configuration déterminent le type et la portée des informations d'identification. credentialsource vous devez définir la valeur 2, ce qui indique un source d'informations d'identification gérée (IsManaged) via la plateforme. Sur le terrain subjectscope La valeur doit être utilisée 1, ce qui correspond à un Type de portée EnvironmentScopeC'est-à-dire, lié à un environnement Dataverse spécifique.

La requête HTTP adressée à l'API Web Dataverse prendra la forme suivante : POSTEZ vers l'URL [Organization URI]/api/data/v9.2/managedidentitiesavec des en-têtes OData typiques (par exemple, Content-Type application/json, OData-MaxVersion 4.0, etc.) et un corps JSON similaire à celui-ci, adapté à vos valeurs réelles :

POST [Organization URI]/api/data/v9.2/managedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"applicationid": "<appId>",
"credentialsource": 2,
"subjectscope": 1,
"tenantid": "<tenantId>"
}

Si tout se passe bien, l'API renverra une réponse. HTTP 204 Aucun contenu, accompagné d'un en-tête OData-EntityId qui inclut l'URL de l'enregistrement nouvellement créé. Dans cette URL, vous verrez un GUID qui correspond à l'identifiant unique (GUID) de l'enregistrement. managedidentityid, quelque chose comme aaaaaaaa-0000-1111-2222-bbbbbbbbbbbbConservez cet identifiant car vous en aurez besoin pour le lier à l'identité gérée SharePoint spécifique.

Associer une identité gérée SharePoint dans Dataverse

Une fois la base d'identités gérée créée dans la table managedidentity, il est nécessaire de le lier à une entrée de type Identité gérée SharePoint, qui vit sur la table sharepointmanagedidentityC’est cet élément qui relie explicitement Dataverse à l’utilisation de SharePoint via cette identité.

Pour ce faire, vous devrez insérer une nouvelle ligne dans le tableau. sharepointmanagedidentity en utilisant, encore une fois, le API Web Dataverse. La campagne uniquename Il doit contenir un nom unique au sein de l'environnement, par exemple : "new_ppmiforsharepointauth", ce qui indique clairement que cette identité est destinée à l'authentification auprès de SharePoint.

À la campagne name Vous pouvez utiliser une étiquette descriptive et conviviale, telle que "Identidad administrada para la autenticación de SharePoint" ou similaire, qui vous permet de le localiser rapidement à l'aide d'outils d'administration ou de scripts.

L'élément le plus important est la relation avec l'enregistrement d'identité gérée de base que vous avez créé précédemment. Cela se fait à l'aide du champ de lien. [email protected], dont la valeur doit pointer vers la ressource /managedidentities(<managedidentityid>), en remplaçant <managedidentityid> par le GUID renvoyé précédemment lors de la création de l'identité gérée.

La requête à l'API web Dataverse ressemblerait à ceci, en utilisant à nouveau POSTEZ Mais maintenant contre la table sharepointmanagedidentities:

POST [Organization URI]/api/data/v9.2/sharepointmanagedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"uniquename": "new_ppmiforsharepointauth",
"name": "Managed Identity For SharePoint Auth",
"[email protected]": "/managedidentities(<managedidentityid>)"
}

Comme précédemment, la réponse sera HTTP 204 Aucun contenu avec l'en-tête OData-EntityId pointant par exemple vers la nouvelle inscription sharepointmanagedidentities(bbbbbbbb-1111-2222-3333-cccccccccccc)Ce GUID est le sharepointmanagedidentityidque vous devrez utiliser lors de la création de l'identificateur de sujet pour l'identification fédérée dans Azure.

Configuration des informations d'identification fédérées dans l'application Azure

Une fois l'application enregistrée dans Azure et les identités managées créées dans Dataverse, la dernière étape majeure consiste à configurer une authentification fédérée lors de l'enregistrement de l'application. Cette authentification permet à Power Platform d'échanger des jetons en toute sécurité avec Azure AD, en s'appuyant sur la relation établie entre l'identité managée et SharePoint.

Pour le configurer, retournez sur le portail Azure et connectez-vous avec votre identifiant Microsoft . Dans le menu, accédez à « Inscriptions d’applications » et repérez l’inscription que vous avez créée pour gérer l’accès à SharePoint. Ouvrez-la pour modifier ses paramètres d’authentification et de certificat.

Dans le panneau latéral du registre, accédez à « Certificats et secrets », puis à l’ onglet « Informations d’identification fédérées » . Vous y trouverez l’ option « Ajouter une information d’identification » , qui vous permettra de définir l’émetteur et le sujet représentant Dataverse.

Dans le champ « Scénario » des informations d’identification fédérées, sélectionnez « Autre émetteur », car vous devrez spécifier manuellement l’URL de l’émetteur et le modèle d’ID du sujet. Cela vous permet de respecter la configuration exacte requise par Power Platform pour les identités gérées SharePoint.

À la campagne "Émetteur" Vous devez écrire une URL au format https://login.microsoftonline.com/<tenantId>/v2.0, en remplaçant <tenantId> par le GUID de ID d'annuaire (locataire) depuis votre application Azure. Cette URL représente le point d'émission des jetons Azure AD pour votre locataire.

Le domaine clé est celui de "Valeur", où le identifiant du sujet qui sera utilisée dans la relation fédérée. Le format attendu est une chaîne de caractères du type :
/eid1/c/pub/t/<base64-encoded-tenantId>/a/<base64-encoded-appid>/Env/<orgid>/sharepointmanagedidentity/<sharepointmanagedidentityid>

Dans cette structure, le locataireId encodé en Base64 URL sécurisée il est placé dans <base64-encoded-tenantId>et l'identificateur d'application Power Platform qui fait office d'identité gérée (un AppId spécifique fourni par Microsoft) est également encodé en Base64 dans <base64-encoded-appid>. Aussi <orgid> est le GUID de l'environnement ou de l'organisation Dataverse, tandis que <sharepointmanagedidentityid> correspond au GUID de l'entrée créée dans la table sharepointmanagedidentity.

Une fois ces informations complétées, cliquez sur « Ajouter » pour créer l’authentification fédérée. Dès lors, l’identité gérée Dataverse liée à SharePoint pourra obtenir des jetons grâce à cette configuration, permettant ainsi aux flux externes, aux plugins ou aux intégrations d’accéder à la table de documents SharePoint de manière contrôlée et sécurisée.

Générer l'identifiant du sujet avec PowerShell

La construction manuelle de la chaîne de sujet pour l'authentification fédérée peut s'avérer fastidieuse, notamment en raison de l'encodage des GUID en Base64 compatible avec les URL et du respect d'une structure très précise. Pour simplifier cette tâche, vous pouvez utiliser un script PowerShell qui génère automatiquement l'identifiant du sujet ainsi que les autres valeurs nécessaires.

Le script proposé définit une fonction appelée GetSharePointManagedIdentifyConfig, qui reçoit plusieurs paramètres obligatoires : le type d'environnement (EnvironmentType), le GUID du Identité gérée SharePoint (SharePointManagedIdentityId), L' identifiant du locataire et l' EnvironmentId associé à l'environnement Dataverse dans lequel vous appliquez la configuration.

Paramètre Type d'environnement Il doit s'agir d'une des valeurs reconnues par le script : Public, Gov, GovFR, High, DoD, MoonCake, USNat o USSecChacun d'eux est associé à une combinaison différente de URL de l'émetteur et URL de la ressource d'échange de jetonscar les différents clouds souverains et les différentes régions utilisent des points de terminaison d'authentification différents.

Dans le script, une fonction interne est déclarée appelée Convert-ToBase64Url, qui est responsable de la transformation d'un GUID en sa version encodée dans URL Base64 sécuriséeLa procédure convertit le GUID en un tableau d'octets, l'encode en Base64 et supprime les caractères de remplissage (=) et remplace les caractères + y / par - y _ respectivement, garantissant ainsi que le résultat est valide pour une utilisation dans les URL.

Le script définit également une constante avec le Identifiant d'application d'identité gérée Power Platform, 58e835ab-2e39-46a9-b797-accce6633447Il s'agit de l'identifiant utilisé par Dataverse pour ces intégrations. Cette valeur est également transmise à la fonction d'encodage Base64 compatible avec les URL afin de correspondre à la chaîne de sujet finale.

La configuration de l'environnement est gérée via une liste ($environmentConfigList) qui attribue à chaque groupe d'environnements un URL de l'émetteurune URL de la ressource d'échange de jetons est notre valeur principale. Préfixe du sujetPar exemple, pour les environnements du type Public, Gov y GovFR l'émetteur est utilisé https://login.microsoftonline.com/ et un préfixe de sujet /eid1/c/pub, alors que pour les environnements de type High o DoD est utilisé https://login.microsoftonline.us/ avec un préfixe différent.

Lorsque vous invoquez la fonction GetSharePointManagedIdentifyConfigCela permet de rechercher la configuration appropriée en fonction de Type d'environnement fourni, construit le URL de l'émetteur concaténer l'identifiant du locataire et le suffixe /v2.0et encode l'identifiant du locataire et l'identifiant de l'application gérée en Base64. À partir de là, il génère la chaîne de sujet selon le modèle suivant :
{SubjectPrefix}/t/{encodedTenantId}/a/{encodedAppId}/Env/{EnvironmentId}/sharepointmanagedidentity/{SharePointManagedIdentityId}

La fonction renvoie un résultat formaté contenant les données d'entrée, les valeurs calculées et, enfin, l' URL du sujet pour la configuration des informations d'identification fédérées . C'est cette dernière valeur que vous devez copier et coller dans le champ « Valeur » lors de la création des informations d'identification fédérées dans l'application Azure.

Pour utiliser le script, commencez par l'enregistrer sous le nom suivant : GetSharePointManagedIdentifyConfig.ps1 et ensuite vous créez un deuxième script test.ps1 Importez-le et fournissez les paramètres appropriés. test.ps1 Une structure de table de hachage comme celle-ci est couramment utilisée :

. .\GetSharePointManagedIdentifyConfig.ps1
$configInput = @{
environmentType = "<environmentType>"
sharePointManagedIdentityId = "<sharePointManagedIdentityId>"
tenantId = "<tenantId>"
environmentId = "<environmentId>"
}
GetSharePointManagedIdentifyConfig @configInput

En courant test.ps1Vous verrez un résultat contenant les données d'entrée, les identifiants encodés, l'émetteur calculé et le résultat final. URL du sujetCette dernière valeur est celle utilisée dans l'identifiant fédéré ; par exemple, quelque chose de similaire à :
/eid1/c/pub/t/u7uqqgAAzMwREd3dIiLu7g/a/qzXoWDkuqUa3l6zM5mM0Rw/Env/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/sharepointmanagedidentity/bbbbbbbb-1111-2222-3333-cccccccccccc

Grâce à cette combinaison d'une application Azure avec des autorisations SharePoint, d'identités gérées dans le Dataverse et d'informations d'identification fédérées soigneusement configurées , vous disposez d'une base solide conforme aux dernières exigences de sécurité de Microsoft. Vous pouvez ainsi concevoir des flux de travail et des solutions exploitant les listes et documents SharePoint comme source de données pour des processus avancés (notamment la création et la gestion d'utilisateurs dans Azure AD), en ayant l'assurance que l'authentification est bien gérée, évolutive et répond aux exigences de sécurité des environnements modernes.