Erreur de réplication Active Directory 5-accès refusé

Cet article décrit les symptômes, les causes et la résolution des situations dans lesquelles AD Operations échoue avec l’erreur 5 : l’accès est refusé.

Version du produit d’origine :   Windows Server 2012 R2
Numéro de la base de connaissances initiale :   2002013

Symptômes

  1. DCDIAG signale que le test de réplication Active Directory a échoué avec le code d’état d’erreur (5) : l’accès est refusé.

    Serveur d’évaluation : <site name><destination dc name>
    Test de démarrage : réplications
    Vérification des réplications
    [Vérification des réplications, <destination DC name] A recent replication attempt failed:
    From <source DC> à <destination DC>
    Contexte d’appellation : <directory partition DN path>
    La réplication a généré une erreur (5) :
    L’accès est refusé.
    L’échec s’est produit à <date> <time> .
    La dernière réussite s’est produite à <date> <time> . 3 les échecs ont eu lieu depuis la dernière réussite.

  2. DCDIAG signale que DsBindWithSpnEx () a échoué avec l’erreur 5.

  3. REPADMIN.EXE signale que la dernière tentative de réplication a échoué avec l’état 5.

    REPADMIN les commandes qui citent couramment le statut 5 incluent, mais ne sont pas limitées à :

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

    Un exemple de sortie de REPADMIN /SHOWREPS la description de la réplication entrante de contoso-DC2 vers contoso-DC1 qui échoue avec l’accès à la réplication a été refusé est indiqué ci-dessous :

    Default-First-Site-Name\CONTOSO-DC1
    Options DSA : IS_GC
    Options de site : (aucune)
    GUID de l’objet DSA : b6dc8589-7e00-4A5D-b688-045aef63ec01
    Invocation DSA : b6dc8589-7e00-4A5D-b688-045aef63ec01

    = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

    DC = contoso, DC = com
    Default-First-Site-Name\CONTOSO-DC2 via RPC
    GUID de l’objet DSA : 74fbe06c-932C-46b5-831b-af9e31f496b2
    La dernière tentative @ <date> <time> a échoué, résultat 5 (0x5) :
    L’accès est refusé.
    < # > défaillances consécutives.
    Dernière réussite @ <date> <time> .

  4. Les événements KCC NTDS, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService dont l’État est 5 sont consignés dans le journal des événements du service d’annuaire.

    Les événements Active Directory qui citent communément l’État 8524 incluent notamment :

    Événement Source Chaîne d’événement
    NTDS général 1655 Active Directory a tenté de communiquer avec le catalogue global suivant et les tentatives ont échoué.
    KCC NTDS 1925 Échec de la tentative d’établissement d’un lien de réplication pour la partition d’annuaire inscriptible suivante.
    KCC NTDS 1926 Échec de la tentative d’établissement d’un lien de réplication vers une partition d’annuaire en lecture seule avec les paramètres suivants :
  5. La commande répliquer maintenant dans sites et services Active Directory renvoie l' accès refusé.

    Le fait de cliquer avec le bouton droit sur l’objet Connection à partir d’un contrôleur de site source et de choisir répliquer maintenant échoue avec l’accès refusé. Le texte et la capture d’écran du message d’erreur à l’écran sont présentés ci-dessous :

  6. 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 d’appellation <% nom de partition d’annuaire% > du contrôleur de domaine <Source DC> au contrôleur de domaine <Destination DC> : l’accès est refusé

    L’opération ne se poursuit pas.

    Boutons de la boîte de dialogue : OK

    Répliquer maintenant

Cause

