Partager via

Catalogue d’alertes Microsoft Entra Connect Health

  • Article

Le service Microsoft Entra Connect Health envoie des alertes indiquant que votre infrastructure d’identité n’est pas saine. Cet article contient des titres d’alertes, ainsi que les descriptions de celles-ci et les étapes de correction pour chacune d’elles.
Les trois phases d’alertes générées à partir du service Connect Health sont : Erreur, Avertissement et Préavertissement. Nous vous recommandons vivement de réagir immédiatement aux alertes déclenchées.
Les alertes Microsoft Entra Connect Health sont résolues en cas de condition de réussite. Les agents Microsoft Entra Connect Health détectent et signalent régulièrement au service les conditions de réussite. Pour certaines alertes, la suppression s’effectue en fonction d’un intervalle de temps. Concrètement, cela signifie que si la condition d’erreur n’est pas observée dans les 72 heures suivant la génération de l’alerte, cette dernière est automatiquement résolue.

Alertes générales

Nom de l’alerte Description Correction
Les données du service de contrôle d’intégrité ne sont pas à jour Les agents d’intégrité exécutés sur un ou plusieurs serveurs ne sont pas connectés au service de contrôle d’intégrité, lequel ne reçoit pas les données les plus récentes de ce serveur. Les dernières données traitées par le service de contrôle d’intégrité datent de plus de 2 heures. Assurez-vous que les agents d’intégrité ont une connectivité sortante vers les points de terminaison de service requis. En savoir plus

Alertes pour Microsoft Entra Connect (Synchronisation)

Nom de l’alerte Description Correction
Le service de synchronisation Microsoft Entra Connect ne fonctionne pas Le service Windows Microsoft Entra ID Sync n’est pas exécuté ou n’a pas pu démarrer. Par conséquent, les objets ne seront pas synchronisés avec Microsoft Entra ID. Démarrer Microsoft Entra ID Sync Services
  1. Cliquez sur Démarrer, Exécuter, tapez Services.msc, puis cliquez sur OK.
  2. Localisez le service Microsoft Entra ID Sync, puis vérifiez s’il est démarré. S’il n’a pas démarré, cliquez dessus avec le bouton droit, puis cliquez sur Démarrer.
