Configurer l’authentification basée sur certificat ou l’authentification basée sur l’application uniquement

Rversion finale: Yokohama

Mis à jour 30 janv. 2025

6 minutes de lecture

Une intégration initiale est requise pour l’authentification à l’aide d’objets d’application. L’application et le principal de service sont utilisés de manière interchangeable, mais une application est comme un objet de classe tandis qu’un principal de service est comme une instance de la classe.

Pour plus d’informations sur les objets principaux d’applications et de services dans Azure Active Directory, consultez Objets principaux d’applications et de services dans Azure Active Directory. Pour un flux visuel détaillé sur la création d’applications dans Azure AD, consultez Créer une application Azure Active Directory et un principal de service pouvant accéder aux ressources.

Pour configurer l’authentification basée sur certificat ou l’authentification basée sur l’application uniquement, procédez comme suit :

Enregistrez l’application dans Azure AD.
Affectez des autorisations d’API à l’application.
Pour que l’objet d’application puisse accéder aux ressources, il doit disposer de l’autorisation d’application Exchange.ManageAsApp et Mail.ReadWrite.
Générez un certificat auto-signé et accordez l’accès à la clé privée.
Créez et configurez un certificat X.509 auto-signé, qui est utilisé pour authentifier votre application auprès d’Azure AD, tout en demandant le jeton d’accès de l’application uniquement. Les certificats de nouvelle génération (CNG) ne sont pas pris en charge pour l’authentification d’application uniquement avec Exchange. Les certificats CNG sont créés par défaut dans les versions modernes de Windows. Vous devez utiliser un certificat d’un fournisseur de clés CSP. (-provider = 'Fournisseur de cryptographie fort Microsoft').
Joindre le certificat à l’application Azure AD.
Affectez des rôles Azure AD à l’application.
Le rôle Azure AD d’administrateur de conformité doit être affecté à l’application.
Créez un nouveau principal de service.

Étape 1 : enregistrer l’application dans Azure AD

Ouvrez le portail Azure AD.
Dans la zone de recherche en haut de la page, saisissez Inscriptions d’applications.
Sélectionnez Inscriptions d’applications dans les résultats de la section Services.
Vous pouvez également accéder à la page Inscriptions de l’application à l’aide de https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
Sur la page Inscriptions de l’application , sélectionnez Nouvelle inscription.

Sur la pageEnregistrer une application , configurez les paramètres suivants :


Champ	Description
Nom	Saisissez un élément descriptif. Par exemple, ExO PowerShell CBA.
Types de compte pris en charge	Vérifiez que les comptes de ce répertoire organisationnel uniquement (< YourOrganizationName > uniquement : locataire unique) sont sélectionnés. Pour rendre l’application multilocataire pour les scénarios délégués Exchange Online, sélectionnez la valeur Comptes dans n’importe quel répertoire organisationnel (Tout répertoire Azure AD : multilocataire).

Une fois l’enregistrement de l’application terminé, sélectionnez S’inscrire et fermez la page de l’application.

Étape 2 : affecter des autorisations d’API à l’application

Les procédures décrites dans cette section remplacent les autorisations par défaut qui ont été automatiquement configurées pour la nouvelle application. L’application n’a pas besoin des autorisations par défaut qui ont été remplacées.

Sur la page de l’application, sélectionnez Manifeste sous Gestion .
Dans la page Manifeste, recherchez l’entrée requiredResourceAccess (à la ligne 47 ou vers cette date).

Modifiez les valeurs resourceAppId, resourceAccess id et type resourceAccess comme indiqué dans l’extrait de code suivant :

"requiredResourceAccess": [
		{
			"resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
			"resourceAccess": [
				{
					"id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
					"type": "Role"
				}
			]
		},
		{
			"resourceAppId": "00000003-0000-0000-c000-000000000000",
			"resourceAccess": [
				{
					"id": "e2a3a72e-5f79-4c64-b1b1-878b674786c9",
					"type": "Role"
				}
			]
		}
	],

Sélectionnez Enregistrer.
Sur la page Manifeste , sélectionnez les autorisations d’API sous Gestion.

Sur la page des autorisations d’API , renseignez les champs.


Champ	Description
Nom de l’API/des autorisations	Vérifiez que la valeur `Exchange.ManageAsApp` et `Mail.ReadWrite` est affichée.
Statut	La valeur incorrecte actuelle est Non accordé pour <Organisation> et cette valeur doit être modifiée. Sélectionnez Accorder le consentement de l’administrateur pour <Organisation>, lisez la boîte de dialogue de confirmation qui s’ouvre, puis sélectionnez Oui. La valeur d’état devrait maintenant être Accordé pour < Organisation >.

Fermez la page des autorisations d’API actuelles (pas l’onglet du navigateur) pour revenir à la page Inscriptions d’applications.

Étape 3 : Générer un certificat auto-signé et accorder l’accès à la clé privée

Créez un certificat x.509 auto-signé en procédant comme suit :

