Comment résoudre les problèmes d’erreur de réplication Active Directory 5 dans Windows Server : l’accès est refusé

Cet article décrit les symptômes, la cause et la résolution des situations dans lesquelles la réplication Active Directory échoue avec l’erreur 5 : Accès refusé.

Numéro de base de connaissances d’origine : 3073945

Symptômes

Vous pouvez rencontrer un ou plusieurs des symptômes suivants lorsque les réplications Active Directory échouent avec l’erreur 5.

Symptôme 1

L’outil en ligne de commande Dcdiag.exe signale que le test de réplication Active Directory échoue avec le code d’état d’erreur (5). Le rapport ressemble à l’exemple suivant :

Testing server: <Site_Name>\<Destination_DC_Name>  
Starting test: Replications  
Replications Check  
[Replications Check,<Destination_DC_Name>] A recent replication attempt failed:  
From <Source_DC> to <Destination_DC>  
Naming Context: <Directory_Partition_DN_Path>  
The replication generated an error (5):  
Access is denied.  
The failure occurred at <Date> <Time>.  
The last success occurred at <Date> <Time>.  
<Number> failures have occurred since the last success.

Symptôme 2

L’outil en ligne de commande Dcdiag.exe signale que la fonction échoue avec l’erreur DsBindWithSpnEx 5 en exécutant la DCDIAG /test:CHECKSECURITYERROR commande.

Symptôme 3

L’outil en ligne de commande REPADMIN.exe signale que la dernière tentative de réplication a échoué avec l’état 5.

Les REPADMIN commandes qui fréquemment citent l’état 5 incluent, mais ne sont pas limitées aux commandes suivantes :

• REPADMIN /KCC
• REPADMIN /REPLICATE
• REPADMIN /REPLSUM
• REPADMIN /SHOWREPL
• REPADMIN /SHOWREPS
• REPADMIN /SYNCALL

L’exemple de sortie de la REPADMIN /SHOWREPL commande est le suivant. Cette sortie indique que la réplication entrante échoue DC_2_Name DC_1_Name avec l’erreur « Accès refusé ».

<Site_Name>\<DC_1_Name>  
DSA Options: IS_GC  
Site Options: (none)  
DSA object GUID: <GUID>  
DSA invocationID: <invocationID>

==== INBOUND NEIGHBORS======================================  
DC= <DomainName>,DC=com  
<Site_Name>\<DC_2_Name> via RPC  
DSA object GUID: <GUID> 
Last attempt @ <Date> <Time> failed, result 5(0x5):  
Access is denied.  
<#> consecutive failure(s).  
Last success @ <Date> <Time>.

Symptôme 4

Les événements NTDS KCC, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService avec l’état 5 sont consignés dans le journal Services d’annuaire dans l’Observateur d’événements.

Le tableau suivant récapitule les événements Active Directory qui fréquemment citent l’état 8524, y compris, mais pas limité à :

ID d'événement	Source	Chaîne d’événement
1655	NTDS General	Active Directory a essayé de communiquer avec le catalogue global suivant et les tentatives ont échoué.
1925	NTDS KCC	Échec de la tentative d’établissement d’un lien de réplication pour la partition d’annuaire accessible en écriture suivante.
19:26	NTDS KCC	La tentative d’établir un lien de réplication vers une partition de répertoire en lecture seule avec les paramètres suivants a échoué.

Symptôme 5

Lorsque vous cliquez avec le bouton droit sur l’objet de connexion à partir d’un contrôleur de domaine source (DC) dans les sites et services Active Directory, puis sélectionnez Répliquer maintenant, le processus échoue et vous recevez l’erreur suivante :

Texte du titre de la boîte de dialogue : Répliquer maintenant

Texte du message de boîte de dialogue :

L’erreur suivante s’est produite lors de la tentative de synchronisation du contexte de nommage %<nom> de partition d’annuaire% du contrôleur de domaine source> du contrôleur de domaine vers le contrôleur de domaine dc de destination> du contrôleur <<de domaine : l’accès est refusé.

L’opération ne continuera pas.

La capture d’écran suivante représente un exemple de l’erreur :

Solution de contournement