Échec de l’importation à partir de Microsoft Entra ID L’opération d’importation depuis le Connecteur Microsoft Entra a échoué. Examinez les erreurs du journal des événements lié à l’opération d’importation pour obtenir plus d’informations.
La connexion à Microsoft Entra ID a échoué en raison d’un échec d’authentification La connexion à Microsoft Entra ID a échoué en raison d’un échec d’authentification. Par conséquent, les objets ne seront pas synchronisés avec Microsoft Entra ID. Examinez les erreurs du journal des événements pour obtenir plus d’informations.
Échec de l’exportation vers Active Directory L’opération d’exportation vers le Connecteur Active Directory a échoué. Examinez les erreurs du journal des événements lié à l’opération d’exportation pour obtenir plus d’informations.
Échec de l’importation depuis Active Directory L’importation depuis Active Directory a échoué. Par conséquent, des objets de certains domaines de cette forêt ne seront peut-être pas importés.
  • Vérifiez la connectivité du contrôleur de domaine
  • Exécutez une nouvelle importation manuellement
  • Examinez les erreurs du journal des événements lié à l’opération d’importation pour plus d’informations
    		•
    Échec de l’exportation vers Microsoft Entra ID L’opération d’exportation vers le Connecteur Microsoft Entra a échoué. Par conséquent, certains objets ne seront peut-être pas exportés correctement vers Microsoft Entra ID. Examinez les erreurs du journal des événements lié à l’opération d’exportation pour obtenir plus d’informations.
    La pulsation de la synchronisation de hachage du mot de passe a été ignorée lors des 120 dernières minutes. La synchronisation de hachage du mot de passe ne s’est pas connectée à Microsoft Entra ID au cours des 120 dernières minutes. Par conséquent, les mots de passes ne seront pas synchronisés avec Microsoft Entra ID. Redémarrer Microsoft Entra ID Sync Services :
    Notez que toute opération de synchronisation en cours sera interrompue. Vous pouvez choisir d’effectuer les étapes suivantes quand aucune opération de synchronisation n’est en cours.
    1. Cliquez sur Démarrer, Exécuter, tapez Services.msc, puis cliquez sur OK.
    2. Recherchez Microsoft Entra ID Sync, cliquez dessus avec le bouton droit, puis cliquez sur Redémarrer.
    Utilisation intensive du processeur détectée Le pourcentage de la consommation du processeur a dépassé le seuil recommandé sur ce serveur.
  • Il peut s’agir d’une hausse temporaire de la consommation du processeur. Vérifiez la tendance d’utilisation du processeur depuis la section Surveillance.
  • Examinez les principaux processus qui utilisent le plus le processeur sur le serveur.
    1. Vous pouvez utiliser le Gestionnaire des tâches ou exécuter la commande PowerShell suivante :
      get-process | Sort-Object -Descending CPU | Select-Object -First 10
    2. Si des processus inattendus utilisent le processeur de manière excessive, arrêtez ces processus en utilisant la commande PowerShell suivante :
      stop-process -ProcessName [name of the process]
  • Si les processus observés dans la liste ci-dessus s’avèrent être des processus prévus, qui sont exécutés sur le serveur et que la consommation du processeur est continuellement proche du seuil, pensez à réévaluer la configuration requise pour le déploiement de ce serveur.
  • Par mesure de sécurité, pensez à redémarrer le serveur.
    		•
    Consommation élevée de mémoire détectée Le pourcentage de consommation de mémoire du serveur dépasse le seuil recommandé sur ce serveur. Examinez les principaux processus qui consomment le plus de mémoire sur le serveur. Vous pouvez utiliser le Gestionnaire des tâches ou exécuter la commande PowerShell suivante :
    get-process | Sort-Object -Descending WS | Select-Object -First 10
    Si des processus inattendus consomment de la mémoire haute, arrêtez les processus à l’aide de la commande PowerShell suivante :
    stop-process -ProcessName [name of the process]
  • Si les processus observés dans la liste ci-dessus se révèlent être des processus prévus, qui sont exécutés sur le serveur, pensez à réévaluer la configuration requise pour le déploiement de ce serveur.
  • Par mesure de sécurité, vous pouvez redémarrer le serveur.
    		•
    La synchronisation de hachage du mot de passe a cessé de fonctionner. La synchronisation de hachage du mot de passe s’est arrêtée. Par conséquent, les mots de passes ne seront pas synchronisés avec Microsoft Entra ID. Redémarrer Microsoft Entra ID Sync Services :
    Notez que toute opération de synchronisation en cours sera interrompue. Vous pouvez choisir d’effectuer les étapes suivantes quand aucune opération de synchronisation n’est en cours.
    1. Cliquez sur Démarrer, Exécuter, tapez Services.msc, puis cliquez sur OK.
    2. Recherchez la synchronisation Microsoft Entra ID, cliquez dessus avec le bouton droit, puis cliquez sur Redémarrer.
    L’exportation vers Microsoft Entra ID a été interrompue. Une limite de suppression accidentelle a été atteinte. L’opération d’exportation vers le Microsoft Entra ID a échoué. Le nombre d’objets à supprimer était supérieur à la limite configurée. Par conséquent, aucun objet n’a été exporté.
  • Le nombre d’objets marqués pour la suppression est plus important que le seuil défini. Assurez-vous qu’il s’agit du résultat souhaité.
  • Pour permettre à l’exportation de continuer, effectuez les étapes suivantes :
    1. Désactivez le seuil en exécutant Disable-ADSyncExportDeletionThreshold.
    2. Démarrer Synchronization Service Manager
    3. Exécutez l’exportation sur le connecteur avec le type = Microsoft Entra ID
    4. Une fois l’exportation des objets réussie, activez le Seuil en exécutant : Enable-ADSyncExportDeletionThreshold
    		•

    Alertes pour les services de fédération Active Directory (AD FS)

    Nom de l’alerte Description Correction
    La demande d’authentification de test (transaction synthétique) n’est pas parvenue à obtenir un jeton Les demandes d’authentification de test (transactions synthétiques) initiées à partir de ce serveur ne sont pas parvenues à obtenir un jeton après 5 tentatives. Cela peut être dû à des problèmes temporaires de réseau, de disponibilité du service de contrôleur de domaine des services de domaine Active Directory ou de serveur AD FS mal configuré. De ce fait, les demandes d’authentification traitées par le service FS (Federation Service) peuvent échouer. Veuillez noter que l’agent utilise le contexte Compte d’ordinateur local (Local Computer Account) pour obtenir un jeton du service FS (Federation Service). Assurez-vous que les mesures suivantes sont prises pour confirmer l’intégrité du serveur.
    1. Vérifiez que votre batterie ne contient aucune alerte supplémentaire non résolue pour ce serveur ou d’autres serveurs AD FS dans votre batterie.
    2. Vérifiez qu’aucun échec temporaire ne survient en ouvrant une session avec un utilisateur test depuis la page de connexion AD FS disponible sur https://{nom__de_votre_serveur_adfs}/adfs/ls/idpinitiatedsignon.aspx
    3. Accédez à https://testconnectivity.microsoft.com et choisissez l’onglet « Office 365 ». Exécutez le « test d’authentification unique Office 365 ».
    4. Vérifiez que votre nom de service AD FS peut être résolu depuis ce serveur en exécutant la commande suivante à partir d’une invite de commandes sur ce serveur. nslookup nom_de_votre_serveur_adfs

    Si le nom de service ne peut pas être résolu, référez-vous à la section FAQ pour obtenir des instructions sur l’ajout d’une entrée dans le fichier HOST de votre service AD FS avec l’adresse IP de ce serveur. Le module de transaction synthétique exécuté sur ce serveur pourra alors demander un jeton
    Le serveur proxy ne peut pas atteindre le serveur de fédération Ce serveur de proxy AD FS est incapable de contacter le service AD FS. Par conséquent, les demandes d’authentification traitées par ce serveur échouent. Suivez les étapes suivantes pour valider la connectivité entre ce serveur et le service AD FS.
    1. Assurez-vous que le pare-feu entre ce serveur et le service AD FS est configuré correctement.
    2. Vérifiez que la résolution DNS du nom de service AD FS pointe bien vers le service AD FS qui réside dans le réseau d’entreprise. Cela peut être obtenu via un serveur DNS qui sert ce serveur dans le réseau de périmètre ou via des entrées dans les fichiers HOSTS pour le service AD FS.
    3. Validez la connectivité réseau en ouvrant le navigateur sur ce serveur et en accédant au point de terminaison des métadonnées de fédération qui se trouve sur https://<your-adfs-service-name>/federationmetadata/2007-06/federationmetadata.xml
    Le certificat SSL arrive à expiration. Le certificat TLS/SSL utilisé par les serveurs de fédération expirera dans un délai de 90 jours. Une fois expiré, toutes les demandes qui nécessitent une connexion TLS valide échoueront. Par exemple, pour les clients Microsoft 365, les clients de messagerie ne pourront pas s’authentifier. Mettez à jour le certificat TLS/SSL sur chaque serveur AD FS.
    1. Bénéficiez du certificat TLS/SSL répondant aux exigences suivantes.
      1. L’utilisation améliorée de la clé constitue au moins une authentification du serveur.
      2. Objet du certificat ou Autre nom de l’objet (SAN) contient le nom DNS du service FS (Federation Service) ou le caractère générique approprié. Par exemple : sso.contoso.com ou *. contoso.com.
    2. Installez le nouveau certificat TLS/SSL sur chaque serveur, dans le magasin de certificats de l’ordinateur local.
    3. Vérifiez que le compte de service AD FS bénéficie d’un accès en lecture à la clé privée du certificat.

    Pour AD FS 2.0 dans Windows Server 2008 R2 :

    • Liez le nouveau certificat TLS/SSL au site Web IIS qui héberge le service FS. Veuillez noter que vous devez effectuer cette étape sur chaque serveur de fédération et serveur proxy de fédération.

    Pour AD FS dans Windows Server 2012 R2 et versions ultérieures :

  • Consultez Gestion des certificats SSL dans AD FS et WAP
    • Le service AD FS n’est pas en cours d’exécution sur le serveur Le service AD FS (service Windows) n’est pas exécuté sur ce serveur. De ce fait, toutes les demandes ciblées sur ce serveur échoueront. Pour démarrer le service AD FS (service Windows) :
    1. Connectez-vous au serveur en tant qu’administrateur.
    2. Ouvrez services.msc.
    3. Recherchez « Services de fédération Active Directory »
    4. Faites un clic droit et sélectionnez « Démarrer »
    Il se peut que le DNS du service FS (Federation Service) ne soit pas configuré correctement. Le serveur DNS peut être configuré afin d’utiliser un enregistrement CNAME pour le nom de la batterie AD FS. Il est recommandé d’utiliser l’enregistrement A ou AAAA pour AD FS afin que l’authentification intégrée de Windows fonctionne de manière transparente au sein de votre réseau d’entreprise. Assurez-vous que l’enregistrement du DNS de la batterie AD FS <Farm Name> n’est pas un enregistrement CNAME. Configurez-le pour qu’il soit un enregistrement A ou AAAA.
    L’audit AD FS est désactivé L’audit AD FS est désactivé pour le serveur. La section Utilisation d’AD FS du portail n’inclura pas les données de ce serveur. Si les audits AD FS ne sont pas activés, suivez ces instructions :
    1. Accordez le compte de service AD FS « Générer des audits de sécurité » sur le serveur AD FS.
    2. Ouvrez la stratégie de sécurité locale sur le serveur gpedit.msc.
    3. Accédez à « Configuration ordinateur\Paramètres Windows\Stratégies locales\Attribution des droits utilisateur ».
    4. Ajoutez le compte de Service AD FS pour avoir droit « Générer des audits de sécurité ».
    5. Exécutez la commande suivante depuis l’invite de commande :
      auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
    6. Mettez à jour les propriétés du service FS (Federation Service) pour inclure les audits de succès et d’échecs.
    7. Dans la console AD FS, choisissez « Modifier les propriétés du Service de fédération »
    8. Depuis la boîte de dialogue « Propriétés du service FS (Federation Service) », choisissez l’onglet Événements et sélectionnez « Audits des succès » et « Audits des échecs »

    Une fois ces étapes accomplies, les événements d’audit AD FS doivent être visibles depuis l’observateur d’événements. Pour vérifier :

    1. Accédez à Observateur d’événements/Journaux d’activité Windows/Sécurité.
    2. Sélectionnez Filtrer les journaux d’activité actuels et sélectionnez l’audit AD FS depuis la liste déroulante des sources d’événements. Pour un serveur AD FS actif sur lequel l’audit AD FS est activé, les événements doivent être visibles pour le filtrage ci-dessus.

    Si vous avez suivi les instructions précédentes, mais que vous voyez toujours cette alerte, il se peut qu’un objet de stratégie de groupe désactive l’audit AD FS. Cela est peut-être dû à l’une des raisons suivantes :

    1. Le compte de service AD FS s’est vu retirer le droit de générer des audits de sécurité.
    2. Un script personnalisé dans Objet de stratégie de groupe désactive les audits des succès et des échecs basés sur « Généré par application ».
    3. La configuration AD FS n’est pas activée pour générer des audits de succès/d’échec.
    Le certificat SSL AD FS est auto-signé. Vous utilisez actuellement un certificat auto-signé comme certificat TLS/SSL dans votre batterie AD FS. De ce fait, l’authentification du client de messagerie pour Microsoft 365 échouera.

    Mettez à jour le certificat TLS/SSL sur chaque serveur AD FS.

    1. Bénéficiez d’un certificat TLS/SSL publiquement approuvé répondant aux exigences suivantes.
    2. Le fichier d’installation du certificat dispose de sa propre clé privée.
    3. L’utilisation améliorée de la clé constitue au moins une authentification du serveur.
    4. Objet du certificat ou Autre nom de l’objet (SAN) contient le nom DNS du service FS (Federation Service) ou le caractère générique approprié. Par exemple : sso.contoso.com ou *. contoso.com.

    Installez le nouveau certificat TLS/SSL sur chaque serveur, dans le magasin de certificats de l’ordinateur local.

      Vérifiez que le compte de service AD FS bénéficie d’un accès en lecture à la clé privée du certificat.
      Pour AD FS 2.0 dans Windows Server 2008 R2 :
    1. Liez le nouveau certificat TLS/SSL au site Web IIS qui héberge le service FS. Veuillez noter que vous devez effectuer cette étape sur chaque serveur de fédération et serveur proxy de fédération.

      2. Pour AD FS dans Windows Server 2012 R2 ou versions ultérieures :
    2. Consultez Gestion des certificats SSL dans AD FS et WAP
    L’approbation entre le serveur proxy et le serveur de fédération n’est pas valide L’approbation entre le proxy du serveur de fédération et le service FS (Federation Service) n’a pas pu être établie ou renouvelée. Mettez à jour le certificat d’approbation du proxy sur le serveur proxy. Réexécutez l’assistant Configuration proxy.
    Protection par verrouillage extranet désactivée pour AD FS La fonctionnalité de protection par verrouillage Extranet est désactivée sur votre batterie de serveurs AD FS. Cette fonctionnalité protège vos utilisateurs contre les attaques de mot de passe par force brute à partir d’Internet, et empêche les attaques par déni de service dirigées contre vos utilisateurs lorsque des stratégies de verrouillage de compte Active Directory Domain Services sont appliquées. Lorsque cette fonctionnalité est activée, si le nombre de tentatives de connexion extranet d’un utilisateur (tentatives de connexion effectuées via un serveur WAP et AD FS) dépasse le seuil défini par « ExtranetLockoutThreshold », les serveurs AD FS cessent de traiter les autres tentatives de connexion pendant la durée définie par « ExtranetObservationWindow ». Nous vous recommandons vivement d’activer cette fonctionnalité sur vos serveurs AD FS. Pour activer la protection par verrouillage Extranet AD FS avec les valeurs par défaut, exécutez la commande suivante.
    Set-AdfsProperties -EnableExtranetLockout $true

    Si vous avez configuré des stratégies de verrouillage AD pour vos utilisateurs, vérifiez que la propriété « ExtranetLockoutThreshold » est définie sur une valeur inférieure à votre seuil de verrouillage AD DS. Cela garantit que les demandes dépassant le seuil défini pour AD FS sont supprimées et ne sont jamais validées par rapport à vos serveurs AD DS.
    Nom de principal du service (SPN) non valide pour le compte de service AD FS Le nom du principal de service du compte de service de fédération n’est pas inscrit ou n’est pas unique. Par conséquent, l’authentification intégrée de Windows à partir de clients joints au domaine peut être problématique. Utilisez la commande [SETSPN-L NomDuCompteDeService] pour répertorier les principaux du service.
    Utilisez la commande [SETSPN -X] pour rechercher les noms de principal du service en double.

    Si le SPN est dupliqué pour le compte de service AD FS, supprimez le SPN du compte en double en utilisant la commande [SETSPN -d service/NomHôte]

    Si le SPN n’est pas défini, utilisez [SETSPN -s {SPN-souhaité} {nom_domaine}{compte_service}] pour définir le SPN souhaité pour le compte de service de fédération.
    Le certificat principal de déchiffrement de jetons AD FS arrive à expiration Le certificat principal AD FS de déchiffrement de jetons est sur le point d’expirer dans moins de 90 jours. AD FS ne peut pas déchiffrer les jetons provenant de fournisseurs de revendications approuvés. AD FS ne peut pas déchiffrer les cookies SSO chiffrés. Les utilisateurs finaux ne pourront pas s’authentifier pour accéder aux ressources. Lorsque le renouvellement de certificat automatique est activé, AD FS gère le certificat de déchiffrement de jetons.

    Si vous gérez votre certificat manuellement, suivez les instructions ci-dessous. Bénéficiez d’un nouveau certificat de déchiffrement de jetons.

    1. Assurez-vous que l’utilisation améliorée de la clé inclut le « Chiffrement de la clé »
    2. Objet ou Autre nom de l’objet (SAN) ne présente aucune restriction.
    3. N’oubliez pas que vos serveurs de fédération et partenaires fournisseurs de demandes doivent être en mesure de s’associer à une autorité de certification racine approuvée lors de la validation de votre certificat de déchiffrement de jetons.
    Décidez de quelle manière vos partenaires fournisseurs de demandes approuveront le certificat de déchiffrement de jetons
    1. Demandez aux partenaires d’extraire les métadonnées de fédération après la mise à jour du certificat.
    2. Partagez la clé publique du nouveau certificat (fichier .cer) avec les partenaires. Sur le serveur AD FS du partenaire fournisseur de demandes, lancez Gestion AD FS à partir du menu Outils d’administration. Sous Relations d’approbation/Approbations de la partie de confiance, sélectionnez l’approbation créée pour vous. Sous Propriétés/Chiffrement, cliquez sur « Parcourir » pour sélectionner le nouveau certificat de déchiffrement de jetons et cliquez sur OK.
    Installez le certificat dans le magasin de certificats, sur chacun de vos serveurs de fédération.
    • Assurez-vous que le fichier d’installation du certificat dispose de la clé privée du certificat sur chaque serveur.
    Vérifiez que le compte de service FS (Federation Service) a accès à la clé privée du nouveau certificat. Ajoutez le nouveau certificat à AD FS.
    1. Lancez Gestion AD FS à partir du menu Outils d’administration
    2. Ouvrez Service et sélectionnez Certificats
    3. Dans le volet Actions, cliquez sur Ajouter un certificat de déchiffrement de jetons
    4. Vous verrez apparaître une liste de certificats valides pour le déchiffrement de jetons. Si votre nouveau certificat n’apparaît pas dans la liste, vous devez revenir en arrière et vérifier que le certificat se trouve bien dans le magasin personnel de l’ordinateur local, avec une clé privée qui lui est associée, et que le chiffrement de la clé du certificat est défini avec l’attribut Utilisation améliorée de la clé.
    5. Sélectionnez votre nouveau certificat de déchiffrement de jetons et cliquez sur OK.
    Configurez le certificat de déchiffrement de jetons en tant que certificat principal.
    1. Avec le nœud de certificats sélectionnés dans Gestion AD FS, vous devriez maintenant voir apparaître deux certificats énumérés sous Chiffrement de la clé : le certificat existant et le nouveau.
    2. Sélectionnez votre nouveau certificat de déchiffrement de jetons, cliquez avec le bouton droit et sélectionnez Définir comme principal.
    3. Conservez l’ancien certificat en tant que certificat secondaire, à des fins de renouvellement. Pensez à supprimer l’ancien certificat une fois qu’il n’est plus nécessaire pour le renouvellement, ou lorsque le certificat est arrivé à expiration.
    Le certificat principal de signature de jetons AD FS arrive à expiration. Le certificat de signature de jetons AD FS expirera dans 90 jours. AD FS ne peut pas émettre de jetons signés lorsque ce certificat n’est pas valide. Bénéficiez d’un nouveau certificat de signature de jetons.
    1. Assurez-vous que l’utilisation améliorée de la clé (EKU) inclut « Signature numérique »
    2. Objet ou Autre nom de l’objet (SAN) ne présente aucune restriction.
    3. N’oubliez pas que vos serveurs de fédération, vos serveurs de fédération de partenaires de ressources et serveurs d’applications de parties de confiance doivent être en mesure de s’attacher à une autorité de certification racine approuvée lors de la validation de votre certificat de signature de jetons.
    Installez le certificat dans le magasin de certificats local, sur chaque serveur de fédération.
    • Assurez-vous que le fichier d’installation du certificat dispose de la clé privée du certificat sur chaque serveur.
    Vérifiez que le compte de service FS (Federation Service) a accès à la clé privée du nouveau certificat. Ajoutez le nouveau certificat à AD FS.
    1. Lancez Gestion AD FS à partir du menu Outils d’administration.
    2. Ouvrez Service et sélectionnez Certificats
    3. Dans le volet Actions, cliquez sur Ajouter un certificat de signature de jetons...
    4. Vous verrez apparaître une liste de certificats valides pour la signature de jetons. Si votre nouveau certificat n’apparaît pas dans cette liste, vous devez revenir en arrière et vérifier que le certificat se trouve bien dans le magasin personnel de l’ordinateur local, avec une clé privée qui lui est associée, et que le certificat dispose d’une signature numérique.
    5. Sélectionnez votre nouveau certificat de signature de jetons et cliquez sur OK
    Informez toutes les parties de confiance de la modification apportée dans le certificat de signature de jetons.
    1. Les parties de confiance, qui utilisent les métadonnées de fédération AD FS, doivent extraire les métadonnées de fédération pour commencer à utiliser le nouveau certificat.
    2. Les parties de confiance qui N’UTILISENT PAS de métadonnées de fédération AD FS doivent mettre à jour manuellement la clé publique du nouveau certificat de signature de jetons. Partagez le fichier .cer avec les parties de confiance.
      3. Configurez le certificat de signature de jetons en tant que certificat principal.
      1. Avec le nœud de certificats sélectionnés dans Gestion AD FS, vous devriez maintenant voir apparaître deux certificats énumérés sous Signature de jetons : le certificat existant et le nouveau.
      2. Sélectionnez votre nouveau certificat de signature de jetons, cliquez avec le bouton droit et sélectionnez Définir comme principal
      3. Conservez l’ancien certificat en tant que certificat secondaire, à des fins de renouvellement. Pensez à supprimer l’ancien certificat une fois qu’il n’est plus nécessaire pour le renouvellement, ou lorsque le certificat est arrivé à expiration. N’oubliez pas que les sessions d’utilisateurs SSO actuelles sont signées. Les relations d’approbation actuelles du proxy AD FS utilisent des jetons qui sont signés et chiffrés via l’ancien certificat.
    Le certificat SSL AD FS est introuvable dans le magasin de certificats local Le certificat, associé à l’empreinte, qui est configuré comme certificat TLS/SSL dans la base de données AD FS est introuvable dans le magasin de certificats local. De ce fait, toutes les demandes d’authentification effectuées via le protocole TLS échouent, par exemple, l’authentification du client de messagerie pour Microsoft 365. Installez le certificat associé à l’empreinte configurée dans le magasin de certificats local.
    Le certificat SSL est arrivé à expiration Le certificat TLS/SSL du service AD FS est arrivé à expiration. De ce fait, toutes les demandes d’authentification qui nécessitent une connexion TLS valide échoueront. Par exemple : l’authentification du client de messagerie ne pourra pas s’authentifier pour Microsoft 365. Mettez à jour le certificat TLS/SSL sur chaque serveur AD FS.
    1. Bénéficiez du certificat TLS/SSL répondant aux exigences suivantes.
    2. L’utilisation améliorée de la clé constitue au moins une authentification du serveur.
    3. Objet du certificat ou Autre nom de l’objet (SAN) contient le nom DNS du service FS (Federation Service) ou le caractère générique approprié. Par exemple : sso.contoso.com ou *. contoso.com.
    4. Installez le nouveau certificat TLS/SSL sur chaque serveur, dans le magasin de certificats de l’ordinateur local.
    5. Vérifiez que le compte de service AD FS bénéficie d’un accès en lecture à la clé privée du certificat.

    Pour AD FS 2.0 dans Windows Server 2008 R2 :

    • Liez le nouveau certificat TLS/SSL au site Web IIS qui héberge le service FS. Veuillez noter que vous devez effectuer cette étape sur chaque serveur de fédération et serveur proxy de fédération.

    Pour AD FS dans Windows Server 2012 R2 ou versions ultérieures : Consultez : Gestion des certificats SSL dans AD FS et WAP

    Les points de terminaison requis pour Microsoft Entra ID (pour Microsoft 365) ne sont pas activés L’ensemble suivant des points de terminaison requis par les services Exchange Online, Microsoft Entra ID et Microsoft 365, ne sont pas activés pour le service de fédération :
  • /adfs/services/trust/2005/usernamemixed
  • /adfs/ls/
    		•  Activez les points de terminaison requis pour les services de cloud computing de Microsoft sur votre service FS (Federation Service).
    Pour AD FS dans Windows Server 2012R2 ou versions ultérieures
  • Consultez : Gestion des certificats SSL dans AD FS et WAP

    • Le serveur de fédération n’est pas parvenu à se connecter à la base de données de configuration AD FS. Le compte de service AD FS rencontre quelques problèmes lorsqu’il se connecte à la base de données de configuration AD FS. Il se peut donc que le service AD FS présent sur cet ordinateur ne fonctionne pas comme prévu.
  • Veillez à ce que le compte de service AD FS ait accès à la base de données de configuration.
  • Assurez-vous que le service de base de données de configuration AD FS est disponible et accessible.
    • Les liaisons SSL requises sont manquantes ou n’ont pas été configurées correctement Les liaisons TLS requises pour permettre à ce serveur de fédération de réaliser avec succès l’authentification n’ont pas été configurées correctement. De ce fait, AD FS ne peut traiter aucune demande entrante. Pour Windows Server 2012 R2
    Ouvrez une invite de commandes d’administration élevée et exécutez les commandes suivantes :
    1. Pour afficher la liaison TLS actuelle : Get-AdfsSslCertificate
    2. Pour ajouter de nouvelles liaisons : netsh http add sslcert hostnameport=<federation service name>:443 certhash=AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00 appid={00001111-aaaa-2222-bbbb-3333cccc4444} certstorename=MY
    Le certificat principal de signature de jetons AD FS est arrivé à expiration Le certificat de signature de jetons AD FS est arrivé à expiration. AD FS ne peut pas émettre de jetons signés lorsque ce certificat n’est pas valide. Si le renouvellement de certificats automatique est activé, AD FS se chargera de mettre à jour le certificat de signature de jetons.

    Si vous gérez votre certificat manuellement, suivez les instructions ci-dessous.

    1. Bénéficiez d’un nouveau certificat de signature de jetons.
      1. Assurez-vous que l’utilisation améliorée de la clé (EKU) inclut « Signature numérique »
      2. Objet ou Autre nom de l’objet (SAN) ne présente aucune restriction.
      3. N’oubliez pas que vos serveurs de fédération, vos serveurs de fédération de partenaires de ressources et serveurs d’application de parties de confiance doivent être en mesure de s’attacher à une autorité de certification racine approuvée lors de la validation de votre certificat de signature de jetons.
    2. Installez le certificat dans le magasin de certificats local, sur chaque serveur de fédération.
      • Assurez-vous que le fichier d’installation du certificat dispose de la clé privée du certificat sur chaque serveur.
    3. Vérifiez que le compte de service FS (Federation Service) a accès à la clé privée du nouveau certificat.
    4. Ajoutez le nouveau certificat à AD FS.
      1. Lancez Gestion AD FS à partir du menu Outils d’administration.
      2. Ouvrez Service et sélectionnez Certificats
      3. Dans le volet Actions, cliquez sur Ajouter un certificat de signature de jetons...
      4. Vous verrez apparaître une liste de certificats valides pour la signature de jetons. Si votre nouveau certificat n’apparaît pas dans cette liste, vous devez revenir en arrière et vérifier que le certificat se trouve bien dans le magasin personnel de l’ordinateur local, avec une clé privée qui lui est associée, et que le certificat dispose d’une signature numérique.
      5. Sélectionnez votre nouveau certificat de signature de jetons et cliquez sur OK
    5. Informez toutes les parties de confiance de la modification apportée dans le certificat de signature de jetons.
      1. Les parties de confiance, qui utilisent les métadonnées de fédération AD FS, doivent extraire les métadonnées de fédération pour commencer à utiliser le nouveau certificat.
      2. Les parties de confiance qui N’UTILISENT PAS de métadonnées de fédération AD FS doivent mettre à jour manuellement la clé publique du nouveau certificat de signature de jetons. Partagez le fichier .cer avec les parties de confiance.
    6. Configurez le certificat de signature de jetons en tant que certificat principal.
      1. Avec le nœud de certificats sélectionnés dans Gestion AD FS, vous devriez maintenant voir apparaître deux certificats énumérés sous Signature de jetons : le certificat existant et le nouveau.
      2. Sélectionnez votre nouveau certificat de signature de jetons, cliquez avec le bouton droit et sélectionnez Définir comme principal
      3. Conservez l’ancien certificat en tant que certificat secondaire, à des fins de renouvellement. Pensez à supprimer l’ancien certificat une fois qu’il n’est plus nécessaire pour le renouvellement, ou lorsque le certificat est arrivé à expiration. N’oubliez pas que les sessions d’utilisateurs SSO actuelles sont signées. Les relations d’approbation actuelles du proxy AD FS utilisent des jetons qui sont signés et chiffrés via l’ancien certificat.
    Le serveur proxy annule des demandes de contrôle de surcharge. Ce serveur proxy annule actuellement des demandes provenant de l’extranet en raison d’une latence plus élevée que la normale entre ce serveur proxy et le serveur de fédération. Il se peut donc que certaines parties des demandes d’authentification traitées par le serveur proxy AD FS échouent.
  • Vérifiez si la latence du réseau entre le serveur proxy de fédération et les serveurs de fédération se situe dans une plage acceptable. Reportez-vous à la section Surveillance pour découvrir les valeurs tendance de la « Latence de demande de jetons » Une latence supérieure à [1500 ms] doit être considérée comme une latence élevée. Si vous constatez une latence élevée, assurez-vous que le réseau entre les serveurs proxy AD FS et AD FS ne rencontre aucun problème de connectivité.
  • Assurez-vous que les serveurs de fédération ne sont pas surchargés de demandes d’authentification. La section Surveillance fournit des affichages des tendances pour les demandes de jetons par seconde, l’utilisation du processeur et la consommation de mémoire.
  • Si les éléments mentionnés ci-dessus ont été vérifiés et que ce problème s’affiche toujours, ajustez le paramètre d’évitement de surcharge sur chaque serveur proxy de fédération en suivant les conseils fournis dans les liens connexes.
    		•
    Le compte de service AD FS s’est vu refuser l’accès à la clé privée de l’un des certificats. Le compte de service AD FS n’a pas accès à la clé privée d’un des certificats AD FS sur cet ordinateur. Veillez à ce que le compte de service AD FS ait accès à des certificats TLS, de signature de jetons et de certificats de déchiffrement dans le magasin de certificats de l’ordinateur local.
    1. Depuis la ligne de commande, tapez MMC.
    2. Accédez à Fichier-> Ajouter/Supprimer un composant logiciel enfichable.
    3. Sélectionnez Certificats et cliquez sur Ajouter. -> Sélectionnez Compte d’ordinateur et cliquez sur Suivant. -> Sélectionnez Ordinateur local et cliquez sur Terminer. Cliquez sur OK.

    Ouvrez Certificates(Local Computer)/Personal/Certificates. Pour tous les certificats qui sont utilisés par AD FS :
    1. Cliquez avec le bouton droit sur le certificat.
    2. Sélectionnez Toutes les tâches -> Gérer les clés privées.
    3. Dans l’onglet Sécurité sous Noms de groupes et d’utilisateurs, assurez-vous que le compte de service AD FS s’y trouve. S’il ne s’y trouve pas, sélectionnez Ajouter et ajoutez le compte de service AD FS.
    4. Sélectionnez le compte de service AD FS puis, sous « Autorisations pour <Nom du compte de service AD FS> », assurez-vous que Lecture est autorisée (case cochée).
    Le certificat SSL AD FS ne dispose d’aucune clé privée Le certificat TLS/SSL AD FS a été installé sans clé privée. De ce fait, toutes les demandes d’authentification effectuées via le protocole SSL échouent, par exemple, l’authentification du client de messagerie pour Microsoft 365. Mettez à jour le certificat TLS/SSL sur chaque serveur AD FS.
    1. Bénéficiez d’un certificat TLS/SSL publiquement approuvé répondant aux exigences suivantes.
      1. Le fichier d’installation du certificat dispose de sa propre clé privée.
      2. L’utilisation améliorée de la clé constitue au moins une authentification du serveur.
      3. Objet du certificat ou Autre nom de l’objet (SAN) contient le nom DNS du service FS (Federation Service) ou le caractère générique approprié. Par exemple : sso.contoso.com ou *. contoso.com.
    2. Installez le nouveau certificat TLS/SSL sur chaque serveur, dans le magasin de certificats de l’ordinateur local.
    3. Vérifiez que le compte de service AD FS bénéficie d’un accès en lecture à la clé privée du certificat.

    Pour AD FS 2.0 dans Windows Server 2008 R2 :

    • Liez le nouveau certificat TLS/SSL au site Web IIS qui héberge le service FS. Veuillez noter que vous devez effectuer cette étape sur chaque serveur de fédération et serveur proxy de fédération.

    Pour AD FS dans Windows Server 2012 R2 ou versions ultérieures :

  • Consultez : Gestion des certificats SSL dans AD FS et WAP
    • Le certificat de déchiffrement de jetons AD FS est arrivé à expiration Le certificat principal de déchiffrement de jetons AD FS est arrivé à expiration. AD FS ne peut pas déchiffrer les jetons provenant de fournisseurs de revendications approuvés. AD FS ne peut pas déchiffrer les cookies SSO chiffrés. Les utilisateurs finaux ne pourront pas s’authentifier pour accéder aux ressources.

    Lorsque le renouvellement de certificat automatique est activé, AD FS gère le certificat de déchiffrement de jetons.

    Si vous gérez votre certificat manuellement, suivez les instructions ci-dessous.

    1. Bénéficiez d’un nouveau certificat de déchiffrement de jetons.
      • Assurez-vous que l’utilisation améliorée de la clé inclut le « Chiffrement de la clé ».
      • Objet ou Autre nom de l’objet (SAN) ne présente aucune restriction.
      • N’oubliez pas que vos serveurs de fédération et partenaires fournisseurs de demandes doivent être en mesure de s’associer à une autorité de certification racine approuvée lors de la validation de votre certificat de déchiffrement de jetons.
    2. Décidez de quelle manière vos partenaires fournisseurs de demandes approuveront le certificat de déchiffrement de jetons
      • Demandez aux partenaires d’extraire les métadonnées de fédération après la mise à jour du certificat.
      • Partagez la clé publique du nouveau certificat (fichier .cer) avec les partenaires. Sur le serveur AD FS du partenaire fournisseur de demandes, lancez Gestion AD FS à partir du menu Outils d’administration. Sous Relations d’approbation/Approbations de la partie de confiance, sélectionnez l’approbation créée pour vous. Sous Propriétés/Chiffrement, cliquez sur « Parcourir » pour sélectionner le nouveau certificat de déchiffrement de jetons et cliquez sur OK.
    3. Installez le certificat dans le magasin de certificats, sur chacun de vos serveurs de fédération.
      • Assurez-vous que le fichier d’installation du certificat dispose de la clé privée du certificat sur chaque serveur.
    4. Vérifiez que le compte de service FS (Federation Service) a accès à la clé privée du nouveau certificat.
    5. Ajoutez le nouveau certificat à AD FS.
      • Lancez Gestion AD FS à partir du menu Outils d’administration
      • Ouvrez Service et sélectionnez Certificats
      • Dans le volet Actions, cliquez sur Ajouter un certificat de déchiffrement de jetons
      • Vous verrez apparaître une liste de certificats valides pour le déchiffrement de jetons. Si votre nouveau certificat n’apparaît pas dans la liste, vous devez revenir en arrière et vérifier que le certificat se trouve bien dans le magasin personnel de l’ordinateur local, avec une clé privée qui lui est associée, et que le chiffrement de la clé du certificat est défini avec l’attribut Utilisation améliorée de la clé.
      • Sélectionnez votre nouveau certificat de déchiffrement de jetons et cliquez sur OK.
    6. Configurez le certificat de déchiffrement de jetons en tant que certificat principal.
      • Avec le nœud de certificats sélectionnés dans Gestion AD FS, vous devriez maintenant voir apparaître deux certificats énumérés sous Chiffrement de la clé : le certificat existant et le nouveau.
      • Sélectionnez votre nouveau certificat de déchiffrement de jetons, cliquez avec le bouton droit et sélectionnez Définir comme principal.
      • Conservez l’ancien certificat en tant que certificat secondaire, à des fins de renouvellement. Pensez à supprimer l’ancien certificat une fois qu’il n’est plus nécessaire pour le renouvellement, ou lorsque le certificat est arrivé à expiration.

    Alertes pour Active Directory Domain Services

    Nom de l’alerte Description Correction
    Le contrôleur de domaine est inaccessible via le ping LDAP Le contrôleur de domaine n’est pas accessible via le ping LDAP. Cela peut être dû à des problèmes de réseau ou de machines. Par conséquent, les tests Ping LDAP échouent.
  • Examinez la liste des alertes à la recherche d’alertes connexes, telles que : Le contrôleur de domaine n’effectue pas de publications.
  • Vérifiez que le contrôleur de domaine affecté dispose d’un espace disque suffisant. Si l’espace est insuffisant, le contrôleur de domaine ne se publiera plus lui-même en tant que serveur LDAP.
  • Tentative de recherche du contrôleur de domaine principal : Exécutez
    requête netdom fsmo
    sur le contrôleur de domaine concerné.
  • Vérifiez que le réseau physique est configuré/connecté correctement.
    • Désolé... Active Directory a rencontré une erreur durant la réplication. Ce contrôleur de domaine rencontre des problèmes de réplication, que vous pouvez consulter en accédant au tableau de bord État de la réplication. Les erreurs de réplication peuvent découler d’une configuration incorrecte ou d’autres problèmes associés. Si vous ne résolvez pas ces erreurs de réplication, celles-ci risquent de nuire à la cohérence de vos données. Consultez les informations supplémentaires pour connaître les noms des contrôleurs de domaines sources et de destination affectés. Accédez au tableau de bord État de la réplication et recherchez les erreurs en cours sur les contrôleurs de domaines affectés. Cliquez sur l’erreur pour ouvrir un panneau présentant une méthode à suivre pour la résoudre.
    Le contrôleur de domaine ne parvient pas à détecter de contrôleur de domaine principal Un contrôleur de domaine principal n’est pas accessible via ce contrôleur de domaine. Des ouvertures de session utilisateur seront ainsi affectées, des changements de stratégie de groupe ne seront pas appliqués et la synchronisation horaire du système ne pourra pas avoir lieu.
  • Examinez la liste des alertes à la recherche d’alertes connexes qui pourraient avoir un impact sur votre contrôleur de domaine principal, telles que : Le contrôle de domaine n’effectue pas de publications.
  • Tentative de recherche du contrôleur de domaine principal : Exécutez
    requête netdom fsmo
    sur le contrôleur de domaine concerné.
  • Vérifiez que le réseau fonctionne correctement.
    • Le contrôleur de domaine ne parvient pas à détecter de serveur de catalogue global Un serveur de catalogue global n’est pas accessible à partir de ce contrôleur de domaine. Ceci entraînera donc des tentatives d’authentification infructueuses via ce contrôleur de domaine. Examinez la liste des alertes en recherchant des alertes de type Le contrôle de domaine n’effectue pas de publications où le serveur concerné peut être un catalogue global. S’il n’y a aucune alerte de publication, veuillez vérifier la présence de catalogues globaux dans les enregistrements SRV. Pour cela, il vous suffit d’exécuter la commande :
    nltest /dnsgetdc: [ForestName] /gc
    Elle doit répertorier les contrôleurs de domaine en tant que catalogues globaux. Si cette liste est vide, Vérifiez la configuration DNS pour vous assurer que le catalogue global contient bien les enregistrements SRV. Le contrôleur de domaine recherche ces derniers dans le DNS.
    Pour résoudre les problèmes des catalogues globaux, veuillez consulter Publication en tant que serveur de catalogue global.
    Le contrôleur de domaine ne parvient pas à accéder au partage sysvol local Sysvol contient des éléments importants provenant d’objets de stratégie de groupe et des scripts qui seront distribués dans les contrôleurs de domaine d’un domaine. Le contrôleur de domaine ne se publiera pas lui-même en tant que contrôleur de domaine et les stratégies de groupe ne seront pas appliquées. Voir comment résoudre les problèmes de partages sysvol et Netlogon manquants
    L’heure du contrôleur de domaine a été désynchronisée. La période définie pour ce contrôleur de domaine est en dehors de la période autorisée. Les authentifications Kerberos ne pourront donc pas avoir lieu.
  • Redémarrez le service de temps Windows : exécutez
    net stop w32time
    puis
    net start w32time
    sur le contrôleur de domaine concerné.
  • Resynchronisez le temps : exécutez
    w32tm /resync
    sur le contrôleur de domaine concerné.
    		•
    Le contrôleur de domaine n’effectue pas de publications Ce contrôleur de domaine ne publie pas correctement les rôles qu’il est capable d’exécuter. Ceci peut être dû à des problèmes de réplication, à une mauvaise configuration de DNS, à des services essentiels qui ne s’exécutent pas, ou à une initialisation incomplète du serveur. De ce fait, les contrôleurs de domaine, les membres de domaine et autres dispositifs ne pourront pas localiser ce contrôleur de domaine. De plus, d’autres contrôleurs de domaine ne pourront peut-être pas effectuer de réplications à partir de ce contrôleur de domaine. Examinez les liste des alertes pour les autres alertes associées, telles que : La réplication est interrompue. L’heure du contrôleur de domaine a été désynchronisée. Le service Netlogon ne s’exécute pas. Les services DFSR et/ou NTFRS ne sont pas en cours d’exécution. Identifier et résoudre les problèmes de DNS associés : Connexion au contrôleur de domaine affecté. Ouvrez le journal des événements système. Si les événements 5774, 5775 ou 5781 sont répertoriés, consultez la page Résolution des problèmes d’inscription des enregistrements DNS du localisateur de contrôleurs de domaine Identifier et résoudre les problèmes liés au service de temps Windows : Vérifiez que le service de temps Windows est en cours d’exécution : Exécutez « net start w32time » sur le contrôleur de domaine affecté. Redémarrez le service de temps Windows : Exécutez « net stop w32time », puis « net start w32time» sur le contrôleur de domaine affecté.
    Le service GPSVC n’est pas en cours d’exécution Si le service est arrêté ou désactivé, les paramètres configurés par l’administrateur ne seront pas appliqués et les applications ou composants ne pourront pas être gérés par le biais d’une stratégie de groupe. Il se peut qu’un composant ou une application dépendant de la stratégie de groupe ne fonctionnent pas si le service est désactivé. Exécutez
    net start gpsvc
    sur le contrôleur de domaine concerné.
    Les services DFSR et/ou NTFRS ne sont pas en cours d’exécution Si les services DFSR et NTFRS sont arrêtés tous les deux, les contrôleurs de domaine ne pourront pas répliquer les données sysvol. Les données sysvol ne seront pas cohérentes.
  • Si vous utilisez DFSR :
      Exécutez « net start dfsr » sur le contrôleur de domaine affecté.
    1. Si vous utilisez NTFRS :
        Exécutez « net start ntfrs » sur le contrôleur de domaine affecté.
    • Le service Netlogon n’est pas en cours d’exécution Les demandes de connexion, l’inscription, l’authentification et la localisation des contrôleurs de domaine seront indisponibles sur ce contrôleur de domaine. Exécutez « net start netlogon » sur le contrôleur de domaine affecté.
    Le service W32Time n’est pas en cours d’exécution Si le Service de temps Windows est arrêté, la synchronisation de la date et de l’heure ne sera pas disponible. Si le service est désactivé, le démarrage de tout service qui en dépend explicitement échouera. Exécutez « net start win32Time » sur le contrôleur de domaine affecté.
    Le service ADWS n’est pas en cours d’exécution Si le service Active Directory Web Services est arrêté ou désactivé, les applications clientes telles qu’Azure Directory PowerShell ne peuvent pas accéder aux instances de service d’annuaire exécutées en local sur ce serveur, ni les gérer. Exécutez « net start adws » sur le contrôleur de domaine affecté.
    Le contrôleur de domaine principal racine ne se synchronise pas depuis le serveur NTP Si vous ne configurez pas le contrôleur de domaine principal pour synchroniser le temps à partir d’une source de temps externe ou interne, l’émulateur du contrôleur de domaine principal utilise son horloge interne et lui-même comme source de temps fiable pour la forêt. Si l’heure n’est pas exacte sur le contrôleur de domaine principal lui-même, les paramètres de temps de tous les ordinateurs sont incorrects. Ouvrez une invite de commande sur le contrôleur de domaine affecté. Arrêtez le service de temps : net stop w32time
  • Configurez la source de temps externe :
    w32tm /config /manualpeerlist: time.windows.com /syncfromflags:manual /reliable:yes

    Remarque : Remplacez time.windows.com par l’adresse de la source de temps externe de votre choix. Démarrez le service de temps :
    net start w32time
    • Le contrôleur de domaine est mis en quarantaine Ce contrôleur de domaine n’est connecté à aucun contrôleur de domaine en cours d’exécution. Ceci peut être dû à une mauvaise configuration. De ce fait, ce contrôleur n’est pas utilisé et n’effectue aucune réplication sur ou depuis l’un d’entre eux. Activez les réplications entrante et sortante : Exécutez « repadmin /options ServerName -DISABLE_INBOUND_REPL » sur le contrôleur de domaine affecté. Exécutez « repadmin /options ServerName -DISABLE_OUTBOUND_REPL » sur le contrôleur de domaine affecté. Créez une connexion de réplication vers un autre contrôleur de domaine :
    1. Ouvrez Sites et services Active Directory : Menu Démarrer, pointez sur Outils d’administration, puis cliquez sur Sites et services Active Directory.
    2. Dans l’arborescence de la console, développez Sites, puis développez le site auquel appartient ce contrôleur de domaine.
    3. Développez le conteneur Serveurs pour afficher la liste des serveurs.
    4. Développez l’objet serveur pour ce contrôleur de domaine.
    5. Clic droit sur l’objet Paramètres NTDS, puis cliquez sur Nouvelle connexion aux Active Directory Domain Services...
    6. Sélectionnez un serveur dans la liste, puis cliquez sur OK.
    Suppression de domaines orphelins d’Active Directory.
    La réplication sortante est désactivée Les contrôleurs de domaine avec une réplication entrante désactivée ne pourront pas distribuer de modifications qui viennent d’eux. Pour activer la réplication sortante du contrôleur de domaine affecté, procédez comme suit : Cliquez sur Démarrer, puis sur Exécuter, entrez cmd, puis cliquez sur OK. Entrez le texte suivant, puis appuyez sur ENTRÉE :
    repadmin /options -DISABLE_OUTBOUND_REPL
    La réplication entrante est désactivée Les contrôleurs de domaine avec une réplication entrante désactivée ne disposeront pas d’informations les plus récentes. Cette situation peut entraîner des échecs de connexion. Pour activer la réplication entrante du contrôleur de domaine affecté, procédez comme suit : Cliquez sur Démarrer, puis sur Exécuter, entrez cmd, puis cliquez sur OK. Entrez le texte suivant, puis appuyez sur ENTRÉE :
    repadmin /options -DISABLE_INBOUND_REPL
    Le service LanmanServer n’est pas en cours d’exécution Si le service est désactivé, le démarrage de tout service qui en dépend explicitement échouera. Exécutez « net start LanManServer » sur le contrôleur de domaine affecté.
    Le service Centre de distribution de clés Kerberos n’est pas en cours d’exécution Si le service KDC est arrêté, les utilisateurs ne peuvent pas réaliser d’authentification via ce contrôleur de domaine à l’aide du protocole d’authentification Kerberos v5. Exécutez « net start kdc » sur le contrôleur de domaine affecté.
    Le service DNS n’est pas en cours d’exécution Si le service DNS est arrêté, les ordinateurs et les utilisateurs exploitant ce serveur à des fins de DNS ne parviendront pas à retrouver les ressources. Exécutez « net start dns » sur le contrôleur de domaine affecté.
    Une restauration de l’USN a été effectuée pour le contrôleur de domaine Quand une restauration d’USN se produit, les modifications apportées aux objets et attributs ne sont pas répliquées en entrée par les contrôleurs de domaine de destination qui ont déjà vu l’USN. Dans la mesure où ces contrôleurs de domaine de destination pensent qu’ils sont à jour, aucune erreur de réplication n’est signalée dans les journaux des événements du service d’annuaire ou via les outils de supervision et de diagnostics. La restauration du nombre de séquences de mise à jour (USN) peut affecter la réplication d’un objet ou d’un attribut dans n’importe quelle partition. L’effet secondaire le plus fréquemment observé est l’absence, sur un ou plusieurs partenaires de réplication, des comptes d’utilisateurs et d’ordinateurs créés sur le contrôleur de domaine de restauration ; Dans certains cas, les mises à jour de mot de passe provenant du contrôleur de domaine de restauration n’existent pas sur les partenaires de réplication. Il existe deux approches pour effectuer une récupération suite à une restauration d’USN :

    Supprimez le contrôleur de domaine du domaine, en procédant comme suit :

    1. Supprimez Active Directory du contrôleur de domaine pour le forcer à être un serveur autonome. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher dans la Base de connaissances Microsoft :
      332199 Les contrôleurs de domaine ne se rétrogradent pas aisément lorsque vous utilisez l’Assistant Installation d’Active Directory pour forcer la rétrogradation dans Windows Server 2003 et Windows 2000 Server.
    2. Arrêtez le serveur rétrogradé.
    3. Sur un contrôleur de domaine sain, nettoyez les métadonnées du contrôleur de domaine rétrogradé. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher dans la Base de connaissances Microsoft :
      216498 Comment supprimer des données dans Active Directory après un échec de dégradation de contrôleur de domaine
    4. Si le contrôleur de domaine incorrectement restauré héberge les rôles de maîtres d’opérations, transférez ces rôles vers un contrôleur de domaine intègre. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher dans la Base de connaissances Microsoft :
      255504 Utilisation de Ntdsutil.exe pour prendre ou transférer des rôles FSMO vers un contrôleur de domaine
    5. Redémarrez le serveur rétrogradé.
    6. Le cas échéant, réinstallez Active Directory sur le serveur autonome.
    7. Si le contrôleur de domaine était auparavant un catalogue global, configurez-le de la même manière. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher dans la Base de connaissances Microsoft :
      313994 Comment créer ou déplacer un catalogue global dans Windows 2000
    8. Si le contrôleur de domaine hébergeait des rôles de maîtres d’opérations, retransférez ces derniers sur le contrôleur de domaine. Pour plus d’informations à ce sujet, cliquez sur le numéro de l’article suivant pour l’afficher dans la Base de connaissances Microsoft :
      255504 Utilisation de Ntdsutil.exe pour prendre ou transférer des rôles FSMO vers un contrôleur de domaine. Restaurez l’état du système d’une sauvegarde correcte.

    Déterminez si vous disposez de sauvegardes d’état de votre système correctes pour ce contrôleur de domaine. Si vous aviez effectué une sauvegarde d’état du système correcte avant l’échec de restauration du contrôleur de domaine, et que cette sauvegarde contient les modifications récentes appliquées au contrôleur de domaine, restaurez l’état du système à partir de la sauvegarde la plus récente.

    Vous pouvez également utiliser la capture instantanée en tant que source de sauvegarde. Ou vous pouvez définir la base de données pour qu’elle s’attribue un nouvel ID d’appel. Pour cela, suivez la procédure décrite dans la section « Pour restaurer la version antérieure d’un VHD de contrôleur de domaine virtuel en l’absence de sauvegarde des données sur l’état du système » de cet article

    Étapes suivantes