Erreur de réplication Active Directory-2146893022 : le nom de principal cible est incorrect

Cet article explique comment résoudre un problème dans lequel la réplication Active Directory échoue et génère une erreur (-2146893022 : le nom du principal cible est incorrect).

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

Notes

Utilisateurs à domicile : Cet article est destiné uniquement aux agents de support technique et aux professionnels de l’informatique. Si vous avez besoin d’aide pour résoudre un problème, Posez la question à la communauté Microsoft.

Résumé

Cette erreur se produit lorsque le contrôleur de domaine source ne déchiffre pas le ticket de service fourni par le contrôleur de domaine de destination (cible).

Cause principale

Le contrôleur de domaine de destination reçoit un ticket de service d’un centre de distribution de clés (KDC) Kerberos qui a une ancienne version du mot de passe pour le contrôleur de domaine source.

Résolution supérieure

  1. Arrêtez le service KDC sur le contrôleur de domaine de destination. Pour ce faire, exécutez la commande suivante à l’invite de commandes :

    net stop KDC
    
  2. Démarrez la réplication sur le contrôleur de domaine de destination à partir du contrôleur de domaine source à l’aide de sites et services Active Directory ou de repadmin.

    Utilisation de repadmin :

    Repadmin replicate destinationDC sourceDC DN_of_Domain_NC
    

    Par exemple, en cas d’échec de ContosoDC2.contoso.com la réplication, exécutez la commande suivante sur ContosoDC1.contoso.com :

    Repadmin replicate ContosoDC2.contoso.com ContosoDC1.contoso.com "DC=contoso,DC=com"
    
  3. Démarrez le service KDC Kerberos sur le contrôleur de domaine de destination. Pour ce faire, exécutez la commande suivante :

    net start KDC
    

Si cela ne résout pas le problème, reportez-vous à la section résolution pour une solution alternative dans laquelle vous utilisez la netdom resetpwd commande pour réinitialiser le mot de passe du compte d’ordinateur du contrôleur de domaine source. Si cette procédure ne résout pas le problème, consultez le reste de cet article.

Symptômes

Lorsque ce problème se produit, vous pouvez observer un ou plusieurs des symptômes suivants :

  • DCDIAG signale que le test de réplication Active Directory a échoué et renvoyé l’erreur-2146893022 : le nom de principal cible est incorrect.

    [Vérification des réplications, <DC Name> ] Une tentative de réplication récente a échoué :
    De <source DC> vers <destination DC>
    Contexte d’appellation : <DN path of directory partition>
    La réplication a généré une erreur (-2146893022) :
    Le nom de principal cible est incorrect.
    L’échec s’est produit à <date> <time> .
    La dernière réussite s’est produite à <date> <time> .
    <X> des échecs ont eu lieu depuis la dernière réussite.

  • Repadmin.exe signale qu’une tentative de réplication a échoué et signale l’état -2146893022 (0x80090322).

    Les commandes repadmin qui indiquent couramment l’état -2146893022 (0x80090322) sont les suivantes :

    • DMIN /REPLSUMREPA

    • REPADMIN /SHOWREPL

    • REPADMIN /SHOWREPL

    • REPADMIN /SYNCALL

      Exemple de sortie de REPADMIN /SHOWREPS et REPADMIN /SYNCALL indiquant que le nom principal de la cible est incorrect l’erreur est la suivante :

      c:\> repadmin /showreps  
      <site name>\<destination DC>
      DC Options: IS_GC
      Site Options: (none)
      DC object GUID: <NTDS settings object object GUID>
      DChttp://bemis/13/Pages/2090913_en-US.aspx invocationID: <invocation ID string>
      
      ==== INBOUND NEIGHBORS ======================================
      
      DC=<DN path for directory partition>
           <site name>\<source DC via RPC
               DC object GUID: <source DCs ntds settings object object guid>
               Last attempt @ <date> <time> failed, result -2146893022 (0x80090322):
      The target principal name is incorrect.
               <X #> consecutive failure(s).
               Last success @ <date> <time>.
      
      c:\> repadmin /syncall /Ade
      Syncing all NC's held on localhost.
      Syncing partition: DC=<Directory DN path>
      CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=<server name>,CN=Servers,CN=<site name>,CN=Sites,CN=Configuration,DC=<forest root domain> (network error): -2146893022 (0x80090322):
      
  • La commande répliquer maintenant dans sites et services Active Directory renvoie le nom du principal cible est un message incorrect .

    Le fait de cliquer avec le bouton droit sur l’objet Connection à partir d’un contrôleur de base de code source et de sélectionner répliquer maintenant échoue et renvoie le nom de principal cible message incorrect . Le message d’erreur à l’écran est le suivant :

    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 contact du contrôleur de domaine <source DC name> :
    Le nom de principal cible est incorrect
    Boutons de la boîte de dialogue : OK

  • Les événements KCC NTDS, NTDS General ou Microsoft-Windows-ActiveDirectory_DomainService ayant l’état -2146893022 sont consignés dans le journal des événements du service d’annuaire.

    Les événements Active Directory qui citent couramment l’état -2146893022 sont notamment les suivants :

    Source de l'événement ID d’évènement Chaîne d’événement
    Réplication NTDS 1586 Le point de contrôle de réplication Windows NT 4,0 ou version antérieure avec le maître émulateur PDC n’a pas réussi.

    Une synchronisation complète de la base de données du gestionnaire de comptes de sécurité (SAM) vers les contrôleurs de domaine exécutant Windows NT 4,0 et version antérieure peut avoir lieu si le rôle de maître d’émulateur PDC est transféré vers le contrôleur de domaine local avant le prochain point de contrôle réussi.
    KCC NTDS 1925 Échec de la tentative d’établissement d’un lien de réplication pour la partition d’annuaire inscriptible suivante.
    KCC NTDS 1308 Le vérificateur de cohérence des connaissances (KCC) a détecté que les tentatives successives de réplication avec le contrôleur de domaine suivant ont échoué.
    Microsoft-Windows-ActiveDirectory_DomainService 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 :
    Messagerie inter-site NTDS 1373 Le service de messagerie intersite n’a pas pu recevoir de messages pour le service suivant via le transport suivant. Échec de la requête pour les messages.