Utilisez les outils en ligne de commande et NETDIAG DCDIAG génériques pour exécuter plusieurs tests. Utilisez l’outil DCDIAG /TEST:CheckSecurityError en ligne de commande pour effectuer des tests spécifiques. (Ces tests incluent une vérification d’inscription SPN.)

Pour contourner ce problème, effectuez les étapes suivantes :

1. À l’invite de commandes, exécutez DCDIAG sur le contrôleur de domaine de destination.
2. Exécutez DCDIAG /TEST:CheckSecurityError et NETDIAG.
3. Résolvez les erreurs identifiées par DCDIAG.
4. Réessayez l’opération de réplication ayant échoué précédemment. Si les réplications continuent d’échouer, consultez les causes et solutions suivantes.

Les causes suivantes peuvent entraîner l’erreur 5. Certains d’entre eux ont des solutions.

Cause 1 : Il existe un canal de sécurité ou une incompatibilité de mot de passe non valide sur le contrôleur de domaine source ou de destination

Validez le canal de sécurité en exécutant l’une des commandes suivantes :

• nltest /sc_query:<Domain Name>

• netdom verify <DC Name>

À condition, réinitialisez le mot de passe du contrôleur de domaine de destination à l’aide NETDOM /RESETPWDde .

Solution

1. Désactivez le service KDC (Kerberos Key Distribution Center) sur le contrôleur de domaine de destination.

2. À partir d’une invite de commandes avec élévation de privilèges sur le contrôleur de domaine de destination, obtenez le ticket Kerberos du système en exécutant Klist -li 0x3e7 purge.

3. Exécutez NETDOM RESETPWD pour réinitialiser le mot de passe du contrôleur de domaine distant :

   c:\>netdom resetpwd /server:<remote_dc_name> /userd: domain_name\administrator /passwordd: administrator_password
   

4. Assurez-vous que les contrôleurs de domaine potentiels et le contrôleur de domaine source (s’ils se trouvent dans le même domaine) répliquent le nouveau mot de passe du contrôleur de domaine de destination.

5. Démarrez le service KDC sur le contrôleur de domaine de destination et réessayez l’opération de réplication.

Pour plus d’informations, consultez Comment utiliser Netdom.exe pour réinitialiser les mots de passe de compte d’ordinateur d’un contrôleur de domaine.

Cause 2 : Le paramètre « CrashOnAuditFail » dans le registre du contrôleur de domaine de destination a la valeur « 2 »

Une CrashOnAuditFail valeur est 2 déclenchée si l’audit : arrêter le système immédiatement s’il n’est pas en mesure de journaliser le paramètre de stratégie d’audit de sécurité dans la stratégie de groupe est activé et que le journal des événements de sécurité local est plein.

Les contrôleurs de domaine Active Directory sont particulièrement sujets aux journaux de sécurité de capacité maximale lorsque l’audit est activé et que la taille du journal des événements de sécurité est limitée par les événements Ne pas remplacer les événements (effacer manuellement le journal) et remplacer les options nécessaires dans l’Observateur d’événements ou leurs équivalents de stratégie de groupe.

Solution

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, vérifiez que vous suivez ces étapes attentivement. Pour pallier à toute éventualité, sauvegardez le Registre avant de le modifier afin de pouvoir le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du registre, voir : Procédure de sauvegarde, de modification et de restauration du Registre dans Windows.

1. Effacez le journal des événements de sécurité et enregistrez-le dans un autre emplacement si nécessaire.

2. Réévaluez toutes les contraintes de taille sur le journal des événements de sécurité. Cela inclut les paramètres basés sur des stratégies.

3. Supprimez puis recréez une CrashOnAuditFail entrée de Registre comme suit :

   Sous-clé de Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
   Nom de la valeur : CrashOnAuditFail
   Type de valeur : REG_DWORD
   Données de valeur : 1

4. Redémarrez le contrôleur de domaine de destination.

Lorsque vous voyez une CrashOnAuditFail valeur ou 0 1, certains ingénieurs CSS ont résolu les erreurs « Accès refusé » en désactivant à nouveau le journal des événements de sécurité, en supprimant la valeur du CrashOnAuditFail Registre et en redémarrant le contrôleur de domaine de destination.

Pour plus d’informations, consultez Gérer l’audit et le journal de sécurité.