Causes racines valides pour l’erreur 5 : l’accès est refusé :

  1. Le paramètre RestrictRemoteClients dans le registre a une valeur de 2.
  2. Le droit d’utilisateur accéder à cet ordinateur à partir du réseau n’est pas accordé au groupe de contrôleurs de domaine de l’entreprise ou à l’administrateur déclenchant une réplication immédiate.
  3. Le paramètre CrashonAuditFail dans le Registre du contrôleur de périphérique de destination a une valeur de 2.
  4. Il existe une différence de temps entre le KDC utilisé par le contrôleur de domaine de destination et le contrôleur de domaine source qui dépasse la limite de temps maximale autorisée par Kerberos définie dans la stratégie de domaine par défaut.
  5. Il y a une incompatibilité de signature SMB entre les contrôleurs de compte source et de destination.
  6. Il y a une incompatibilité LMCompatiblity entre les contrôleurs de compte source et de destination.
  7. Les noms principaux de service ne sont pas enregistrés ou ne sont pas présents en raison d’une latence de réplication simple ou d’un échec de réplication.
  8. Les paquets Kerberos au format UDP sont fragmentés par les périphériques de l’infrastructure réseau, tels que les routeurs et les commutateurs.
  9. Le canal sécurisé sur le DC source ou de destination n’est pas valide.
  10. Les relations d’approbation de la chaîne d’approbation sont rompues ou non valides.
  11. Le paramètre KDCNames dans la HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains section du registre contient de manière incorrecte le nom de domaine Active Directory local.
  12. Certaines cartes réseau ont une fonctionnalité de déchargement d’envoi importante qui a été connue pour provoquer ce problème.
  13. Un logiciel antivirus qui utilise un pilote de filtre de carte réseau mini-pare-feu sur le contrôleur de réseau source ou de destination a été identifié comme étant à l’origine du problème.

Des erreurs et des événements Active Directory comme ceux cités dans la section symptômes de cette base de connaissances peuvent également échouer avec l’erreur 8453 avec une chaîne d’erreur similaire l’accès de réplication a été refusé. Les causes de cause première suivantes peuvent provoquer l’échec des opérations AD avec le 8453 : l' accès à la réplication a été refusé mais ne provoque pas d’échecs avec l’erreur 5 : la réplication est refusée:

  1. La tête CN n’est pas autorisée avec l’autorisation changes Directory changes .
  2. Le principal de sécurité qui initie la réplication n’est pas membre d’un groupe qui a été autorisé à répliquer les modificationsde l’annuaire.
  3. Indicateurs manquants dans l' UserAccountControl attribut, y compris SERVER_TRUST_ACCOUNT et TRUSTED_FOR_DELEGATION .
  4. Contrôleur de domaine en lecture seule promu domaine sans s’exécuter ADPREP /RODCPREP .

Résolution

L’échec de la réplication AD avec l’erreur 5 a plusieurs causes racines. Attaquez le problème à l’aide des outils tels que DCDIAG DCDIAG /TEST : CHECKSECURITYERROR et Netdiag qui exposent des problèmes courants. Si ce n’est toujours pas le cas, parcourez la liste des causes connues dans le plus courant, le moins complexe, l’ordre le moins fréquent et le moins complexe, le plus complexe et l’ordre d’interruption le plus élevé.

Exécuter DCDIAG, DCDIAG/TEST : CheckSecurityError et Netdiag

La DCDIAG générique exécute plusieurs tests

DCDIAG/TEST : CheckSecurityErrors a été écrit pour effectuer des tests spécifiques (notamment une vérification de l’inscription SPN) pour résoudre les problèmes liés à l’échec de la réplication des opérations Active Directory avec l’erreur 5 : l’accès est refusé et l’erreur 8453 : l’accès à la réplication a été refusé mais n’est pas exécuté dans le cadre de l’exécution par défaut de Dcdiag.

  1. Exécuter DCDIAG sur le contrôleur de destination
  2. Exécuter DCDIAG/TEST : CheckSecurityError
  3. Exécuter Netdiag
  4. Résoudre les éventuelles défaillances identifiées par DCDIAG et Netdiag. Réessayez l’opération de réplication précédemment en échec. Si le problème persiste, passez à la longue.

