Comment faire pour résoudre les erreurs de réplication Active Directory 5 « accès refusé » dans Windows Server

Le support de Windows Server 2003 a pris fin le 14 juillet 2015

Microsoft a mis fin au support de Windows Server 2003 le 14 juillet 2015. Cette modification a affecté vos mises à jour logicielles et options de sécurité. Découvrez les implications de ce changement à votre niveau et la marche à suivre pour rester protégé.

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3073945
Cet article décrit les symptômes, cause et résolution des situations d'Active Directory, la réplication échoue witherror 5 :
L'accès est refusé.
Symptômes
Vous pouvez rencontrer un ou plusieurs des problèmes suivants lors de la réplication d'Active Directory échoue avec l'erreur 5.

Symptôme 1

L'outil de ligne de commande Dcdiag.exe signale que le test de la réplication Active Directory échoue avec le code d'état erreur (5). L'état semblable à la suivante :

Test du serveur : Nom_site\Destination_DC_Name
Test de démarrage : réplications
* Vérifier les réplications
[Contrôle des réplications,Destination_DC_Name] Une tentative de réplication récente a échoué :
À partir de Source_DC Pour Destination_DC
Contexte d'appellation : Directory_Partition_DN_Path
La réplication a généré une erreur (5) :
L'accès est refusé.
La défaillance s'est produite à DateHeure.
La dernière réussite s'est produite à DateHeure.
Numéro de défaillances sont sont produites depuis le dernier succès.

Symptôme 2

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

Problème 3

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

Les commandes REPADMIN fréquemment citent l'état 5 incluent mais ne sont pas limitées à ce qui suit :
  • REPADMIN /KCC
  • REPADMIN /REPLICATE
  • REPADMIN /REPLSUM
  • REPADMIN /SHOWREPL
  • REPADMIN /SHOWREPS
  • REPADMIN /SYNCALL
Exemple de sortie de la commande REPADMIN /SHOWREPLsuit. Ce résultat affiche une réplication entrante à partir deDC_2_Name Pour DC_1_NameÉchec avec l'erreur « Accès refusé ».

Nom_site\DC_1_Name
Options de DSA : IS_GC
Options de site: (aucune)
GUID d'objet DSA : GUID
ID d'invocation DSA : ID d'invocation

=== VOISIN ENTRANT ===
DC =Nom_domaine, DC = com
Nom_site\DC_2_Name via RPC
GUID d'objet DSA : GUID
La dernière tentative @ DateHeure a échoué, résultat 5(0x5) :
L'accès est refusé.
<#>échecs consécutifs.
Dernière réussite </#>DateHeure.

Problème 4

Événements de KCC NTDS ou NTDS Général 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ésume les événements Active Directory fréquemment citent l'état 8524.
ID d'événementSourceChaîne d'événement
1655NTDS GénéralActive Directory a tenté de communiquer avec le catalogue global suivant et les tentatives ont échoué.
1925KCC NTDSÉchec de la tentative d'établissement d'un lien de réplication pour la partition d'annuaire accessible en écriture suivante.
1926KCC NTDSLa tentative d'établir un lien de réplication pour une partition d'annuaire en lecture seule avec les paramètres suivants a échoué.

Symptôme 5

Lorsque vous cliquez sur l'objet connexion à partir d'un contrôleur de domaine source dans les Sites Active Directory et les Services, puis sélectionnezRépliquer maintenant, le processus échoue et vous recevez le message d'erreur suivant :

Répliquer maintenant

L'erreur suivante s'est produite lors de la tentative de synchronisation % de contexte d'attribution de nomsnom de partition d'annuaire% à partir du contrôleur de domaine Contrôleur de domaine source contrôleur de domaine Contrôleur de domaine de destination:
L'accès est refusé.

L'opération ne peut pas continuer.

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


Contournement
Utilisez le modèle génériqueDCDIAG outil de ligne de commande pour exécuter plusieurs tests. Utilisez l'outil de ligne de commande DCDIAG /TEST:CheckSecurityErrorspour effectuer des tests spécifiques. (Ces tests incluent une vérification de l'inscription de nom principal de service). Exécutez les tests pour résoudre les problèmes de réplication des opérations Active Directory échoue avec l'erreur 5 et erreur 8453. Toutefois, sachez que cet outil ne s'exécute pas dans le cadre de l'exécution par défaut deDCDIAG.