Cause 3 : Approbation non valide (le canal sécurisé sur le contrôleur de domaine source ou de destination n’est pas valide, ou les relations d’approbation dans la chaîne d’approbation sont rompues ou non valides)

Si la réplication Active Directory échoue entre les contrôleurs de domaine dans différents domaines, vous devez vérifier l’intégrité des relations d’approbation le long du chemin d’approbation.

Vous pouvez essayer le test relation d’approbation NetDiag pour vérifier les approbations rompues. L’utilitaire Netdiag.exe identifie les approbations rompues en affichant le texte suivant :

Trust relationship test. . . . . . : Failed  
Test to ensure DomainSid of domain '<domainname>' is correct.  
[FATAL] Secure channel to domain '<domainname>' is broken.  
[% <variable status code> %]

Par exemple, si vous avez une forêt multi-domaines qui contient un domaine racine (Contoso.COM), un domaine enfant (B.Contoso.COM), un domaine petit-enfant (C.B.Contoso.COM) et un domaine d’arborescence dans la même forêt (Fabrikam.COM) et si la réplication échoue entre les contrôleurs de domaine dans le domaine grand-enfant () et le domaine d’arborescence (Fabrikam.COM)C.B.Contoso.COM, vous devez vérifier l’intégrité de confiance entre C.B.Contoso.COM etB.Contoso.COM, entre B.Contoso.COM etContoso.COM, enfin, entre et enfin entre Contoso.COM et Fabrikam.COM.

Si une approbation de raccourci existe entre les domaines de destination, vous n’avez pas besoin de valider la chaîne de chemins d’accès d’approbation. Au lieu de cela, vous devez valider l’approbation de raccourci entre la destination et le domaine source.

Recherchez les modifications de mot de passe récentes apportées à l’approbation en exécutant la commande suivante :

Repadmin /showobjmeta * <DN path for TDO in question>

Vérifiez que le contrôleur de domaine de destination est transitif en répliquant de manière transitive la partition de répertoire de domaine accessible en écriture où les modifications de mot de passe d’approbation peuvent prendre effet.

Les commandes permettant de réinitialiser les approbations à partir du contrôleur de domaine racine sont les suivantes :

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay

Les commandes permettant de réinitialiser les approbations à partir du contrôleur de domaine enfant sont les suivantes :

netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset /TwoWay

Cause 4 : Décalage horaire excessif

Il existe une différence de temps entre le contrôleur de domaine de destination utilisé par le contrôleur de domaine de destination et le contrôleur de domaine source. La différence de temps dépasse l’asymétrie maximale de temps autorisée par Kerberos définie dans la stratégie de domaine par défaut.

Les paramètres de stratégie Kerberos dans la stratégie de domaine par défaut permettent une différence de cinq minutes dans le temps système (il s’agit de la valeur par défaut) entre les contrôleurs de domaine KDC et les serveurs cibles Kerberos pour empêcher les attaques par relecture. Certaines documentations indiquent que l’heure système du client et celle de la cible Kerberos doivent être comprises dans les cinq minutes entre elles. D’autres documents indiquent que, dans le contexte de l’authentification Kerberos, l’heure qui est importante est le delta entre le KDC utilisé par l’appelant et l’heure sur la cible Kerberos. De plus, Kerberos ne s’occupe pas si l’heure système sur les contrôleurs de domaine appropriés correspond à l’heure actuelle. Il s’agit uniquement de la différence de temps relative entre le contrôleur de domaine KDC et le contrôleur de domaine cible dans le délai maximal que la stratégie Kerberos autorise. (La durée par défaut est de cinq minutes ou moins.)

Dans le contexte des opérations Active Directory, le serveur cible est le contrôleur de domaine source qui est contacté par le contrôleur de domaine de destination. Chaque contrôleur de domaine d’une forêt Active Directory qui exécute actuellement le service KDC est un contrôleur de domaine potentiel. Par conséquent, vous devez prendre en compte l’exactitude du temps sur tous les autres contrôleurs de domaine par rapport au contrôleur de domaine source. Cela inclut le temps sur le contrôleur de domaine de destination lui-même.

Vous pouvez utiliser les deux commandes suivantes pour vérifier la précision du temps :

• DCDIAG /TEST:CheckSecurityError
• W32TM /MONITOR