Cause

Le code d’erreur -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL n’est pas une erreur Active Directory, mais peut être renvoyé par les composants de couche inférieurs, y compris RPC, Kerberos, SSL, LSA et NTLM pour différentes causes racines.

Les erreurs Kerberos mappées par le code Windows à -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL sont les suivantes :

  • KRB_AP_ERR_MODIFIED (0x29 / 41 décimal / KRB_APP_ERR_MODIFIED)
  • KRB_AP_ERR_BADMATCH (0x24h / 36 décimal / "le ticket et l’authentificateur ne correspondent pas")
  • KRB_AP_ERR_NOT_US (0x23h / 35 décimal / « le ticket n’est pas pour nous »)

Des causes de racine spécifiques pour -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL sont les suivantes :

  • Un mappage de nom à IP incorrect dans le fichier DNS, WINS, HOST ou LMHOST a provoqué le contrôleur de domaine de destination à se connecter au mauvais contrôleur de domaine source dans un autre domaine Kerberos.

  • L’ordinateur cible Kerberos (contrôleur de domaine source) n’a pas pu déchiffrer les données d’authentification Kerberos envoyées par le client Kerberos (contrôleur de domaine de destination) car le KDC et le contrôleur de domaine source ont des versions différentes du mot de passe du compte d’ordinateur du contrôleur de domaine source.

  • Le KDC n’a pas pu trouver de domaine pour rechercher le SPN du contrôleur de domaine source.

  • Les données d’authentification des trames chiffrées Kerberos ont été modifiées par du matériel (y compris des périphériques réseau), un logiciel ou une personne malveillante.

Résolution

  • Exécution dcdiag /test:checksecurityerror sur le contrôleur de périphérique source

    Les SPN peuvent être manquants, non valides ou dupliqués en raison d’une latence de réplication simple, notamment après une promotion ou des échecs de réplication.

    Les SPN en double peuvent entraîner des mappages de noms SPN incorrects.

    DCDIAG /TEST:CheckSecurityError peut vérifier les noms principaux de principaux manquants ou en double, ainsi que d’autres erreurs.

    Exécutez cette commande sur la console de tous les contrôleurs de session source qui échouent la réplication sortante avec l’erreur SEC_E_WRONG_PRINCIPAL .

    Vous pouvez vérifier l’inscription SPN par rapport à un emplacement spécifique à l’aide de la syntaxe suivante :

    dcdiag /test:checksecurityerror replsource:<remote dc>
    
  • Vérifier que le trafic réseau chiffré Kerberos a atteint la cible Kerberos cible (mappage de nom à IP)

    Prenons l’exemple du scénario suivant :

    • La réplication entrante des contrôleurs de domaine de destination Active Directory recherche dans la copie locale du répertoire le GUID des objets des Paramètres NTDS des contrôleurs de domaine sources.

    • Les contrôleurs de domaine interrogent le serveur DNS actif pour un enregistrement CNAMe de contrôleur de domaine correspondant qui est ensuite mappé à un enregistrement A/AAAA hôte qui contient l’adresse IP du contrôleur de domaine source.

      Dans ce scénario, Active Directory exécute une résolution de nom de secours qui inclut les requêtes pour les noms d’ordinateur complets dans le DNS ou les noms d’hôtes en une seule partie dans WINS.

      Notes

      Les serveurs DNS peuvent également effectuer des recherches WINS dans des scénarios de secours.

