Le contrôleur de domaine ne fonctionne pas correctement

Cet article fournit des solutions courantes au problème selon lequel le contrôleur de domaine ne fonctionne pas correctement.

S’applique à : Windows Server 2012 R2
Numéro de l’article d’origine dans la base de connaissances : 837513

Symptômes

Quand vous exécutez l’outil Dcdiag sur un contrôleur de domaine Microsoft Windows 2000 Server ou Windows Server 2003, le message d’erreur suivant peut s’afficher :

Diagnostic du contrôleur de domaine
Exécution de l’installation initiale :
[DC1] La liaison LDAP a échoué avec l’erreur 31

Quand vous utilisez l’utilitaire REPADMIN /SHOWREPS en local sur un contrôleur de domaine, l’un des messages d’erreur ci-dessous peut s’afficher :

[D:\nt\private\ds\src\util\repadmin\repinfo.c, 389] Erreur LDAP 82 (Erreur locale).

La dernière tentative le aaaa-mm-jj hh:mm.ss a échoué, résultat 1753 : Le mappeur de point final n’a plus de point final disponible.

La dernière tentative le aaaa-mm-jj hh:mm.ss a échoué, résultat 5 : Accès refusé.

Si vous utilisez l’utilitaire Sites et services Active Directory pour déclencher la réplication, un message indiquant que l’accès est refusé peut s’afficher.

Quand vous essayez d’utiliser des ressources réseau à partir de la console d’un contrôleur de domaine affecté, y compris des ressources UNC (Universal Naming Convention) ou des lecteurs réseau mappés, le message d’erreur ci-dessous peut s’afficher :

Aucun serveur d’accès disponible (c000005e = "STATUS_NO_LOGON_SERVERS")

Si vous démarrez des outils d’administration Active Directory à partir de la console d’un contrôleur de domaine affecté, y compris Sites et services Active Directory et Utilisateurs et ordinateurs Active Directory, l’un des messages d’erreur ci-dessous peut s’afficher :

Les informations de nom ne peuvent pas être trouvées car : Aucune autorité n’a pu être contactée pour l’authentification. Contactez votre administrateur système pour vérifier que le domaine est correctement configuré et qu’il est en ligne.

Les informations de nom ne peuvent pas être trouvées car : Le nom du compte cible est incorrect. Contactez votre administrateur système pour vérifier que le domaine est correctement configuré et qu’il est en ligne.

Les clients Microsoft Outlook connectés à des ordinateurs Microsoft Exchange Server qui utilisent des contrôleurs de domaine affectés à des fins d’authentification peuvent être invités à entrer des informations d’identification d’ouverture de session, même si l’authentification de connexion a réussi à partir d’autres contrôleurs de domaine.

L’outil Netdiag peut afficher les messages d’erreur suivants :

DC list test. . . . . . . . . . . : Failed
[AVERTISSEMENT] Impossible d’appeler DsBind vers <NomServeur>.<fqdn> (<adresse IP>). [ERROR_DOMAIN_CONTROLLER_NOT_FOUND]
Kerberos test. . . . . . . . . . . : Failed
[FATAL] Kerberos n’a pas de ticket pour krbtgt/<fqdn>.

[FATAL] Kerberos n’a pas de ticket pour <Nom d’hôte>.
LDAP test. . . . . . . . . . . . . : Passed
[AVERTISSEMENT] Échec de l’interrogation de l’inscription du nom SPN sur le contrôleur de domaine <Nom d’hôte><fqdn>

L’événement suivant peut être consigné dans le journal des événements système du contrôleur de domaine affecté :

Event Type: Error
Event Source: Service Control Manager
Event ID: 7023
Description: The Kerberos Key Distribution Center service terminated with the following error: The security account manager (SAM) or local security authority (LSA) server was in the wrong state to perform the security operation.

Résolution

Plusieurs résolutions sont possibles pour ces symptômes. Voici une liste de méthodes à essayer. Cette liste est suivie des étapes à effectuer pour chaque méthode. Essayez chaque méthode jusqu’à ce que le problème soit résolu. Les articles de la Base de connaissances Microsoft qui décrivent des correctifs moins courants pour ces symptômes sont répertoriés en fin d’article.

1. Méthode 1 : Corriger les erreurs DNS (Domain Name System).
2. Méthode 2 : Synchroniser l’heure entre les ordinateurs.
3. Méthode 3 : Vérifier les droits d’utilisateur Accéder à cet ordinateur à partir du réseau.
4. Méthode 4 : Vérifier que l’attribut userAccountControl du contrôleur de domaine est 532480.
5. Méthode 5 : Corriger le domaine Kerberos (vérifier que les clés de Registre PolAcDmN et PolPrDmN correspondent).
6. Méthode 6 : Réinitialiser le mot de passe du compte d’ordinateur, puis obtenir un nouveau ticket Kerberos.

