Partager via

Résoudre des problèmes liés au provisionnement d’application locale

  • Article

Résoudre les problèmes de test de connexion

Après la configuration de l’agent d’approvisionnement et de l’hôte connecteur ECMA (Extensible Connectivity), il est temps de tester la connectivité du service d’approvisionnement Microsoft Entra à l’agent d’approvisionnement, l’hôte ECMA et l’application. Pour effectuer ce test de bout en bout, sélectionnez Tester la connexion dans l’application dans le portail Azure. Veillez à attendre 10 à 20 minutes après avoir affecté un agent initial ou changé d’agent avant de tester la connexion. Si, passé ce délai, le test de connexion échoue, essayez les étapes de résolution des problèmes suivantes :

  1. Vérifiez que l’agent et l’hôte ECMA sont en cours d’exécution :

    1. Sur le serveur où l’agent est installé, ouvrez Services en accédant à Démarrer>Exécuter>Services.msc.

    2. Sous Services, vérifiez que les services Agent d'approvisionnement Microsoft Entra Connect et Microsoft ECMA2Host sont présents, et que leur état est En cours d’exécution.

      Capture d’écran montrant que le service ECMA est en cours d’exécution.

  2. Vérifiez que le service hôte du connecteur ECMA répond aux demandes.

    1. Sur le serveur sur lequel l’agent est installé, lancez PowerShell.
    2. Accédez au dossier dans lequel l’hôte ECMA a été installé, tel que C:\Program Files\Microsoft ECMA2Host.
    3. Accédez au sous-répertoire Troubleshooting.
    4. Exécutez le script TestECMA2HostConnection.ps1 dans ce répertoire. Fournissez comme arguments le nom du connecteur et le jeton secret lorsque vous y êtes invité. 
      PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1
Supply values for the following parameters:
ConnectorName: CORPDB1
SecretToken: ************
    5. Ce script envoie une requête SCIM GET ou POST pour vérifier que l’hôte du connecteur ECMA fonctionne et répond aux requêtes. Si la sortie n’indique pas qu’une connexion HTTP a réussi, vérifiez que le service est en cours d’exécution et que le jeton secret correct a été fourni.

  3. Vérifiez que l’agent est actif en accédant à votre application dans le portail Azure, en sélectionnant connectivité administrateur, en sélectionnant la liste déroulante des agents, puis en vérifiant que votre agent est actif.

  4. Vérifiez si le jeton secret fourni est identique au jeton secret local. Accédez à l’environnement local, fournissez à nouveau le jeton secret, puis copiez-le dans le portail Azure.

  5. Vérifiez que vous avez attribué au moins un agent à l’application dans le portail Azure.

  6. Après avoir attribué un agent, vous devez attendre de 10 à 20 minutes pour finaliser l’inscription. Le test de connectivité ne fonctionne pas tant que l’inscription n’est pas terminée.

  7. Vérifiez que vous utilisez un certificat valide qui n’a pas expiré. Accédez à l’onglet Paramètres de l’hôte ECMA pour afficher la date d’expiration du certificat. Si le certificat a expiré, cliquez Generate certificate pour générer un nouveau certificat.

  8. Redémarrez l’agent de provisionnement en accédant à la barre des tâches sur votre machine virtuelle, en recherchant l’agent de provisionnement Microsoft Entra Connect. Cliquez avec le bouton droit sur Arrêter, puis sélectionnez Démarrer.

  9. Si vous continuez à voir The ECMA host is currently importing data from the target application même après avoir redémarré l’Hôte du connecteur ECMA et l’agent de provisionnement et avoir attendu la fin de l’importation initiale, vous devrez peut-être annuler et redémarrer la configuration du provisionnement de l’application dans le portail Azure.

  10. Lorsque vous fournissez l’URL du locataire dans le portail Azure, veillez à ce qu’il respecte le modèle suivant. Vous pouvez remplacer localhost par votre nom d’hôte, mais cela n’est pas obligatoire. Remplacez connectorName par le nom du connecteur que vous avez spécifié dans l’hôte ECMA. Le message d’erreur « ressource non valide » indique généralement que l’URL ne respecte pas le format attendu.

    https://localhost:8585/ecma2host_connectorName/scim

  11. Accédez au dossier suivant pour passer en revue les journaux de l’agent de provisionnement : C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace

    1. Si vous voyez l’erreur suivante, ajoutez le compte de service « NT SERVICE\AADConnectProvisioningAgent » au groupe local appelé « Utilisateurs du journal des performances ». Cela élimine l’erreur d’exception « Impossible d’initialiser le collecteur de métriques » en autorisant le compte à accéder à la clé de Registre souhaitée : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