Les objets Paramètres NTDS périmés, les mappages de nom à IP incorrects dans les enregistrements d’hôte DNS et WINS, et les entrées obsolètes dans les fichiers hôtes peuvent entraîner la soumission du trafic chiffré Kerberos à une cible Kerberos incorrecte.

Pour vérifier cette condition, prenez un suivi réseau ou vérifiez manuellement que les requêtes de nom DNS/NetBIOS de nom correspondent à l’ordinateur cible prévu.

Méthode 1 : méthode de suivi réseau (telle qu’analysée par le moniteur réseau 3.3.1641 en activant les analyseurs complets par défaut)

Le tableau suivant présente un Synopsis du trafic réseau qui se produit lorsque la destination DC1 entrante réplique l’annuaire Active Directory à partir de la source DC2.

P # SRC DEST Protocole Cadre Commentaire
0,1 DC1 DC2 MSRPC MSRPC : demande c/o : appel inconnu = 0x5 Opnum = 0x3 Context = 0x1 Conseil = 0X90 Appel RPC DC dest vers EPM sur le contrôleur de session de source sur 135
n°2 DC2 DC1 MSRPC MSRPC : réponse c/o : appel inconnu = 0x5 Context = 0x1 Hint = 0xF4 cancels = 0x0 Réponse EPM à l’appelant RPC
3 DC1 DC2 MSRPC MSRPC : liaison c/o : UUID {E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR (DRSR) Call = 0X2 Assoc GRP = 0x0 transmission = 0x16D0 recv = 0x16D0 Demande de liaison RPC vers E351... UUID de service
4 DC2 DC1 MSRPC MSRPC : accusé de réception c/o bind : Call = 0X2 Assoc GRP = 0x9E62, transmission = 0x16D0 recv = 0x16D0 Réponse de liaison RPC
DC1 CENTRES KerberosV5 KerberosV5 : domaine de demande TGS : CONTOSO.COM sName : E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso. com Demande TGS pour le SPN de réplication du contrôleur de service source. Cette opération n’apparaît pas sur le câble du contrôleur de domaine de destination utilise Self comme KDC.
CENTRES DC1 KerberosV5 KerberosV5 : réponse TGS CNAME : CONTOSO-DC1 $ Réponse TGS à destination DC contoso-DC1. Cette opération n’apparaît pas sur le câble du contrôleur de domaine de destination utilise Self comme KDC.
7j/7 DC1 DC2 MSRPC MSRPC : c/o ALTER CONT : UUID {E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR (DRSR) Call = 0X2 Demande AP
8bits DC2 DC1 MSRPC MSRPC : c/o ALTER CONT REEE : Call = 0X2 Assoc GRP = 0x9E62, transmission = 0x16D0 recv = 0x16D0 Réponse AP.
Descente sur le cadre 7 Descente sur le cadre 8 Commentaires
MSRPC MSRPC : c/o ALTER CONT : UUID {E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR (DRSR) Call = 0X2 MSRPC : c/o ALTER CONT REEE : Call = 0X2 Assoc GRP = 0xC3EA43, transmission = 0x16D0 recv = 0x16D0 DC1 se connecte au service de réplication AD sur DC2 sur le port renvoyé par l’EPM sur DC2.
IPv4 : SRC = x. x. x. 245, dest = x. x. x. 35, protocole suivant = TCP, ID de paquet =, longueur IP totale = 0 IPv4 : SRC = x. x. x. 35, dest = x. x. x. 245, protocole suivant = TCP, ID de paquet = 31546, longueur IP totale = 278 Vérifiez que le contrôleur de domaine de réplication AD (désigné ici comme ordinateur de destination dans la première colonne et ordinateur src dans la colonne 2) est propriétaire de l’adresse IP citée dans le suivi (x. x. x. 35 dans cet exemple).
Ticket : domaine : CONTOSO.COM , SNAME : E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso. com ErrorCode : KRB_AP_ERR_MODIFIED (41)

Domaine : <verify that realm returned by the source DC matches the Kerberos realm intended by the destination DC> .

SName : <verify that the sName in the AP response matches contains the hostname of the intended source DC and NOT another DC that the destination incorrectly resolved to due to a bad name-to-ip mapping problem> .
Dans la colonne 1, notez le domaine du domaine Kerberos cible, contoso.com suivi du nom principal de service de réplication DCS source (sName) qui se compose de l’UUID du service de réplication Active Directory (E351...) concaténé avec le GUID d’objet de l’objet Paramètres NTDS source DCS.

La valeur guidée 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2 à droite de E351... UUID du service de réplication est le GUID d’objet de l’objet Paramètres NTDS des contrôleurs de service (DCs) source actuellement défini dans la copie des DC de destination d’Active Directory. Vérifiez que le GUID de cet objet correspond à la valeur du champ GUID de l' objet DSA lorsque repadmin /showreps est exécuté à partir de la console du contrôleur de domaine source.

Une commande ping ou nslookup de la with_msdcs concaténée CNAMe Completed DCs.<forest root DNS name> à partir de la console du contrôleur de destination doit renvoyer l’adresse IP actuelle du contrôleur de contrôleur de base :

ping 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.contoso.com

nslookup -type=cname 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.<forest root domain> <DNS Server IP>

Dans la réponse indiquée dans la colonne 2, concentrez-vous sur le champ sName et vérifiez qu’il contient le nom d’hôte du contrôleur de domaine de la réplication AD.

Les mappages de nom à IP incorrects peuvent entraîner la connexion du contrôleur de domaine de destination à un contrôleur de domaine dans un domaine cible non valide, comme indiqué dans ce cas. Les mappages hôte-IP incorrects peuvent entraîner le fait que DC1 se connecte à DC3 dans le même domaine, ce qui génère toujours KRB_AP_ERR_MODIFIED mais que le nom de domaine dans le cadre 8 corresponde au domaine dans l’image 7.

Méthode 2 : vérification du mappage nom-IP (sans utiliser de suivi réseau)

À partir de la console du contrôleur de contexte source :

Command Commentaire
IPCONFIG /ALL |MORE Remarque adresse IP de la carte d’interface réseau utilisée par les DC de destination
REPADMIN /SHOWREPS |MORE Note valeur du GUID d’objet DSA qui indique le GUID de l’objet pour l’objet Paramètres NTDS des contrôleurs de source de contenu dans la copie DCs source d’Active Directory

À partir de la console du contrôleur de destination :

Command Commentaire
IPCONFIG /ALL |MORE Notez les serveurs DNS principaux, secondaires et tertiaires configurés par le contrôleur de domaine de destination pour les requêtes de recherche DNS.
REPADMIN /SHOWREPS |MORE Dans la section voisins entrants de la sortie repadmin, recherchez l’état de la réplication où le DC de destination réplique une partition commune à partir du contrôleur de contexte source en question.

Le GUID de l’objet DSA figurant dans la section statut de la réplication du rapport doit correspondre au GUID d’objet figurant dans l' /showreps en-tête lors de l’exécution sur la console du contrôleur de base de session.
IPCONFIG /FLUSHDNS Effacer le cache du client DNS
Démarrer > Exécuter > Bloc-notes
%systemroot%\system32\drivers\etc\hosts
Vérifiez si des mappages d’hôte à IP font référence à l’étiquette unique ou au nom DNS complet du contrôleur de domaine. Supprimez le cas échéant. Enregistrer les modifications apportées au fichier hôte.

Exécuter Nbtstat -R (majuscule R) pour actualiser le cache de noms NetBIOS.
NSLOOKUP -type=CNAME <object guid of source DCs NTDS Settings object>._msdcs.<forest root DNS name> <primary DNS Server IP>

Répétez l’opération pour chaque adresse IP de serveur DNS supplémentaire configurée sur le contrôleur de domaine de destination.

tels c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 152.45.42.103
Vérifiez que le protocole IP renvoyé correspond à l’adresse IP du contrôleur de contexte cible indiqué ci-dessus enregistré à partir de la console du contrôleur de contexte source.

Répétez l’opération pour tous les serveurs DNS IPs configurés sur le contrôleur de domaine de destination.
nslookup -type=A+AAAA <FQDN of source DC> <DNS Server IP> Recherchez les enregistrements d’hôte A dupliqués sur toutes les adresses IP du serveur DNS configurées sur le contrôleur de domaine de destination.
nbtstat -A <IP address of DNS Server IP returned by nslookup> Doit renvoyer le nom du contrôleur de périphérique source.

Notes

Une demande de réplication qui est dirigée vers un contrôleur n’appartenant pas au domaine (en raison d’un mappage nom-adresse IP incorrect) ou d’un contrôleur de domaine qui ne possède pas actuellement le E351... UUID de service enregistré avec le mappeur de point de terminaison renvoie l’erreur 1753 : il n’y a plus de points de terminaison disponibles avec le mappeur de point de terminaison.

La cible Kerberos ne peut pas déchiffrer les données Kerberos authentifiées en raison d’une incompatibilité de mot de passe

Cette condition peut se produire si le mot de passe du contrôleur de domaine source diffère entre le KDC et la copie du contrôleur de domaine source de l’annuaire Active Directory. La copie du contrôleur de domaine de destination du mot de passe du compte d’ordinateur du contrôleur de domaine source peut être périmée si elle n’est pas utilisée en tant que KDC.

Les échecs de réplication peuvent empêcher les contrôleurs de domaine d’avoir une valeur de mot de passe actuelle pour les contrôleurs de domaine dans un domaine donné.

Chaque contrôleur de domaine exécute le service KDC pour leur domaine. Pour les mêmes transactions de domaine, un contrôleur de domaine de destination favorise l’obtention de tickets Kerberos à partir de lui-même. Toutefois, il peut recevoir un ticket d’un contrôleur de domaine distant. Les références sont utilisées pour obtenir des tickets Kerberos à partir d’autres domaines.

La NLTEST /DSGETDC:<DNS domain of target domain> /kdc commande exécutée à partir d’une invite de commandes avec élévation de temps en fermant la proximité d’une SEC_E_WRONG_PRINCIPAL erreur peut être utilisée pour identifier rapidement le KDC qu’un client Kerberos cible.

La méthode définitive pour déterminer le contrôleur de domaine à partir duquel un client Kerberos a reçu un ticket est de suivre un suivi réseau. L’absence de trafic Kerberos dans un suivi réseau peut indiquer que le client Kerberos a déjà acquis des tickets, qu’il reçoit des tickets à travers lui-même ou que votre application de suivi réseau n’analyse pas correctement le trafic Kerberos.

Les tickets Kerberos pour le compte d’utilisateur connecté peuvent être purgés à partir d’une invite de commandes avec élévation de privilèges à l’aide de la KLIST purge commande.

Les tickets Kerberos pour le compte système qui sont utilisés par la réplication Active Directory peuvent être purgés sans redémarrage à l’aide de KLIST -li 0x3e7 purge .

Des contrôleurs de domaine peuvent être créés pour utiliser d’autres contrôleurs de domaine en arrêtant le service KDC sur un contrôleur de domaine local ou distant.

Utilisez REPADIN /SHOWOBJMETA pour vérifier les différences de numéros de version évidentes dans les attributs liés au mot de passe (dBCSPwd, UnicodePWD, NtPwdHistory, pwdLastSet, lmPwdHistory) pour le contrôleur de domaine source dans la copie du contrôleur de domaine source et du contrôleur de domaine de destination du répertoire Active Directory.

C:\>repadmin /showobjmeta <source DC> <DN path of source DC computer account>
C:\>repadmin /showobjmeta <KDC selected by destination DC> <DN path of source DC computer account>

La resetpwd /server:<DC to direct password change to> /userd:<user name> /passwordd:<password> commande Netdom exécutée à partir d’une invite de commandes avec élévation de privilèges sur la console du contrôleur de domaine qui requiert une réinitialisation de mot de passe peut être utilisée pour réinitialiser les mots de passe du compte d’ordinateur du contrôleur de domaine.

Dépannage de scénarios spécifiques

  • Étapes de reproduction pour un mappage hôte à IP incorrect entraînant l’extraction du contrôleur de domaine de destination d’une source incorrecte.

    1. Promouvez ** \ \ DC1 + \ \ DC2 + \ \ DC3** dans le contoso.com domaine. La réplication de bout en bout s’effectue sans erreur.

    2. Arrêtez le centre KDC sur \ \ DC1 et \ \ DC2 pour forcer le trafic Kerberos hors zone qui peut être observé dans un suivi réseau. La réplication de bout en bout s’effectue sans erreur.

    3. Créez une entrée de fichier hôte pour \ \ DC2 qui pointe vers l’adresse IP d’un contrôleur de domaine dans une forêt distante pour simuler un mappage hôte-IP incorrect dans un enregistrement a/aaaa hôte ou peut-être un objet Paramètres NTDS obsolète dans la copie du contrôleur de domaine de destination du répertoire Active Directory.

    4. Démarrez sites et services Active Directory sur la console de \ \ DC1. Cliquez avec le bouton droit sur l' ** \ \ objet de connexion entrante DC1** à partir de \ \ DC2 et notez que le nom du compte cible est une erreur de réplication incorrecte.

  • Étapes de reproduction pour une incompatibilité de mot de passe de contrôleur de domaine source entre KDC et le contrôleur de domaine source.

    1. Promouvez ** \ \ DC1 + \ \ DC2 + \ \ DC3** dans le contoso.com domaine. La réplication de bout en bout s’effectue sans erreur.

    2. Arrêtez le centre KDC sur \ \ DC1 et \ \ DC2 pour forcer le trafic Kerberos hors zone qui peut être observé dans le suivi du réseau. La réplication de bout en bout s’effectue sans erreur.

    3. Désactivation de la réplication entrante sur le centre KDC \ \ DC3 pour simuler un échec de réplication sur le KDC.

    4. Réinitialisez le mot de passe du compte d’ordinateur sur \ \ DC2 trois fois ou plus afin que \ \ DC1 et \ \ DC2 aient le mot de passe actuel pour \ \ DC2.

    5. Démarrez sites et services Active Directory sur la console de \ \ DC1. Cliquez avec le bouton droit sur \ \ l’objet de connexion entrante de DC1 à partir de \ \ DC2 et notez que le nom de compte cible est une erreur de réplication incorrecte.

  • Journalisation du client RPC DS

    Définissez NTDS\Diagnostics LOGGINGS\DS RPC client = 3. Déclenchez la réplication. Recherchez l’événement de catégorie de tâche 1962 + 1963. Notez l’enregistrement CNAME complet indiqué dans le champ service d’annuaire . Le contrôleur de domaine de destination doit être en mesure d’effectuer un test ping sur cet enregistrement et faire en sorte que l’adresse renvoyée soit mappée sur l’adresse IP actuelle du contrôleur de domaine source.

  • Flux de travail Kerberos

    Le flux de travail Kerberos comprend les actions suivantes :

    • L’ordinateur client appelle la fonction IntializeSecurityContext et spécifie le fournisseur SSP (Security Support Provider).

    • Le client contacte le KDC avec son TGT et demande un ticket TGS pour le contrôleur de domaine cible.

    • Le KDC recherche une source (E351 ou nom d’hôte) dans le catalogue global dans le domaine du contrôleur de domaine de destination.

    • Si le contrôleur de domaine cible se trouve dans le domaine du contrôleur de domaine de destination, le KDC fournit au client un ticket de service.

    • Si le contrôleur de domaine cible se trouve dans un autre domaine, le KDC fournit au client un ticket de référence.

    • Le client contacte un KDC dans le domaine du contrôleur de domaine cible et demande un ticket de service.

    • Si le nom principal de service du contrôleur de domaine source n’existe pas dans le domaine, vous recevez une erreur KDC_ERR_S_PRINCIPAL_UNKNOWN .

    • Le contrôleur de domaine de destination contacte la cible et présente son ticket.

    • Si le contrôleur de domaine cible est propriétaire du nom dans le ticket et peut le déchiffrer, l’authentification fonctionne.

    • Si le contrôleur de domaine cible héberge l’UUID du service de serveur RPC, le KRB_AP_ERR_NOT_US Kerberos sur connexion ou KRB_AP_ERR_MODIFIED erreur est remappée à la suivante :

      -2146893022 décimal/0x80090322/SEC_E_WRONG_PRINCIPAL/» le nom de principal de la cible est incorrect.