Méthode 1 : Corriger les erreurs DNS

1. Dans une invite de commandes, exécutez la commande netdiag -v. Cette commande crée un fichier Netdiag.log dans le dossier où la commande a été exécutée.
2. Résolvez les erreurs DNS éventuelles dans le fichier Netdiag.log avant de continuer. L’outil Netdiag se trouve dans les outils de support de Windows 2000 Server inclus sur le CD-ROM de Windows 2000 Server ou est disponible au téléchargement.
3. Assurez-vous que le système DNS est configuré correctement. L’une des erreurs DNS les plus courantes consiste à pointer le contrôleur de domaine vers un fournisseur de services Internet (ISP) pour DNS au lieu de pointer le système DNS vers lui-même ou vers un autre serveur DNS qui prend en charge les mises à jour dynamiques et les enregistrements SRV. Il est recommandé de pointer le contrôleur de domaine vers lui-même ou vers un autre serveur DNS qui prend en charge les mises à jour dynamiques et les enregistrements SRV. Il est également recommandé de configurer des redirecteurs vers le fournisseur de services Internet pour la résolution de noms sur Internet.

Pour plus d’informations sur la configuration du système DNS pour le service d’annuaire Active Directory, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
254680 Planification de l’espace de noms DNS

Méthode 2 : Synchroniser l’heure entre les ordinateurs

Vérifiez que l’heure est correctement synchronisée entre les contrôleurs de domaine, ainsi qu’entre les ordinateurs clients et les contrôleurs de domaine.

Méthode 3 : Vérifier les droits d’utilisateur « Accéder à cet ordinateur à partir du réseau »

Modifiez le fichier Gpttmpl.inf pour vérifier que les utilisateurs appropriés disposent des droits d’utilisateur Accéder à cet ordinateur à partir du réseau sur le contrôleur de domaine. Pour cela, procédez comme suit :

1. Modifiez le fichier Gpttmpl.inf pour la stratégie des contrôleurs de domaine par défaut. Par défaut, la stratégie par défaut des contrôleurs de domaine est l’endroit où les droits des utilisateur sont définis pour un contrôleur de domaine. Par défaut, le fichier Gpttmpl.inf de la stratégie par défaut des contrôleurs de domaine se trouve dans le dossier suivant.

   Remarque

   Sysvol peut se trouver à un autre endroit, mais le chemin d’accès au fichier Gpttmpl.inf sera le même.

   Pour les contrôleurs de domaine Windows Server 2003 :

   C:\WINDOWS\Sysvol\Sysvol\<NomDomaine>\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

   Pour les contrôleurs de domaine Windows 2000 Server :

   C:\WINNT\Sysvol\Sysvol\<NomDomaine>\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf

2. À droite de l’entrée SeNetworkLogonRight, ajoutez les identifiants de sécurité pour les administrateurs, pour les utilisateurs authentifiés et pour tout le monde. Reportez-vous aux exemples suivants.

   Pour les contrôleurs de domaine Windows Server 2003 :

   SeNetworkLogonRight = *S-1-5-32-554,*S-1-5-9,*S-1-5-32-544,*S-1-1-0

   Pour les contrôleurs de domaine Windows 2000 Server :

   SeNetworkLogonRight = *S-1-5-11,*S-1-5-32-544,*S-1-1-0

   Remarque

   Les administrateurs (S-1-5-32-544), les utilisateurs authentifiés (S-1-5-11), tout le monde (S-1-1-0) et les contrôleurs d’entreprise (S-1-5-9) utilisent des identifiants de sécurité bien connus qui sont les mêmes dans tous les domaines.