Vous trouverez un exemple de sortie dans DCDIAG /TEST:CheckSecurityError la section « Plus d’informations ». Cet exemple montre un décalage horaire excessif sur les contrôleurs de domaine.

Recherchez les événements LSASRV 40960 sur le contrôleur de domaine de destination lorsque la demande de réplication échoue. Recherchez les événements qui citent un GUID dans l’enregistrement CNAME du contrôleur de domaine source avec l’erreur étendue 0xc000133. Recherchez les événements qui ressemblent à ce qui suit :

0xc000133 : l’heure au contrôleur de domaine principal est différente de l’heure au niveau du contrôleur de domaine de sauvegarde ou du serveur membre par trop grande quantité

Les traces réseau qui capturent l’ordinateur de destination qui se connecte à un dossier partagé sur le contrôleur de domaine source (et également d’autres opérations) peuvent afficher l’erreur « Une erreur étendue s’est produite » à l’écran, mais une trace réseau affiche les informations suivantes :

-> KerberosV5 KerberosV5 :TGS Request Realm : <- Requête TGS à partir du contrôleur de domaine source
<- Kerberosvs Kerberosvs :KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- Réponse TGS où « KRB_AP_ERR_TKE_NYV
<- mappe à « Ticket non encore valide » <- mappe à « Ticket non encore valide »

La TKE_NYV réponse indique que la plage de dates du ticket TGS est plus récente que l’heure sur la cible. Cela indique une asymétrie excessive du temps.

Note

• W32TM /MONITOR vérifie l’heure uniquement sur les contrôleurs de domaine dans le domaine des ordinateurs de test. Vous devez donc l’exécuter dans chaque domaine et comparer le temps entre les domaines.
• Si l’heure système a été jugée inexacte, essayez de déterminer pourquoi et ce qui peut être fait pour empêcher l’heure inexacte à l’avenir. Le contrôleur de domaine principal racine de la forêt a-t-il été configuré avec une source de temps externe ? Les sources de temps de référence sont-elles en ligne et disponibles sur le réseau ? Le service a-t-il été en cours d’exécution ? Les ordinateurs de rôle DC sont-ils configurés pour utiliser la hiérarchie NT5DS pour l’heure source ?
• Lorsque la différence de temps est trop importante sur les contrôleurs de domaine de destination, la commande Répliquer maintenant dans DSSITE. MSC échoue avec l’erreur « Il y a une heure et/ou une différence de date entre le client et le serveur » à l’écran. Cette chaîne d’erreur correspond à l’erreur 1398 (décimale) ou 0x576 (hexadécimal) avec le nom d’erreur symbolique ERROR_TIME_SKEW.

Pour plus d’informations, consultez Définition de la tolérance de synchronisation d’horloge pour empêcher les attaques par relecture.

Cause 5 : Le paramètre « RestrictRemoteClients » dans le Registre a la valeur « 2 »

Si le paramètre de stratégie des clients RPC non authentifiés est activé et défini sur Authentifié sans exceptions, la RestrictRemoteClients valeur de Registre est définie sur une valeur de la sous-clé de 0x2 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC Registre.

Ce paramètre de stratégie permet uniquement aux clients RPC (Remote Procedure Call) authentifiés de se connecter aux serveurs RPC qui s’exécutent sur l’ordinateur auquel le paramètre de stratégie est appliqué. Elle n’autorise pas les exceptions. Si vous sélectionnez cette option, le système ne peut pas recevoir d’appels anonymes distants à l’aide de RPC. Ce paramètre ne doit jamais être appliqué à un contrôleur de domaine.

Solution

1. Désactivez les restrictions pour le paramètre de stratégie des clients RPC non authentifiés qui limite la valeur de RestrictRemoteClients Registre à 2.

   Note

   Le paramètre de stratégie se trouve dans le chemin d’accès suivant :

   Configuration ordinateur\Modèles d’administration\System\Appel de procédure distante\Restrictions pour les clients RPC non authentifiés.

2. Supprimez le paramètre de RestrictRemoteClients Registre, puis redémarrez.

Pour plus d’informations, consultez Restrictions pour les clients RPC non authentifiés : la stratégie de groupe qui frappe votre domaine dans le visage et la clé de Registre RestrictRemoteClients est activée.