Unable to initialize metrics collector, exception: 'System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
  1. Lors de la configuration de l’hôte ECMA, veillez à fournir un certificat avec un objet qui correspond au nom d’hôte de votre serveur Windows. Le certificat généré par l’hôte ECMA le fera automatiquement pour vous, mais ne doit être utilisé qu’à des fins de test.
Error code: SystemForCrossDomainIdentityManagementCredentialValidationUnavailable

Details: We received this unexpected response from your application: Received response from Web resource. Resource: https://localhost/Users?filter=PLACEHOLDER+eq+"8646d011-1693-4cd3-9ee6-0d7482ca2219" Operation: GET Response Status Code: InternalServerError Response Headers: Response Content: An error occurred while sending the request. Please check the service and try again.

Impossible de configurer l’hôte ECMA, d’afficher les journaux dans l’observateur d’événements ou de démarrer le service Hôte ECMA

Pour résoudre les problèmes suivants, exécutez l’assistant de configuration de l’hôte ECMA en tant qu’administrateur :

  • J’obtiens une erreur lorsque j’ouvre l’Assistant Hôte ECMA.

    Capture d’écran montrant une erreur de l’Assistant ECMA.

  • Je peux configurer l’Assistant Hôte ECMA, mais je ne vois pas les journaux de l’hôte ECMA. Dans ce cas, vous devez ouvrir l’assistant de configuration de l’hôte ECMA en tant qu’administrateur et configurer un connecteur de bout en bout. Cette étape peut être simplifiée par l’exportation d’un connecteur existant et sa réimportation.

    Capture d’écran montrant les journaux des hôtes.

  • Je peux configurer l’Assistant Hôte ECMA, mais je ne parviens pas à démarrer le service Hôte ECMA.

    Capture d’écran montrant le service hôte.

Activer la journalisation détaillée

Par défaut, la valeur switchValue pour l’hôte du connecteur ECMA est définie sur Verbose. Ce paramètre permet d’obtenir une journalisation détaillée qui vous aidera à résoudre les problèmes. Vous pouvez changer le niveau de détail et choisir Error si vous souhaitez limiter le nombre de journaux émis aux erreurs uniquement. Lors de l’utilisation du connecteur SQL sans authentification intégrée Windows, nous vous recommandons de définir switchValue sur Error pour garantir que la chaîne de connexion n’est pas émise dans les journaux. Pour changer le niveau de détail et choisir Erreur, mettez à jour switchValue avec « Erreur » dans les deux emplacements, comme indiqué ci-dessous.

L’emplacement du fichier pour la journalisation détaillée du service est C:\program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config.

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <startup>  
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
    </startup> 
    <appSettings> 
      <add key="Debug" value="true" /> 
    </appSettings> 
    <system.diagnostics> 
      <sources> 
    <source name="ConnectorsLog" switchValue="Error"> 
          <listeners> 
            <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
              <filter type=""/> 
            </add> 
          </listeners> 
        </source> 
        <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
        <source name="ECMA2Host" switchValue="Error"> 
          <listeners>  
            <add initializeData="ECMA2Host" type="System.Diagnos

L’emplacement du fichier pour la journalisation de l’Assistant est C:\Program Files\Microsoft ECMA2Host\Wizard\Microsoft.ECMA2Host.ConfigWizard.exe.config.

      <source name="ConnectorsLog" switchValue="Error"> 
        <listeners> 
          <add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack"> 
            <filter type=""/> 
          </add> 
        </listeners> 
      </source> 
      <!-- Choose one of the following switchTrace:  Off, Error, Warning, Information, Verbose --> 
      <source name="ECMA2Host" switchValue="Error"> 
        <listeners> 
          <add initializeData="ECMA2Host" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ECMA2HostListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />

Interroger le cache d’hôte ECMA