3. Supprimez toutes les entrées à droite de l’entrée SeDenyNetworkLogonRight (refuser l’accès à cet ordinateur depuis le réseau) pour qu’elles correspondent à l’exemple suivant.

   SeDenyNetworkLogonRight =

   Remarque

   L’exemple est le même pour Windows 2000 Server et pour Windows Server 2003.

   Par défaut, Windows 2000 Server n’a aucune entrée dans l’entrée SeDenyNetworkLogonRight. Par défaut, Windows Server 2003 n’a que le compte de chaîne Support_random dans l’entrée SeDenyNetworkLogonRight. (Le compte de chaîne Support_random est utilisé par l’assistance à distance) Comme le compte de chaîne Support_random utilise un identificateur de sécurité (SID) différent dans chaque domaine, on peut facilement le confondre avec un compte d’utilisateur classique si l’on se fie simplement à l’identificateur de sécurité. Vous pouvez copier l’identificateur de sécurité dans un autre fichier texte, puis le supprimer de l’entrée SeDenyNetworkLogonRight. Ainsi, vous pourrez le remettre en place lorsque vous aurez fini de résoudre le problème.

   SeNetworkLogonRight et SeDenyNetworkLogonRight peuvent être définis dans n’importe quelle stratégie. Si les étapes précédentes ne permettent pas de résoudre le problème, vérifiez le fichier Gpttmpl.inf dans d’autres stratégies de Sysvol pour confirmer que les droits de l’utilisateur n’y sont pas également définis. Si un fichier Gpttmpl.inf ne contient aucune référence à SeNetworkLogonRight ou SeDenyNetworkLogonRight, ces paramètres ne sont pas définis dans la stratégie et cette dernière n’est pas à l’origine de ce problème. Si ces entrées existent, assurez-vous qu’elles correspondent aux paramètres répertoriés précédemment pour la stratégie par défaut des contrôleurs de domaine.

Méthode 4 : vérifier que l’attribut userAccountControl du contrôleur de domaine est 532480

1. Cliquez sur Démarrer, puis sur Exécuter et saisissez adsiedit.msc.
2. Développez les objets suivants : Domain NC, puis DC=domain et enfin OU=Domain Controllers.
3. Cliquez avec le bouton droit sur le contrôleur de domaine affecté, puis sélectionnez Propriétés.
4. Sous Windows Server 2003, activez les cases Afficher les attributs obligatoires et Afficher les attributs facultatifs sous l’onglet Éditeur d’attributs. Sous Windows 2000 Server, cliquez sur Les deux dans la zone Sélectionner les propriétés à afficher.
5. Sous Windows Server 2003, cliquez sur userAccountControl dans la zone Attributs. Sous Windows 2000 Server, cliquez sur userAccountControl dans la zone Sélectionner une propriété à afficher.
6. Si la valeur n’est pas 532480, saisissez 532480 dans la zone Modifier l’attribut, puis cliquez sur Définir, sur Appliquer et sélectionnez OK.
7. Quittez Modification ADSI.

Méthode 5 : corriger le domaine Kerberos (vérifier que les clés de Registre PolAcDmN et PolPrDmN correspondent)

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 Autorisations pour accorder au groupe local des administrateurs le contrôle total de la ruche SECURITY et de ses conteneurs et objets enfants.
4. Recherchez la clé nommée HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN.
5. Dans le volet droit de l’Éditeur du Registre, cliquez une fois sur l’entrée No Name<> : REG_NONE.
6. Dans le menu Affichage, cliquez sur Affichage des données binaires. Dans la section Format de la boîte de dialogue, cliquez sur Octet.
7. Le nom de domaine apparaît sous forme de chaîne dans 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 clé de Registre HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN.
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 à partir de PolPrDmN sera le nom de domaine NetBIOS).
11. Redémarrez le contrôleur de domaine.

Méthode 6 : réinitialiser le mot de passe du compte ordinateur, puis obtenir un nouveau ticket Kerberos

1. Arrêtez le service Centre de distribution de clés Kerberos, puis réglez la valeur de démarrage sur Manuel.

2. Utilisez l’outil Netdom, à partir des outils de support de Windows 2000 Server ou Windows Server 2003, pour réinitialiser le mot de passe du compte ordinateur du contrôleur de domaine :

   netdom resetpwd /server: <another domain controller> /userd:domain\administrator /passwordd: <administrator password>  
   

   Assurez-vous que la netdom commande est retournée comme effectuée avec succès. Dans le cas contraire, la commande n’a pas fonctionné. Pour le domaine Contoso, où le contrôleur de domaine affecté est DC1 et un contrôleur de domaine fonctionnel est DC2, vous exécutez la commande suivante netdom depuis la console du DC1 :

   netdom resetpwd /server:DC2 /userd:contoso\administrator /passwordd: <administrator password>
   

3. Redémarrez le contrôleur de domaine affecté.

4. Démarrez le service Centre de distribution de clés Kerberos, puis réglez le paramètre de démarrage sur Automatique.

Pour plus d’informations sur ce problème, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
323542 Vous ne pouvez pas démarrer l’outil Utilisateurs et ordinateurs Active Directory, car le serveur n’est pas opérationnel