La solution

  1. RestrictRemoteClients la valeur est définie sur 2

    Cette valeur RestrictRemoteClients de Registre est définie sur la valeur 0X2 dans HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC .

    Pour résoudre ce :

    1. Désactivez la stratégie qui applique ce paramètre.

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

      Pour plus d’informations sur ce paramètre, reportez-vous à la clé de Registre RestrictRemoteClients est activée.

      La RestrictRemoteClients valeur de Registre est définie par le paramètre de stratégie de groupe suivant :

      Configuration de l' ordinateur > Modèles > d’administration Système > Appel de procédure distante - Restrictions pour les clients RPC non authentifiés

      Une valeur de Registre 0X2 est appliquée si le paramètre de stratégie est activé et défini sur authentifié sans exceptions.

      Cette option permet uniquement aux clients RPC authentifiés de se connecter aux serveurs RPC s’exécutant sur l’ordinateur sur lequel le paramètre de stratégie est appliqué ; Il n’autorise pas les 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.

  2. Consultez la case à cocher accéder à cet ordinateur à partir du réseau .

    Dans une installation par défaut de Windows, la stratégie de contrôleurs de domaine par défaut est liée à l’unité d’organisation des contrôleurs de domaine qui accorde le droit d’utilisateur accéder à cet ordinateur à partir du réseau aux groupes de sécurité suivants :

    Stratégie locale Stratégie des contrôleurs 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 pré-Windows 2000] [Accès compatible pré-Windows 2000]

    En cas d’échec des opérations Active Directory avec l’erreur 5 : l’accès est refusé, vérifiez les éléments suivants :

    • Les groupes de sécurité de la liste ci-dessus disposent du droit accéder à cet ordinateur à partir du réseau dans la stratégie de contrôleurs de domaine par défaut.
    • Les comptes d’ordinateur de contrôleur de domaine sont situés dans l’unité d’organisation des contrôleurs de domaine.
    • La stratégie de contrôleurs de domaine par défaut est liée aux comptes d’ordinateur ou aux unités d’organisation secondaires hébergeant des ordinateurs.
    • La stratégie de groupe s’applique sur le contrôleur de domaine de destination en cours de journalisation de l’erreur 5.
    • Refuser l’accès à cet ordinateur à partir du réseau le droit d’utilisateur n’a pas été activé ou ne fait pas référence à des groupes ayant échoué, directs ou imbriqués.
    • La priorité de stratégie, l’héritage bloqué, le filtrage WMI, ou similaire, n’empêche pas le paramètre de stratégie de s’appliquer aux ordinateurs du rôle DC.

    Les paramètres de stratégie peuvent être validés avec RSOP. MSC GPRESULT /Z , mais il s’agit de l’outil par défaut, car il est plus précis.

    Notes

    La stratégie locale a priorité sur la stratégie définie dans sites, domaines et OU.

    Notes

    À un moment donné, il était courant pour les administrateurs de supprimer les groupes contrôleur de domaine de l’entreprise et tout le monde du droit accéder à cet ordinateur à partir du réseau dans la stratégie de contrôleurs de domaine par défaut. La suppression des deux est irrécupérable. Il n’y a aucune raison de supprimer des contrôleurs de domaine d’entreprise de ce droit, car seuls les contrôleurs de domaine sont membres de ce groupe.

  3. CrashOnAuditFail = n°2

    La réplication AD échoue lorsque HKLM\System\CurrentControlSet\Control\LSA\CrashOnAuditFail = a la valeur 2,

    Une CrashOnAduitFail valeur de 2 est déclenchée lorsque le paramètre système d’audit : arrêter immédiatement s’il n’est pas possible de consigner les audits de sécurité dans la stratégie de groupe a été activé et que le journal des événements de sécurité local est saturé.

    Les contrôleurs de domaine Active Directory sont particulièrement susceptibles d’avoir des journaux de sécurité de capacité maximale lorsque l’audit a été activé et que la taille du journal des événements de sécurité a été limitée par les options ne pas remplacer les événements (vider manuellement le journal) ou remplacer si nécessaire dans l’observateur d’événements ou les équivalents de la stratégie de groupe.

    Action de l’utilisateur :

    Si HKLM\System\CCS\Control\LSA\CrashOnAuditFail = 2:

    • Effacement du journal des événements de sécurité (enregistrer dans un autre emplacement, comme requis)
    • Ré-evalaute toutes les contraintes de taille dans le journal des événements de sécurité, y compris les paramètres basés sur la stratégie.
    • Recréer CrashOnAuditFail (REG_DWORD) = 1
    • Lancer

    CrashOnAuditFailSi vous voyez une valeur de 0 ou 1, certains ingénieurs CSS ont résolu l’accès, les erreurs sont refusées en effaçant le journal des événements de sécurité, en supprimant la the CrashOnAuditFail valeur de Registre et en redémarrant le contrôleur de destination.

    Contenu connexe : gérer le journal d’audit et de sécurité.

  4. Décalage de temps excessif

    Les paramètres de stratégie Kerberos dans la stratégie de domaine par défaut autorisent une différence de 5 minutes (valeur par défaut) entre les contrôleurs de domaine du centre de distribution de clés (KDC) et un serveur cible Kerberos afin d’empêcher les attaques de relecture. Une partie de la documentation indique que le délai entre le client et la cible Kerberos doit être de 5 minutes les uns des autres. D’autres États indiquent que dans le contexte de l’authentification Kerberos, le temps qui est important est le différentiel entre le KDC utilisé par l’appelant et l’heure sur la cible Kerberos. De même, Kerberos ne s’occupe pas que l’heure du système sur le contrôleur de domaine approprié correspond à l’heure actuelle, mais seulement la différence de temps relative entre le KDC et le contrôleur de domaine cible est comprise dans la valeur maximale (par défaut 5 minutes ou moins) autorisée par la stratégie Kerberos.

    Dans le contexte des opérations Active Directory, le serveur cible est le DC source contacté par le contrôleur de destination. Chaque contrôleur de domaine dans une forêt Active Directory (qui exécute actuellement le service KDC) est un KDC potentiel, de sorte que vous devez prendre en compte la précision du temps sur tous les autres contrôleurs de domaine par rapport au contrôleur de domaine source, y compris l’heure sur le contrôleur de domaine de destination lui-même.

    Deux méthodes de vérification de la précision des heures incluent

    C:\> DCDIAG /TEST: CheckSecurityError
    

    AND

    C:\> W32TM /MONITOR
    

    Recherchez les événements LSASRV 40960 sur le contrôleur de périphérique de destination au moment de la demande de réplication défectueuse qui cite un enregistrement CNAMe guidé du contrôleur de contexte source avec l’erreur étendue :

    0xc000133 : l’heure sur le contrôleur de domaine principal est différente de celle du contrôleur de domaine de sauvegarde ou du serveur membre, trop importante.

    Les suivis réseau capturant l’ordinateur de destination qui se connecte à un dossier partagé sur le contrôleur de site source (ainsi que d’autres opérations) peuvent afficher l’erreur à l’écran une erreur étendue s’est produite. Lorsqu’un suivi réseau indique :

    KerberosV5 : demande TGS > demande TGS du contrôleur de domaine source
    KerberosV5 : KRB_ERROR-KRB_AP_ERR_TKE_NVV (33) > réponse TGS où KRB_AP_ERR_TKE_NYV > correspond au ticket non encore valide

    La réponse TKE_NYV indique que la plage de dates sur le ticket TGS est plus récente que l’heure sur la cible, ce qui indique un décalage excessif.

    Notes

    W32TM /MONITOR vérifie uniquement le temps sur les contrôleurs de domaine dans le domaine des ordinateurs de test, de sorte que vous devez l’exécuter dans chaque domaine et comparer le temps écoulé entre les domaines.

    Notes

    Si l’heure système a été jugée inexacte, faites un effort pour déterminer pourquoi et ce qui peut être fait pour empêcher le temps incorrect de se faire avancer. Le contrôleur principal de domaine 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 de temps était-il en cours d’exécution ? Les ordinateurs de rôle DC sont-ils configurés pour utiliser la hiérarchie NT5DS sur l’heure source ?

    Notes

    Lorsque la différence de temps est trop grande sur les contrôleurs de contrôleur de destination Windows Server 2008 R2, la commande répliquer maintenant dans DSSITE. MSC échoue avec l’erreur à l’écran il y a une différence de temps et/ou de date entre le client et le serveur. Cette chaîne d’erreur correspond à l’erreur 1398 décimal/0x576 hex avec le nom d’erreur symbolique ERROR_TIME_SKEW.

    Contenu associé : définition de la tolérance de synchronisation des horloges pour empêcher les attaques de relecture.

  5. Incompatibilité de signature SMB

    La matrice de compatibilité optimale 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 du Registre
    Client réseau Microsoft : communications signées numériquement (si le serveur l’accepte) HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
    Client réseau Microsoft : communications signées numériquement (toujours) HKLM\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
    Serveur réseau Microsoft : communications signées numériquement (si le serveur l’accepte) HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
    Serveur réseau Microsoft : communications signées numériquement (toujours) HKLM\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature

    Concentrez-vous sur les correspondances de signature SMB entre les contrôleurs de domaine de destination et source, les cas classiques étant le paramètre activé ou requis sur un côté, mais désactivé sur l’autre.

    Notes

    Les tests internes ont montré des incohérences de signature SMB provoquant l’échec de la réplication avec l’erreur 1722 : le serveur RPC n’est pas disponible.

  6. Fragmentation des paquets Kerberos mis en forme UDP

    Les routeurs et commutateurs de réseau peuvent fragmenter ou supprimer complètement des paquets réseau au format UDP volumineux utilisés par Kerberos et EDNS0 (DNS). Les ordinateurs exécutant des familles de systèmes d’exploitation Windows 2000 et Windows 2003 sont vulnérables à la fragmentation UDP par rapport aux ordinateurs exécutant Windows Server 2008 et 2008 R2.

    Action de l’utilisateur :

    • À partir de la console du DC de destination, exécutez une commande ping sur le contrôleur de réseau source en indiquant son nom d’ordinateur complet pour identifier le plus grand paquet pris en charge par l’itinéraire réseau.

      c:\> Ping <source DC hostname.>. <fully qualified computer name> -f -l 1472
      
    • Si le plus grand paquet non fragmenté est inférieur à 1 472 octets, (dans l’ordre de préférence)

      • Modifiez votre infrastructure réseau afin de prendre en charge correctement les cadres UDP volumineux. Cela peut nécessiter une mise à niveau du microprogramme ou une modification de configuration sur les routeurs, les commutateurs ou les pare-feu.

        OR

      • Définissez MaxPacketSize (sur le contrôleur de site de destination) sur le plus grand paquet identifié par la commande PING-f-l moins 8 octets pour tenir compte de l’en-tête TCP et redémarrer le contrôleur de jeu modifié.

        OR

      • Définissez MaxPacketSize (sur le contrôleur de destination) sur une valeur de « 1 » qui déclenche l’utilisation d’un TCP par Kerberos. Redémarrez le contrôleur de périphérique modifié pour que la modification prenne effet.