L’hôte ECMA dispose d’un cache d’utilisateurs dans votre application qui est mis à jour selon la planification que vous spécifiez dans la page de propriétés de l’Assistant d’hôte ECMA. Pour interroger le cache, procédez comme suit :

  1. Définissez l’indicateur de débogage sur true.

    N’oubliez pas que la définition de l’indicateur de débogage sur true désactive l’authentification sur l’hôte ECMA. Vous devrez la redéfinir sur false et redémarrer le service hôte ECMA une fois que vous aurez terminé d’interroger le cache.

    L’emplacement du fichier pour la journalisation verbeuse du service est C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config.

    <?xml version="1.0" encoding="utf-8"?>
<configuration>
   <startup>  
       <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> 
   </startup> 
   <appSettings> 
     <add key="Debug" value="true" /> 
   </appSettings>

  2. Redémarrez le service Microsoft ECMA2Host .

  3. Attendez que l’hôte ECMA se connecte aux systèmes cibles et relire son cache à partir de chacun des systèmes connectés. S’il existe de nombreux utilisateurs dans ces systèmes connectés, ce processus d’importation peut prendre plusieurs minutes.

  4. Interrogez ce point de terminaison à partir du serveur sur lequel l’hôte ECMA est installé, en remplaçant {connector name} par le nom de votre connecteur, spécifié dans la page de propriétés de l’hôte ECMA :https://localhost:8585/ecma2host_{connectorName}/scim/cache.

    1. Sur le serveur sur lequel l’agent est installé, lancez PowerShell.
    2. Accédez au dossier dans lequel l’hôte ECMA a été installé, tel que C:\Program Files\Microsoft ECMA2Host.
    3. Accédez au sous-répertoire Troubleshooting.
    4. Exécutez le script TestECMA2HostConnection.ps1 dans ce répertoire et fournissez comme arguments le nom du connecteur et la ObjectTypePath valeur cache. Lorsque vous y êtes invité, tapez le jeton secret configuré pour ce connecteur. 
      PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1 -ConnectorName CORPDB1 -ObjectTypePath cache
Supply values for the following parameters:
SecretToken: ************
    5. Ce script envoie une requête SCIM GET pour vérifier que l’hôte du connecteur ECMA fonctionne et répond aux requêtes. Si la sortie n’indique pas qu’une connexion HTTP a réussi, vérifiez que le service est en cours d’exécution et que le jeton secret correct a été fourni.

  5. Définissez l’indicateur Debug sur false ou supprimez le paramètre une fois que vous avez terminé d’interroger le cache.

  6. Redémarrez le service Microsoft ECMA2Host .

L’attribut cible est manquant

Le service d’approvisionnement découvre automatiquement des attributs dans votre application cible. Si vous constatez qu’un attribut cible est manquant dans la liste d’attributs cibles du portail Azure, exécutez l’étape de résolution des problèmes suivante :

  1. Passez en revue la page Sélectionner les attributs de la configuration de votre hôte ECMA pour vérifier que l’attribut a été sélectionné afin d’être exposé dans le portail Azure.
  2. Vérifiez que le service Hôte ECMA est exécuté.
  3. Après avoir attribué le ou les agents à l’application d’entreprise, en effectuant l’étape de connexion de test et en enregistrant les identifiants de l’administrateur, actualisez le navigateur. Cela force le service d’approvisionnement à effectuer une requête/des schemas et à découvrir les attributs cibles.
  4. Examinez les journaux de l’hôte ECMA pour vérifier qu’une requête /schemas a été effectuée, et passez en revue les attributs dans la réponse. Ces informations seront utiles pour la résolution du problème.

Collecter les journaux à partir de l’observateur d’événements en tant que fichier zip

Vous pouvez utiliser un script pour capturer les journaux dans un fichier zip et les exporter.

  1. Sur le serveur sur lequel l’agent est installé, cliquez avec le bouton droit sur PowerShell dans le menu Démarrer, puis sélectionnez sur Run as administrator.
  2. Accédez au dossier dans lequel l’hôte ECMA a été installé, tel que C:\Program Files\Microsoft ECMA2Host.
  3. Accédez au sous-répertoire Troubleshooting.
  4. Exécutez le script CollectTroubleshootingInfo.ps1 dans ce répertoire.
  5. Le script crée un fichier ZIP dans ce répertoire contenant les journaux des événements.

Examiner les événements dans l’observateur d’événements