Pour contourner ce problème, procédez comme suit :
  1. À l'invite de commande, exécutez DCDIAG sur le contrôleur de domaine de destination.
  2. Exécutez DCDAIG /TEST:CheckSecurityError.
  3. Exécution de NETDIAG.
  4. Résoudre les erreurs qui ont été identifiés parDCDIAG et NETDIAG.
  5. Réessayer l'échec précédemment opération de réplication.
Si la réplication continue à échouer, voir le "Causes et solutions.


Causes et solutions
Les causes suivantes peuvent provoquer l'erreur 5. Certains d'entre eux ont des solutions.

Cause 1: Le paramètre du Registre RestrictRemoteClients a la valeur 2

Si le paramètre de stratégie Restrictions pour les clients RPC non authentifiéest activé et aauthentifié sans exceptions, la valeur de Registre RestrictRemoteClients est définie à une valeur de 0 x 2 dans la sous-clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC.

Ce paramètre de stratégie permet uniquement l'authentification à distance RPC clients (RPC) pour se connecter aux serveurs RPC qui sont exécutent sur l'ordinateur sur lequel le paramètre de stratégie est appliqué. Il n'autorise pas d'exceptions. Si vous sélectionnez cette option, un 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 le paramètre de stratégie Restrictions pour les clients RPC non authentifiésqui limite la valeur de RegistreRestrictRemoteClients à 2.

    Remarque : Le paramètre de stratégie se trouve dans le chemin d'accès suivant :
    Computer Configuration\Administrative Templates\System\Remote Procedure Call\Restrictions for Unauthenticated RPC clients

  2. Supprimer le paramètre de Registre RestrictRemoteClientset redémarrez.
Reportez-vous à la section Restrictions pour les Clients RPC non authentifiés : la stratégie de groupe qui PERFORE votre domaine dans la face.

Cause 2: Le paramètre CrashOnAuditFail dans le Registre du contrôleur de domaine de destination a une valeur de 2

CrashOnAduitFail la valeur 2 est déclenchée si la Audit : arrêter immédiatement le système s'Impossible de se connecter aux audits de sécuritéparamètre dans Stratégie de groupe est activé et que le journal de sécurité local est plein.

Les contrôleurs de domaine Active Directory sont particulièrement sujettes aux journaux de sécurité des capacités maximales lorsque l'audit est activé et que la taille du journal d'événements de sécurité est limitée parne pas remplacer les événements (nettoyage manuel du journal)et les Remplacer si nécessaireles options dans l'Observateur d'événements ou leurs équivalents de la stratégie de groupe.

Solution

Important Suivez les étapes décrites dans cette section avec soin. Des problèmes graves peuvent survenir si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegarder le Registre pour la restauration en cas de problème.
  1. Effacer le journal d'événements de sécurité et l'enregistrer dans un autre emplacement selon vos besoins.
  2. Réévaluer les contraintes de taille sur le journal de sécurité. Cela inclut les paramètres de stratégie.
  3. Supprimez, puis créez de nouveau une entrée de Registre CrashOnAuditFail comme suit :
    Sous-clé de Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
    Nom de la valeur : CrashOnAuditFail
    Type de la valeur : REG_DWORD
    Données de la valeur: 1
  4. Redémarrez le contrôleur de domaine de destination.
Pour plus d'informations, consultez les articles suivants dans la Base de connaissances Microsoft :

Cause 3: Niveau de confiance non valide

Échec de la réplication de Active Directory entre les contrôleurs de domaine dans différentsdomaines, vous devez vérifier l'intégrité des relations d'approbation sur le chemin d'approbation.

Vous pouvez essayer de la relation de confiance NetDiagapprouve le test pour vérifier pour les brisures. L'utilitaire Netdiag.exe identifie les approbations en affichant le texte suivant :
Test de la relation d'approbation...... : Échec de
Test pour garantir DomainSid du domaine 'nom_domaine' est correct.
[FATAL] Canal sécurisé vers le domaine 'nom_domaine' est interrompue.
[%code d'état d'une variable%]