Nouvelle tentative de l’opération Active Directory qui a échoué

  1. Canal sécurisé/incompatibilité de mot de passe non valide

    Validez le canal sécurisé avec nltest /sc: query ou netdom verify .

    Pour plus d’informations sur la réinitialisation du mot de passe du contrôleur de domaine de destination avec NETDOM / RESETPWD , voir comment utiliser Netdom.exe pour réinitialiser les mots de passe de compte d’ordinateur d’un contrôleur de domaine Windows Server.

    Action de l’utilisateur :

    • Désactivez le service KDC sur le contrôleur de domaine en cours de réamorçage.

    • À partir de la console du contrôleur de destination, exécutez NETDOM RESETPWD pour réinitialiser le mot de passe du contrôleur de périphérique de destination :

      c:\>netdom resetpwd /server: server_name /userd: domain_name \administrator /passwordd: administrator_password
      
    • Assurez-vous que les KDC et le contrôleur de domaine source (si dans le même domaine) sont susceptibles de répliquer les informations sur le nouveau mot de passe des DC de destination.

    • Redémarrez le contrôleur de destination pour vider les tickets Kerberos et recommencez l’opération de réplication.

  2. Approbation non valide

    Si la réplication AD échoue entre les contrôleurs de domaine de différents domaines, vérifiez l’intégrité des relations d’approbation le long du chemin d’approbation.

    Dans la mesure du possible, utilisez le test de relation d’approbation Netdiag pour vérifier les approbations rompues. Netdiag identifie les approbations rompues avec le texte suivant :

    Test de relation d’approbation. . . . . . : Échec du test pour s’assurer que DomainSid de domaine <domainname> est correct. Erreurs Le canal sécurisé vers le domaine <domainname> est rompu. [<% code d’état de variable% >]

    Par exemple, si vous avez une forêt à domaines multiples contenant un domaine racine Contoso.COM , un domaine enfant, un domaine B.Contoso.COM enfant général C.B.Contoso.COM et un domaine d’arborescence dans une même forêt Fabrikam.COM où la réplication échoue entre les contrôleurs de domaine et le domaine d' C.B.Contoso.COM arborescence général, vérifiez l’intégrité de l' Fabrikam.COM approbation entre C.B.Contoso.COM et, puis B.Contoso.COM B.Contoso.COM Contoso.COM enfin Contoso.COM Fabrikam.COM .

    S’il existe une approbation courte entre les domaines de destination, il n’est pas nécessaire de valider la chaîne de chemin d’approbation. Au lieu de cela, validez l’approbation courte entre le domaine de destination et le domaine source.

    Vérifier les modifications de mot de passe récentes apportées à l’approbation avec l' Repadmin /showobjmeta * \<DN path for TDO in question> objet de domaine approuvé (TDO) Vérifiez que le contrôleur de domaine de destination est en transit entrant de manière transitant la partition d’annuaire de domaine accessible en écriture pour laquelle des modifications de mot de passe d’approbation peuvent avoir lieu

    Commandes permettant de réinitialiser les approbations :

    • À partir du contrôleur principal de domaine racine :

      netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay
      
    • À partir du contrôleur principal de domaine enfant :

      netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root/PasswordD:*/UserO:Child /PasswordO:* /Reset /TwoWay
      
  3. Domaine Kerberos non valide-PolAcDmN/PolPrDmN (pas de repro lors de l’article écrit)

    Copié à partir du contrôleur de domaine ne fonctionne pas correctement.

    1. Démarrez l’Éditeur du Registre.
    2. Dans le volet gauche, développez sécurité.
    3. Dans le menu sécurité , sélectionnez autorisations pour accorder au groupe local Administrateurs le contrôle total de la ruche de sécurité et de ses conteneurs et objets enfants.
    4. Recherchez la HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN clé.
    5. Dans le volet droit de l’éditeur du Registre, sélectionnez l’entrée ** <No Name> : REG_NONE** une fois.
    6. Dans le menu affichage , sélectionnez afficher les données binaires. Dans la section format de la boîte de dialogue, sélectionnez Byte.
    7. Le nom de domaine apparaît sous la forme d’une 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. Localisez la HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN clé de registre.
    9. Dans le volet droit de l’éditeur du Registre, double-cliquez sur l’entrée ** <No Name> : REG_NONE** .
    10. Dans la boîte de dialogue Éditeur binaire , collez la valeur de PolPrDmN. (La valeur de PolPrDmN sera le nom de domaine NetBIOS).
    11. Redémarrez le contrôleur de domaine.
  4. Domaine Kerberos non valide-KdcNames

    Action de l’utilisateur :

    • Sur la console du contrôleur de destination, exécutez REGEDIT.
    • Recherchez le chemin d’accès suivant dans le registre : HKLM\system\ccs\control\lsa\kerberos\domains .
    • Pour chacun d’eux <fully qualified domain> sous HKLM\system\ccs\control\lsa\kerberos\domains , vérifiez que la valeur de KdcNames fait référence à un domaine Kerberos externe valide et non au domaine local ou à un autre domaine de la même forêt Active Directory.
  5. Cartes réseau avec le déchargement d’envoi IPv4 volumineux activé :

    Action de l’utilisateur :

    • Ouvrez les propriétés de la carte réseau .
    • Sélectionnez le bouton configurer .
    • Sélectionnez l’onglet avancé .
    • Désactivez le déchargement important d’envoi IPv4.
    • Lancer.