Utilisez les applets de commande New-SelfSignedCertificate, Export-Certificate et Export-PfxCertificate dans une session Windows PowerShell avec élévation de privilèges (exécuter en tant qu’administrateur) pour demander un certificat auto-signé et l’exporter vers .cer et .pfx (SHA1 par défaut). Par exemple :

# Create certificate
$mycert = New-SelfSignedCertificate -DnsName "snowsecops.onmicrosoft.com" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(2) -KeySpec KeyExchange -Provider "Microsoft Strong Cryptographic Provider"

# Generate password fro private key
$mypwd = ConvertTo-SecureString -String '<password>' -Force -AsPlainText

# Export certificate to .pfx file
$mycert | Export-PfxCertificate -FilePath mycert.pfx -Password $mypwd

# Export certificate to .cer file
$mycert | Export-Certificate -FilePath mycert.cer

Fournissez un accès par clé privée à l’utilisateur du service MID en procédant comme suit :
1. Ouvrez MMC (Microsoft Management Console).
2. À partir de votre console de gestion Microsoft (MMC), accédez à Certificats (ordinateur local) > Personnel > Certificats.
  (Si MMC n’a pas d’élément de menu, ajoutez-le en accédant à Fichier > Ajouter Supprimer le composant logiciel enfichable.
3. Cliquez avec le bouton droit sur le certificat que vous avez généré.
4. Développer Toutes les tâches > Gérer les clés privées
5. Ajoutez l’utilisateur du service MID à la liste des accesseurs.

Étape 4 : Joindre le certificat à l’application Azure AD

Après avoir enregistré le certificat auprès de votre application, vous pouvez utiliser l’empreinte digitale pour l’authentification.

Dans l’onglet Applications détenues de la page Inscription des applications , à la fin de l’étape 2, sélectionnez votre application.
Si vous devez revenir à la page d’inscription des applications , utilisez https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/%7E/RegisteredApps, vérifiez que l’onglet Applications détenues est sélectionné, puis sélectionnez votre application.
Sélectionnez Certificats et secrets sous Gérer.
Sur la page Certificats et secrets qui s’ouvre, sélectionnez Télécharger le certificat.
Accédez au certificat autosigné (fichier .cer ) que vous avez créé à l’étape 3.
Une fois terminé, sélectionnez Ajouter.
Le certificat s’affiche maintenant dans la section Certificats.
Notez l’empreinte du certificat et fermez la page actuelle Certificats et secrets .

Étape 5 : Affecter des rôles Azure AD à l’application

Ouvrez le portail Azure AD.
Dans le champ de recherche en haut de la page, recherchez Rôles et Administrateurs.
Sélectionnez les rôles et les administrateurs Azure AD dans les résultats de la section Services.
Vous pouvez également accéder à la page Rôles et administrateurs Azure AD à l’aide de https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade.
Sur la page Rôles et administrateurs Azure AD , recherchez et sélectionnez l’un des rôles pris en charge en cliquant sur le nom du rôle (et non sur la case à cocher) dans les résultats.
Recherchez et sélectionnez le rôle d’administrateur de conformité .
Sur la page Affectations , sélectionnez Ajouter des affectations.
Dans la fenêtre contextuelle Ajouter des affectations , recherchez et sélectionnez l’application que vous avez créée à l’étape 1.
Une fois terminé, sélectionnez Ajouter.
Revenez à la page Affectations et vérifiez que le rôle a été affecté à l’application.

Étape 6 : Créer un nouveau principal de service

Important :

Assurez-vous d’être connecté à PowerShell Sécurité et conformité avant d’effectuer les étapes de création d’un nouveau principal de service. La création d’un nouveau principal de service sans connexion à PowerShell ne fonctionnera pas (votre ID d’application Azure et votre ID d’objet sont nécessaires pour créer le nouveau principal de service).

Exécutez la commande suivante pour stocker les détails de l’application Azure que vous avez inscrite à l’étape 1 (<AppName>) dans une variable :
```
Install-Module -Name AzureAD 
Import-Module -Name AzureAD 
Connect-AzureAD 
$AADApp = Get-AzureADServicePrincipal -SearchString"<AppName>"
```
Pour des informations détaillées sur la syntaxe et les paramètres, consultez Get-AzureADServicePrincipal.
Dans la même fenêtre PowerShell, connectez-vous à PowerShell Sécurité et conformité :
```
Import-Module ExchangeOnlineManagement
Connect-IPPSSession -CertificateThumbPrint "<Your_Certificate_ThumbPrint>" -AppID $AADApp.AppId -Organization "<Your_organization>
```
Exécutez les commandes suivantes pour créer un objet principal de service pour l’application Azure :
```
New-ServicePrincipal -AppId $AADApp.AppId -ObjectId $AADApp.ObjectId -DisplayName "<Descriptive Name>"
```
Pour plus d’informations sur la syntaxe et les paramètres, consultez New-ServicePrincipal.