Par exemple, si vous avez une forêt à plusieurs 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 de l'arborescence dans la même forêt (Fabrikam.COM) et échoue si la réplication entre les contrôleurs de domaine dans le domaine petit-enfant (C.B.Contoso.COM) et le domaine de l'arborescence (Fabrikam.COM), vous devez vérifier la santé de confiance entre C.B.Contoso.COM et B.Contoso.COM , entre B.Contoso.COM et Contoso.COM, puis enfin entre les forêts Contoso.COM et Fabrikam.COM.

S'il existe une approbation raccourcie entre les domaines de la destination, vous n'avez pas valider la chaîne de chemin d'accès de confiance. Au lieu de cela, vous devez valider l'approbation raccourcie entre le domaine source et de destination.

Vérifiez les modifications récentes du mot de passe pour 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 transitive entrant pour répliquer la partition d'annuaire de domaine accessible en écriture où les changements de mot de passe d'approbation peuvent prendre effet.

Commandes pour réinitialiser les approbations à partir du contrôleur principal de domaine du domaine racine sont les suivantes :
netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay
Commandes pour réinitialiser les approbations à partir du contrôleur principal de domaine du domaine enfant sont les suivantes :
netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset /TwoWay

Cause 4: Perdure skew

Les paramètres de stratégie Kerberos dans la stratégie de domaine par défaut permettent d'une différence de cinq minutes de l'heure système (il s'agit de la valeur par défaut) entre les contrôleurs de domaine KDC et les serveurs cibles de Kerberos pour empêcher les attaques de relecture. Une documentation qui indique l'heure du système du client et celui de la cible Kerberos doit être dans les cinq minutes des unes des autres. Autre documentation stipule que, dans le cadre de l'authentification Kerberos, le temps est important est le delta entre le KDC est utilisé par l'appelant et de l'heure sur la cible Kerberos. En outre, Kerberos ne se soucie pas si l'heure système sur les contrôleurs de domaine appropriés correspond à heure actuelle. Il reconnaît uniquement qui relativedifférence de temps entre le contrôleur de domaine contrôleur de domaine Kerberos et la cible est le délai maximum inclinaison que Kerberos permet de stratégie. (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 dans une forêt Active Directory qui exécute actuellement le service KDC est un KDC potentiel. Par conséquent, vous devez prendre en compte de la précision de l'heure sur tous les autres contrôleurs de domaine sur le contrôleur de domaine source. Cela inclut le temps sur le contrôleur de domaine de destination elle-même.

Vous pouvez utiliser les deux commandes suivantes pour vérifier la précision de l'heure :
  • /TEST:CheckSecurityError DCDIAG
  • W32TM/SURVEILLANCE
Vous trouverez un exemple de sortie deDCDIAG /TEST:CheckSecurityErrordans la "Plus d'informations. Cet exemple montre perdure skew sur les contrôleurs de domaine Windows Server 2003 et Windows Server 2008 R2.

Recherchez LSASRV 40960 événements sur le contrôleur de domaine de destination au moment de l'échec d'une demande de réplication. Recherchez les événements qui invoquent un GUID dans l'enregistrement CNAME du contrôleur de domaine source avec l'erreur étendue 0xc000133. Recherchez les événements semblables aux suivants :
L'heure sur le contrôleur de domaine principal est différent de celui de l'heure sur le contrôleur secondaire de domaine ou un serveur membre est trop importante

Peuvent afficher 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) le « une erreur étendue s'est produite » à l'écran erreur, qu'une trace réseau affiche les informations suivantes :
-> KerberosV5 KerberosV5:TGS Request Realm: <- TGS request from source DC <- Kerberosvs Kerberosvs:KRB_ERROR - KRB_AP_ERR_TKE_NVV (33) <- TGS response where "KRB_AP_ERR_TKE_NYV<- maps to "Ticket not yet valid"                                                                                                                                  <-  maps to "Ticket not yet valid"
La réponse de le TKE_NYVindique que la plage de dates dans le ticket TGS est plus récente que l'heure sur le système cible. Cela indique perdure skew.

Remarques
  • W32TM MONITORvérifie l'heure uniquement sur les contrôleurs de domaine dans le domaine d'ordinateurs de test, afin que vous exécutez cette procédure dans chaque domaine et comparer le temps entre les domaines.
  • Lorsque la différence de temps est trop importante sur les contrôleurs de domaine basés sur Windows Server 2008 R2 de destination, la commande Dupliquer maintenant dans DSSITE. MSC échoue avec le « Il existe une différence d'heure et / ou de date entre le client et le serveur » à l'écran erreur. Cette chaîne d'erreur mappe en erreur 1398 decimal ou en hexadécimal avec le nom symbolique d'erreurERROR_TIME_SKEW de 0x576.
Pour plus d'informations, reportez-vous à la section. Tolérance de synchronisation d'horloge paramètre pour empêcher les attaques de relecture.

Cause 5: Est une incompatibilité de canal ou de mot de passe de sécurité non valide sur le contrôleur de domaine source ou de destination

Valider le canal sécurisé en exécutant une des commandes suivantes :
  • Nltest /sc:query
  • Vérifiez que Netdom

À condition, réinitialiser le mot de passe du contrôleur de domaine de destination à l'aide de NETDOM /RESETPWD.

Solution

  1. Désactiver le service Centre de Distribution de clés Kerberos (KDC, Key Distribution Center) sur le contrôleur de domaine est redémarré.
  2. À partir de la console du contrôleur de domaine de destination, exécutez NETDOM RESETPWD pour réinitialiser le mot de passe pour le contrôleur de domaine de destination comme suit :
    c:\>netdom resetpwd /server: server_name /userd: domain_name\administrator /passwordd: administrator_password
  3. Assurez-vous que KDC probable et le contrôleur de domaine source (si elles sont dans le même domaine) entrant connaissances répliquer de nouveau mot de passe du contrôleur de domaine de destination.
  4. Redémarrez le contrôleur de domaine de destination pour mettre à jour les tickets Kerberos et recommencez l'opération de réplication.
Reportez-vous à la section Comment faire pour utiliser Netdom.exe pour réinitialiser les mots de passe de compte ordinateur d'un contrôleur de domaine.

Cause 6: Le droit d'utilisateur « Accéder à cet ordinateur à partir du réseau » n'est pas accordé à un utilisateur qui déclenche 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 (OU). Le OUgrants de l'utilisateuraccéder à cet ordinateur à partir du réseau, droit à des groupes de sécurité suivants :
Stratégie localeStratégie de contrôleur de domaine par défaut
AdministrateursAdministrateurs
Utilisateurs authentifiésUtilisateurs authentifiés
Tout le mondeTout le monde
Contrôleurs de domaine d'entrepriseContrôleurs de domaine d'entreprise
[Pre-Windows 2000 compatible Access]Accès compatible pré-Windows 2000
Si les opérations Active Directory échouent avec l'erreur 5, vous devez vérifier les points suivants :
  • Le droit d'utilisateuraccéder à cet ordinateur à partir du réseau dans la stratégie du contrôleur de domaine par défaut est attribué à des groupes de sécurité dans la table.
  • Comptes d'ordinateur de contrôleur de domaine se trouvent dans l'unité d'organisation du contrôleur de domaine.
  • Stratégie du contrôleur de domaine par défaut est liée à d'autres unités d'organisation qui hébergent des comptes d'ordinateurs ou d'unités d'organisation du contrôleur de domaine.
  • Stratégie de groupe est appliquée sur le contrôleur de domaine de destination qui enregistre actuellement l'erreur 5.
  • Le droit d'utilisateur refuser accès à cet ordinateur à partir du réseau est activé, ou ne pas aux groupes de référence directe ou transitive qui le contexte de sécurité utilisé par le contrôleur de domaine ou le compte d'utilisateur que déclenchement de la réplication.
  • Priorité de la stratégie, l'héritage bloqué, filtrage de Microsoft Windows Management Instrumentation (WMI) ou similaire n'empêche pas le paramètre de stratégie de s'appliquer aux ordinateurs de rôle de contrôleur de domaine.

Remarques
  • Paramètres de stratégie peuvent être validées avec le jeu de stratégie résultant. Outil MSC. Toutefois, GPRESULT /Z est l'outil préféré car il est plus précis.
  • Stratégie locale est prioritaire sur la stratégie qui est définie dans l'unité d'organisation, des domaines et des sites.
  • En même temps, il était courant pour les administrateurs de supprimer les « contrôleurs de domaine de l'entreprise » et « Tout le monde » de groupes à partir du paramètre de stratégie « Accéder à cet ordinateur à partir du réseau » dans la stratégie du contrôleur de domaine par défaut. Toutefois, la suppression de ces deux groupes est irrécupérable. Il n'y a aucune raison de supprimer « Contrôleurs de domaine d'entreprise » à partir de ce paramètre de stratégie, seuls les contrôleurs de domaine étant un membre de ce groupe.

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

La matrice de compatibilité des meilleure pour la signature SMB est décrite dans les sections « matrice d'interopérabilité » graphisme et de texte de l'article de la Base de connaissances916846. La matrice est définie par les quatre paramètres de stratégie et de leurs équivalents basés sur le Registre comme suit.
Paramètre de stratégie Chemin d'accès du 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 : communications signées numériquement (lorsque le serveur l'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 entre la destination et les contrôleurs de domaine source de signature SMB. Les cas classiques impliquant un paramètre qui est activé ou requise sur un côté mais désactivé sur l'autre.

La cause 8: La fragmentation des paquets UDP au format de Kerberos

Les commutateurs et routeurs de réseau peuvent fragmenter ou complètement rejeter les paquets de réseau UDP User Datagram Protocol-mise en forme de grande taille qui sont utilisées par Kerberos et les mécanismes d'Extension pour DNS (EDNS0). Les ordinateurs qui exécutent Windows 2000 Server ou la famille du système d'exploitation Windows Server 2003 sont particulièrement vulnérables à la fragmentation de UDP sur les ordinateurs qui exécutent Windows Server 2008 ou Windows Server 2008 R2.

Solution
  1. À partir de la console du contrôleur de domaine de destination, ping sur le contrôleur de domaine source par son nom qualifié complet pour identifier le plus grand paquet pris en charge par la gamme de 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 de moins de 1 472 octets, essayez l'une des méthodes suivantes (dans l'ordre de préférence) :
    • Modifier l'infrastructure de réseau pour prendre en charge correctement les trames d'UDP volumineux. Cela peut nécessiter une modification de configuration ou de la mise à niveau du microprogramme sur les routeurs, les commutateurs ou les pare-feu.
    • La valeur maxpacketsize (sur le contrôleur de domaine de destination) du plus grand paquet identifié par la commande PING-f-lmoins 8 octets pour tenir compte de l'en-tête TCP et redémarrez le contrôleur de domaine modifié.
    • La valeur maxpacketsize (sur le contrôleur de domaine de destination) une valeur de 1cela déclenche l'authentification Kerberos pour utiliser un TCP. Redémarrez le contrôleur de domaine modifié pour que les modifications prennent effet.
  3. Recommencez l'opération de Active Directory défectueux.