Une fois le mappage du schéma d’hôte de connecteur ECMA configuré, démarrez le service pour qu’il écoute les connexions entrantes. Surveillez ensuite les requêtes entrantes.

  1. Sélectionnez le menu Démarrer, entrez observateur d’événements, puis sélectionnez Observateur d’événements.
  2. Dans l’Observateur d’événements, développez les journaux Applications et services, puis sélectionnez Journaux Microsoft ECMA2Host.
  3. À mesure que les modifications sont reçues par l’hôte du connecteur, les événements sont écrits dans le journal des applications.

Erreurs courantes

Error Résolution
Impossible de charger le fichier ou l’assembly « 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\Cache\8b514472-c18a-4641-9a44-732c296534e8\Microsoft.IAM.Connector.GenericSql.dll » ou l’une de ses dépendances. L’accès est refusé. Assurez-vous que le compte de service réseau dispose des autorisations « contrôle total » sur le dossier du cache. Si le compte dispose des autorisations nécessaires mais que .NET tente de créer une copie de la DLL du connecteur, il peut être nécessaire d’ajouter la DLL au Global Assembly Cache.
Style LDAP non valide du DN de l’objet. DN : username@domain.com ou Target Site: ValidByLdapStyle Vérifiez que la case « DN est une ancre » n’est pas cochée dans la page « Connectivité » de l’hôte ECMA. Vérifiez que la case « généré automatiquement » est cochée dans la page « Types d’objets » de l’hôte ECMA. Pour plus d’informations, consultez À propos des attributs d’ancre et des noms uniques.
ExportErrorCustomContinueRun. objectClass : valeur numérique invalide selon la syntaxe Vérifiez que le mappage de l’attribut d’approvisionnement à l’attribut objectClass inclut uniquement les noms de classes d’objets reconnues par le serveur d’annuaire.

Comprendre les requêtes SCIM entrantes

Les requêtes effectuées par Microsoft Entra ID à l’agent d’approvisionnement et à l’hôte du connecteur utilisent le protocole SCIM. Les requêtes effectuées de l’hôte vers des applications utilisent le protocole pris en charge par l’application. Les requêtes de l’hôte à l’agent pour Microsoft Entra ID s’appuient sur SCIM. Pour en savoir plus sur l’implémentation de SCIM, consultez Tutoriel : Développer et planifier le provisionnement d’un point de terminaison SCIM dans Microsoft Entra ID.

Le service d’approvisionnement Microsoft Entra effectue généralement un appel get-user pour rechercher un utilisateur factice dans trois situations : au début de chaque cycle d’approvisionnement, avant d’effectuer l’approvisionnement à la demande et lorsque la connexion de test est sélectionnée. Cette vérification garantit que le point de terminaison cible est disponible et retourne des réponses conformes SCIM au service d’approvisionnement Microsoft Entra.

Comment résoudre les problèmes liés à l’agent d’approvisionnement ?

Vous pouvez rencontrer les scénarios d’erreur suivants.

Échec du démarrage de l’agent

Vous pouvez recevoir un message d’erreur indiquant ceci :

Le service « Agent d’approvisionnement Microsoft Entra Connect » n’a pas pu démarrer. Vérifiez que vous disposez des droits suffisants pour démarrer les services système ».

Ce problème est généralement dû à une stratégie de groupe qui a empêché l’application d’autorisations sur le compte d’ouverture de session du service NT local créé par le programme d’installation (NT SERVICE\AADConnectProvisioningAgent). Ces autorisations sont nécessaires pour démarrer le service.

Pour résoudre ce problème :

  1. Connectez-vous au serveur avec un compte Administrateur.
  2. Ouvrez Services en y accédant ou en accédant à Démarrer>Exécuter>Services.msc.
  3. Sous Services, double-cliquez sur Microsoft Entra Connect Provisioning Agent.
  4. Sous l’onglet Ouvrir une session, remplacez ce compte par celui d’un administrateur de domaine. Ensuite, redémarrez le service.

Ce test vérifie que vos agents peuvent communiquer avec Azure via le port 443. Ouvrez un navigateur et accédez à l’URL précédents à partir du serveur sur lequel l’agent est installé.

Le délai de l’agent a expiré ou le certificat n’est pas valide

Les messages d’erreur suivants peuvent s’afficher si vous essayez d’inscrire l’agent.

Capture d’écran montrant que le délai d’attente de l’agent a expiré.

Ce problème est généralement dû au fait que l’agent ne peut pas se connecter au service d’identité hybride, et nécessite donc la configuration d’un proxy HTTP. Pour résoudre ce problème, configurez un proxy sortant.