Cause 6 : le droit d’utilisateur « Accéder à cet ordinateur à partir du réseau » n’est pas accordé au groupe « Contrôleurs de domaine d’entreprise » ou à un utilisateur qui a déclenché la réplication

Dans une installation par défaut de Windows, la stratégie de contrôleur de domaine par défaut est liée à l’unité d’organisation du contrôleur de domaine (UO). L’unité d’organisation accorde l’accès à cet ordinateur à partir de l’utilisateur réseau droit aux groupes de sécurité suivants :

Stratégie locale	Stratégie de contrôleur de domaine par défaut
Administrateurs	Administrateurs
Utilisateurs authentifiés	Utilisateurs authentifiés
Tout le monde	Tout le monde
Contrôleurs de domaine d’entreprise	Contrôleurs de domaine d’entreprise
[Accès compatible avec Windows 2000]	Accès pré-Windows 2000 compatible

Si les opérations Active Directory échouent avec l’erreur 5, vous devez vérifier les points suivants :

• Les groupes de sécurité de la table reçoivent l’accès à cet ordinateur à partir du droit de l’utilisateur réseau dans la stratégie du contrôleur de domaine par défaut.

• Les comptes d’ordinateur du contrôleur de domaine se trouvent dans l’unité d’organisation du contrôleur de domaine.

• La stratégie du contrôleur de domaine par défaut est liée à l’unité d’organisation du contrôleur de domaine ou à d’autres unités d’organisation qui hébergent les comptes d’ordinateur du contrôleur de domaine.

• La stratégie de groupe est appliquée au contrôleur de domaine de destination qui enregistre actuellement l’erreur 5.

• L’accès refusé à cet ordinateur à partir du droit d’utilisateur réseau est activé ou ne fait pas référence à des groupes directs ou transitifs que le contexte de sécurité utilisé par le contrôleur de domaine ou le compte d’utilisateur déclenche la réplication.

• La priorité des stratégies, l’héritage bloqué, le filtrage WMI (Microsoft Windows Management Instrumentation) ou les autres n’empêchent pas l’application du paramètre de stratégie aux ordinateurs de rôle du contrôleur de domaine.

Note

• Les paramètres de stratégie peuvent être validés avec RSOP. MSC, mais GPRESULT est l’outil préféré, car il est plus précis, par exemple, GPRESULT /H c:\temp\GPOResult.html ou GPRESULT /Z.
• La stratégie locale est prioritaire sur les stratégies définies dans les sites, les domaines et les unités d’organisation.
• À un moment donné, il était courant pour les administrateurs de supprimer les contrôleurs de domaine d’entreprise et les groupes Tout le monde de l’accès à cet ordinateur du paramètre de stratégie réseau dans la stratégie du contrôleur de domaine par défaut. Toutefois, la suppression des deux groupes est irrécupérable. Il n’existe aucune raison de supprimer les contrôleurs de domaine d’entreprise de ce paramètre de stratégie, car seuls les contrôleurs de domaine sont membres de ce groupe.

Cause 7 : Il existe une incompatibilité de signature SMB entre les contrôleurs de domaine source et de destination

La meilleure matrice de compatibilité pour la signature SMB est définie par quatre paramètres de stratégie et leurs équivalents basés sur le Registre :

Paramètre de stratégie	Chemin d’accès au Registre
Client réseau Microsoft : communications signées numériquement (lorsque le serveur l’accepte)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
Client réseau Microsoft : communications signées numériquement (toujours)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
Serveur réseau Microsoft : Signer numériquement les communications (si le serveur accepte)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
Serveur réseau Microsoft : communications signées numériquement (toujours)	HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature

Vous devez vous concentrer sur les incompatibilités de signature SMB entre les contrôleurs de domaine source et de destination. Les cas classiques impliquent un paramètre activé ou obligatoire d’un côté, mais désactivé l’autre.

Note

Les tests internes ont montré des incompatibilités de signature SMB, ce qui provoque l’échec de la réplication avec l’erreur 1722 : « Le serveur RPC n’est pas disponible ».

Cause 8 : fragmentation des paquets Kerberos au format UDP

Les routeurs et commutateurs réseau peuvent fragmenter ou supprimer complètement des paquets réseau au format UDP (User Datagram Protocol) volumineux qui sont utilisés par Kerberos et les mécanismes d’extension pour DNS (EDNS0).

