Windows Server : Identifier et réparer un canal sécurisé défaillant sur un contrôleur de domaine Active Directory

• La réplication échoue entre un contrôleur de domaine concerné et d’autres dans le domaine. La raison de l’échec peut varier, mais « Le nom principal de la cible est incorrect » est un indicateur fort d’un canal sécurisé rompu.
  • Les codes de résultat associés à cette erreur incluent -2146893022 et 0x80090322. Ces codes peuvent apparaître dans repadmin sortie ou événements dans le journal des événements du service d’annuaire.
• « La relation d’approbation entre cette station de travail et le domaine principal a échoué » est une autre erreur associée à un canal sécurisé rompu.
• Si le contrôleur de domaine concerné est un serveur DNS, la console du gestionnaire DNS peut générer une erreur « Accès refusé » lors de la connexion à ce contrôleur de domaine.

La copie du mot de passe du compte d’ordinateur du contrôleur de domaine ne correspond pas au mot de passe correspondant stocké dans la base de données Active Directory (AD). Lorsque ces mots de passe diffèrent, un canal sécurisé ne peut pas être établi. Vous trouverez plus d’informations sur les mots de passe de compte d’ordinateur dans AD dans la section Informations supplémentaires ci-dessous.

Le Test-ComputerSecureChannel Commande PowerShell avec l’attribut -Repair peut réparer un canal sécurisé cassé sur un contrôleur de domaine. (Il existe d’autres méthodes, mais cette commande est simple et directe.) Procédez comme suit sur le contrôleur de domaine concerné pour réparer son canal sécurisé :

1. Ignorez cette étape s’il n’y a qu’un seul contrôleur de domaine dans le domaine. Arrêtez le service Centre de distribution de clés (KDC) Kerberos et définissez son type de démarrage sur Désactivé.
   Il peut également être nécessaire de le faire sur d’autres contrôleurs de domaine du domaine, mais le service doit être laissé en cours d’exécution sur au moins un contrôleur de domaine. Voir les informations supplémentaires ci-dessous.
2. Lancez une invite PowerShell avec élévation de privilèges.
3. Exécutez klist purge pour supprimer des tickets Kerberos existants.
4. Exécutez Test-ComputerSecureChannel -server <good_dc> -repair -verbose.
   Remplacez <good_dc> par le nom ou l’adresse IP d’un contrôleur de domaine sur lequel le service KDC est en cours d’exécution.
5. Le résultat de la commande doit indiquer que le canal sécurisé a été réparé avec succès :
   Figure 1 : Le canal sécurisé a été réparé avec succès.
6. Forcez la réplication AD vers et depuis le contrôleur de domaine concerné et confirmez qu’elle a réussi.
7. Réinitialisez le type de démarrage du service KDC sur Automatique sur tous les contrôleurs de domaine et démarrez le service. (En d’autres termes, annulez ce qui a été fait à l’étape 1.)

Mots de passe de compte d’ordinateur dans Active Directory

Chaque machine jointe à un domaine dispose d’un compte d’ordinateur dans la base de données AD. À l’instar des comptes d’utilisateur, ces comptes d’ordinateur sont associés à des mots de passe. Ces mots de passe sont utilisés pour établir un chemin de communication sécurisé (canal sécurisé) entre les appareils du domaine. Chaque machine stocke une copie de son mot de passe localement, et une autre copie est stockée dans la base de données AD. Les mots de passe des comptes d’ordinateur n’expirent pas et ne nécessitent pas de maintenance manuelle de la part des utilisateurs. Ils sont exemptés des stratégies de mots de passe établies pour les mots de passe des comptes d’utilisateur.

Par défaut, une machine jointe à un domaine tente de modifier son mot de passe tous les 30 jours, bien que cet intervalle puisse être modifié. La modification du mot de passe est initiée par la machine jointe au domaine, et non par un mécanisme au sein d’AD. Si un contrôleur de domaine peut être contacté, la copie locale du mot de passe de la machine et la copie stockée dans AD sont toutes deux modifiées. Si la machine ne peut pas contacter un contrôleur de domaine, elle ne modifie pas la copie locale de son mot de passe.

Ces principes s’appliquent aux contrôleurs de domaine tout comme ils s’appliquent aux autres machines jointes à un domaine. Il est possible que la copie locale d’un contrôleur de domaine du mot de passe de son compte d’ordinateur ne soit pas synchronisée avec la copie stockée dans AD. C’est même possible, bien que rare, dans un domaine à un seul contrôleur de domaine.

Arrêt du service Centre de distribution de clés (KDC) Kerberos

S’il existe plusieurs contrôleurs de domaine dans le domaine, le service KDC doit être arrêté sur le contrôleur de domaine concerné. Il est également recommandé de définir le type de démarrage du service sur Désactivé pour empêcher le service de démarrer. En fonction de l’étendue du problème et du nombre de contrôleurs de domaine dans le domaine, il peut être nécessaire d’arrêter le service sur d’autres contrôleurs de domaine également. Si tous les autres contrôleurs de domaine du domaine sont synchronisés les uns avec les autres (réplication sans erreurs), arrêtez et désactivez le service sur le contrôleur de domaine concerné uniquement. Sinon, arrêtez-le et désactivez-le sur tous les contrôleurs de domaine qui ne peuvent pas être répliqués. Il doit être laissé en cours d’exécution sur au moins un contrôleur de domaine. Si possible, arrêtez le service sur tous les contrôleurs de domaine sauf un et spécifiez ce contrôleur de domaine comme cible du -server Le changement à l’étape 4 devrait donner de bons résultats.