L’agent de provisionnement prend en charge l’utilisation du proxy sortant. Vous pouvez le configurer en modifiant le fichier de configuration C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config de l'agent. Ajoutez les lignes suivantes à la fin du fichier, juste avant la balise </configuration> de fermeture. Remplacez les variables [proxy-server] et [proxy-port] par le nom de votre serveur proxy et les valeurs de port.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

L’inscription de l’agent échoue avec une erreur de sécurité

Vous pouvez recevoir un message d’erreur lorsque vous installez l’agent de provisionnement cloud.

Ce problème est généralement dû à l’incapacité de l’agent à exécuter les scripts d’inscription PowerShell en raison des stratégies d’exécution PowerShell locales.

Pour résoudre ce problème, modifiez les stratégies d’exécution PowerShell sur le serveur. Les stratégies de la machine et de l’utilisateur doivent être définies sur Undefined ou RemoteSigned. Si elles sont définies sur Unrestricted, vous verrez ce message d’erreur. Pour plus d’informations, consultez Stratégies d’exécution PowerShell.

Fichiers journaux

Par défaut, l’agent émet peu de messages d’erreur et d’informations sur la trace de la pile. Vous trouverez les journaux de suivi dans le dossier C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace.

Pour recueillir davantage d’informations afin de résoudre les problèmes liés à l’agent :

  1. Installez le module PowerShell AADCloudSyncTools comme décrit dans Module PowerShell AADCloudSyncTools pour la synchronisation cloud Microsoft Entra Connect.

  2. Utilisez l’applet de commande PowerShell Export-AADCloudSyncToolsLogs pour capturer les informations. Utilisez les commutateurs suivants pour affiner votre collecte de données. Utilisez :

    • SkipVerboseTrace pour exporter uniquement les journaux actuels sans capturer les journaux détaillés (par défaut = false).
    • TracingDurationMins pour spécifier une durée de capture différente (par défaut = 3 minutes).
    • OutputPath pour spécifier un autre chemin de sortie (par défaut = les documents de l’utilisateur).

En utilisant Microsoft Entra ID, vous pouvez superviser le service de provisionnement dans le cloud et de collecter les journaux locaux. Le service d’approvisionnement émet des journaux pour chaque utilisateur qui a été évalué dans le cadre du processus de synchronisation. Ces journaux peuvent être utilisés via l'interface utilisateur du portail Azure, les API et l’analytique des journaux d'activité. L’hôte ECMA génère également des journaux locaux. Il affiche chaque requête de provisionnement qui a été reçue et la réponse qui a été envoyée à Microsoft Entra ID.

Échec de l’installation de l’agent

  • L’erreur System.ComponentModel.Win32Exception: The specified service already exists indique que l’hôte ECMA précédent n’a pas été correctement désinstallé. Désinstallez l’application hôte. Accédez à Program Files et supprimez le dossier de l’hôte ECMA. Vous souhaiterez peut-être stocker le fichier de configuration à des fins de sauvegarde.

  • L’erreur suivante indique qu’un prérequis n’a pas été satisfait. Assurez-vous que .NET 4.7.1 est installé.

      Method Name : <>c__DisplayClass0_1 : 
  RegisterNotLoadedAssemblies Error during load assembly: System.Management.Automation.resources.dll
  --------- Outer Exception Data ---------
  Message: Could not load file or assembly 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\System.Management.Automation.resources.dll' or one of its dependencies. The system cannot find the file specified.

J’obtiens une erreur de DN de style LDAP non valide lors de la tentative de configuration de l’hôte connecteur ECMA avec SQL

Par défaut, le connecteur SQL générique s’attend à ce que le DN soit renseigné avec le style LDAP (lorsque l’attribut « DN est une ancre » n’est pas activé dans la première page de connectivité). Dans le message d’erreur Invalid LDAP style DN ou Target Site: ValidByLdapStyle, vous pouvez voir que le champ DN contient un nom d’utilisateur principal (UPN), plutôt qu’un DN de style LDAP attendu par le connecteur.

Pour résoudre ce message d’erreur, vérifiez que généré automatiquement est sélectionné sur la page Types d’objets lorsque vous configurez le connecteur.

Pour plus d’informations, consultez À propos des attributs d’ancre et des noms uniques.

Étapes suivantes