Solution

1. À partir de la console du contrôleur de domaine de destination, effectuez un test ping sur le contrôleur de domaine source par son nom d’ordinateur complet pour identifier le plus grand paquet pris en charge par l’itinéraire réseau. Pour ce faire, exécutez la commande suivante :

   c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472
   

2. Si le plus grand paquet non fragmenté est inférieur à 1 472 octets, essayez l’une des méthodes suivantes (par ordre de préférence) :

   • Modifiez l’infrastructure réseau pour prendre en charge les grandes trames UDP. Cela peut nécessiter une mise à niveau du microprogramme ou une modification de configuration sur les routeurs, les commutateurs ou les pare-feu.
   • Définissez maxpacketsize (sur le contrôleur de domaine de destination) sur le plus grand paquet identifié par la PING -f -l commande moins de 8 octets pour prendre en compte l’en-tête TCP, puis redémarrez le contrôleur de domaine modifié.
   • Définissez maxpacketsize (sur le contrôleur de domaine de destination) sur une valeur de 1. Cela déclenche l’authentification Kerberos pour utiliser un protocole TCP. Redémarrez le contrôleur de domaine modifié pour que la modification prenne effet.

3. Réessayez l’opération Active Directory ayant échoué.

Cause 9 : les cartes réseau ont la fonctionnalité « Déchargement d’envoi volumineux » activée

Solution

1. Sur le contrôleur de domaine de destination, ouvrez les propriétés de la carte réseau.
2. Sélectionnez le bouton Configurer.
3. Sélectionnez l'onglet Avancé.
4. Désactivez la propriété De déchargement d’envoi volumineux IPv4.
5. Redémarrez le contrôleur de domaine.

Cause 10 : Domaine Kerberos non valide

Le domaine Kerberos n’est pas valide si une ou plusieurs des conditions suivantes sont remplies :

• L’entrée KDCNames de Registre contient incorrectement le nom de domaine Active Directory local.
• La PolAcDmN clé de Registre et la clé de PolPrDmN Registre ne correspondent pas.

Solutions

Important

Cette section, méthode ou tâche contient des étapes vous indiquant comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, vérifiez que vous suivez ces étapes attentivement. Pour pallier à toute éventualité, sauvegardez le Registre avant de le modifier afin de pouvoir le restaurer en cas de problème. Pour plus d’informations sur la sauvegarde et la restauration du registre, voir : Procédure de sauvegarde, de modification et de restauration du Registre dans Windows.

Solution à l’entrée de Registre « KDCNames » incorrecte

1. Sur le contrôleur de domaine de destination, exécutez REGEDIT.
2. Recherchez la sous-clé suivante dans le Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains
3. Pour chaque <Fully_Qualified_Domain> sous la sous-clé, vérifiez que la valeur de l’entrée de KdcNames Registre fait référence à un domaine Kerberos externe valide et non au domaine local ou à un autre domaine dans la même forêt Active Directory.

Solution aux clés de Registre « PolAcDmN » et « PolPrDmN » incompatibles

1. Démarrez l'Éditeur du Registre.

2. Dans le volet de navigation, développez Sécurité.

3. Dans le menu Sécurité, sélectionnez Autorisations pour accorder au groupe local Administrateurs un contrôle total de la SECURITY ruche et de ses conteneurs et objets enfants.

4. Recherchez la sous-clé suivante dans le Registre :
   HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN

5. Dans le volet droit de l’Éditeur de Registre, sélectionnez l’entrée de Registre No Name : REG_NONE entrée de Registre une fois.

6. Dans le menu Affichage , sélectionnez Afficher les données binaires.

7. Dans la section Format de la boîte de dialogue, sélectionnez Octet.

   Le nom de domaine s’affiche sous forme de chaîne sur le côté droit de la boîte de dialogue Données binaires. Le nom de domaine est le même que le domaine Kerberos.

8. Recherchez la sous-clé suivante dans le Registre :
   HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN

9. Dans le volet droit de l’Éditeur de Registre, double-cliquez sur l’entrée No Name : REG_NONE .

10. Dans la boîte de dialogue Éditeur binaire, collez la valeur de la sous-clé de PolPrDmN Registre. (La valeur de la sous-clé de PolPrDmN Registre est le nom de domaine NetBIOS).