Cause 9: Cartes réseau qui ont activé la fonctionnalité déchargement d'envoi important

Solution
  1. Sur le contrôleur de domaine de destination, ouvrez les propriétés de la carte réseau.
  2. Cliquez surle bouton configurer .
  3. Sélectionnez l'onglet Avancé .
  4. Désactivez la propriété Déchargement envoyer grand IPv4 .
  5. Redémarrez le contrôleur de domaine.

Cause 10 : Domaine de Kerberos valide

Le domaine Kerberos n'est pas valide si une ou plusieurs des conditions suivantes sont remplies :
  • L'entrée de Registre KDCNames contient le nom de domaine Active Directory local de façon incorrecte.
  • L'entrée de Registre PolAcDmN et la clé de Registre PolPrDmN ne correspondent pas.

Solutions

Important Suivez les étapes décrites dans cette section avec soin. Des problèmes graves peuvent survenir si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegarder le Registre pour la restauration en cas de problème.

Solution pour l'entrée de Registre incorrecte KDCNames
  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 chaqueFully_Qualified_Domain> sous la sous-clé, vérifiez que la valeur de l'entrée de Registre KdcNames fait référence à un externe validede Kerberos et pas sur le domaine local ou d'un autre domaine dans la même forêt Active Directory.
Solution pour la non-concordance des clés de Registre PolAcDmN et PolPrDmN
Remarque Cette méthode est valide uniquement pour les contrôleurs de domaine qui exécutent Windows 2000 Server.
  1. Démarrez l'Éditeur du Registre.
  2. Dans le volet de navigation, développez sécurité.
  3. Dans le menu sécurité , cliquez sur autorisationspour accorder le contrôle total de groupe local Administrateurs d'objets la ruche SECURITY et ses conteneurs enfants.
  4. Recherchez la sous-clé suivante dans le Registre :
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN
  5. Dans le volet de droite de l'Éditeur du Registre, cliquez sur leAucun nom: Entrée de Registre REG_NONE une seule fois.
  6. Dans le menu affichage , cliquez sur Afficher les données binaires.
  7. Dans la section Format de la boîte de dialogue, cliquez suroctets.

    Le nom de domaine est affiché sous la forme d'une chaîne sur le côté droit de la boîte de dialogueDonné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 de droite de l'Éditeur du Registre, double-cliquez sur leAucun nom: L'entrée REG_NONE.
  10. Dans la boîte de dialogue Éditeur binaire, collez la valeur de la sous-clé PolPrDmNregistry. (La valeur de la sous-clé de Registre PolPrDmN est le nom de domaine NetBIOS).
  11. Redémarrez le contrôleur de domaine.