11. Redémarrez le contrôleur de domaine. Si le contrôleur de domaine ne fonctionne pas correctement, consultez d’autres méthodes.

Cause 11 : Il existe une incompatibilité de compatibilité du gestionnaire de réseau local (LM Compatibility) entre les contrôleurs de domaine source et de destination

Cause 12 : Les noms de principal de service ne sont pas inscrits ou non présents en raison d’une latence de réplication simple ou d’un échec de réplication

Cause 13 : Le logiciel antivirus utilise un pilote de filtre de carte réseau mini-pare-feu sur le contrôleur de domaine source ou de destination

Plus d’informations

Les erreurs et événements Active Directory tels que ceux décrits dans la section « Symptômes » peuvent également échouer avec l’erreur 8453 avec la chaîne d’erreur similaire à celle suivante :

L’accès à la réplication a été refusé.

Les situations suivantes peuvent entraîner l’échec des opérations Active Directory avec l’erreur 8453. Toutefois, ces situations ne provoquent pas d’échecs avec l’erreur 5.

• La tête du contexte d’affectation de noms (NC) n’est pas autorisée avec l’autorisation De réplication des modifications du répertoire.
• La réplication de démarrage du principal de sécurité n’est pas membre d’un groupe disposant de l’autorisation De modification du répertoire de réplication.
• Les indicateurs sont manquants dans l’attribut UserAccountControl . Ces indicateurs incluent SERVER_TRUST_ACCOUNT et TRUSTED_FOR_DELEGATION.
• Le contrôleur de domaine en lecture seule (RODC) a joint le domaine sans exécuter la ADPREP /RODCPREP commande.

Exemple de sortie de « DCDIAG /TEST :CheckSecurityError »

L’exemple de sortie d’un contrôleur de DCDIAG /CHECKSECURITYERROR domaine est le suivant. Cela est dû à une asymétrie excessive du temps.

Doing primary tests  
Testing server: <Site_Name>\<Destination_DC_Name>  
Starting test: CheckSecurityError  
Source DC <Source DC> has possible security error (5). Diagnosing...  
Time skew error between client and 1 DCs! ERROR_ACCESS_DENIED or down machine recieved by:
<Source DC>  
Source DC <Source DC>_has possible security error (5). Diagnosing...  
Time skew error: 7205 seconds different between:.  
<Source DC>  
<Destination_DC>  
[<Source DC>] DsBindWithSpnEx() failed with error 5,  
Access is denied..  
Ignoring DC <Source DC> in the convergence test of object CN=<Destination_DC>,OU=Domain  Controllers,DC=<DomainName>,DC=com, because we cannot connect!  
......................... <Destination_DC> failed test CheckSecurityError  

L’exemple de sortie est DCDIAG /CHECKSECURITYERROR le suivant. Il affiche les noms de SPN manquants. (La sortie peut varier de l’environnement à l’environnement.)

Doing primary tests  
Testing server: <site name>\<dc name>  
Test omitted by user request: Advertising  
Starting test: CheckSecurityError  
* Dr Auth: Beginning security errors check'  
Found KDC <KDC DC> for domain <DNS Name of AD domain> in site <site name>  
Checking machine account for DC <DC name> on DC <DC Name>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<DNS domain name>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>  
* Missing SPN :LDAP/<hostname>  
* Missing SPN :LDAP/<hostname>.<DNS domain name>/<NetBIOS domain name>  
* Missing SPN :LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<forest root domain DN>  
* SPN found :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Settings object GUID>/<forest root domain DNS name>  
* Missing SPN :HOST/<hostname>.<DNS domain name>/<DNS domain name>  
* SPN found :HOST/<hostname>.<DNS domain name>  
* SPN found :HOST/<hostname>  
* Missing SPN :HOST/<hostname>.<DNS domain name>/<NetBIOS domain name>  
* Missing SPN :GC/<hostname>.<DNS domain name>/<DNS domain name>
Unable to verify the machine account (<DN path for Dc machine account>) for <DC Name> on <DC name>.

Collecte de données

Si vous avez besoin d’aide du support Microsoft, nous vous recommandons de collecter les informations en suivant les étapes mentionnées dans Collecter des informations à l’aide de TSS pour les problèmes de réplication Active Directory.