Si le contrôleur de domaine ne fonctionne pas correctement, reportez-vous àautres méthodes.

Cause 11 : Il existe une incompatibilité de compatibilité de LAN Manager (LM compatibilité) entre la source et la destination des contrôleurs de domaine

Cause 12 : Noms principaux de Service sont n'existe pas ou n'est pas inscrit en raison de la latence de réplication ou un échec de la réplication

Cause 13 : Antivirus utilisent des pilotes de filtre pare-feu mini carte réseau sur le contrôleur de domaine source ou de destination

Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».
Plus d'informations
Active les erreurs de répertoire et des événements, tels que ceux décrits dans la section "Symptômes" section peut également échouer avec l'erreur 8453 avec la chaîne d'erreur suivants, similaires :
Accès à la réplication a été refusé.

Les situations suivantes peuvent provoquer des opérations Active Directory échoue avec l'erreur 8453. Toutefois, ces situations ne provoquent pas de défaillances avec l'erreur 5.
  • Tête de contexte (CN) d'attribution de noms n'est pas autorisée avec l'autorisation de répliquer les modifications de répertoire.
  • La réplication de départ principal de sécurité n'est pas un membre d'un groupe qui dispose de l'autorisation de répliquer les modifications de répertoire.
  • Les indicateurs sont manquants dans l'attributUserAccountControl. Citons notamment les indicateursTRUSTED_FOR_DELEGATIONetSERVER_TRUST_ACCOUNT.
  • Le contrôleur de domaine en lecture seule (RODC) est joint dans le domaine sans la commandeADPREP /RODCPREPs'exécutant en premier.

Exemple de sortie de DCDIAG /TEST:CheckSecurityError


Exemple de sortie DCDIAG /test:CHECKSECURITYERRORà partir d'un contrôleur de domaine Windows Server 2008 R2 suit. Ce résultat est dû perdure skew.

Doing primary tests   Testing server: <Site_Name>\<Destination_DC_Name>      Starting test: CheckSecurityError        Source DC <Source DC> has possible security error (1398).         Diagnosing...               Time skew error between client and 1 DCs!  ERROR_ACCESS_DENIED               or down machine received by:                    <Source DC>         [<Source DC>] DsBindWithSpnEx() failed with error 1398,         There is a time and/or date difference between the client and server..         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
Exemple de sortie DCDIAG /CHECKSECURITYERROR à partir d'un contrôleur de domaine Windows Server 2003 suit. Cela est dû à l'inclinaison de temps excessif.
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
Exemple de sortie DCDIAG /CHECKSECURITYERRORsuit. Il montre pas les noms SPN. (La sortie peut varier de l'environnement).
Doing primary testsTesting server: <site name>\<dc name>Test omitted by user request: AdvertisingStarting 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>.



Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3073945 - Dernière mise à jour : 08/20/2015 23:18:00 - Révision : 1.0

Windows Server 2012 R2 Standard, Windows Server 2012 Standard, Windows Server 2008 R2 Standard, Windows Server 2008 Standard, Microsoft Windows Server 2003 R2 Standard x64 Edition, Microsoft Windows Server 2003 R2 Standard Edition (32-bit x86), Microsoft Windows Server 2003, Standard x64 Edition, Microsoft Windows Server 2003, Standard Edition (32-bit x86), Microsoft Windows 2000 Server

  • kbprb kbtshoot kbexpertiseadvanced kbsurveynew kbmt KB3073945 KbMtfr
Commentaires