Les ID d’événements 5788 et 5789 se produisent sur un ordinateur Windows

  • Article

Cet article fournit des solutions à un problème où l’ID d’événement 5788 et l’ID d’événement 5789 sont enregistrés lorsque le nom de domaine DNS et le nom de domaine Active Directory diffèrent sur un ordinateur Windows.

Produits concernés : Windows 7 Service Pack 1, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 258503

Symptômes

Vous pouvez rencontrer l’un des problèmes suivants :

  • Sur Windows Vista et les versions ultérieures, vous recevez le message d’erreur suivant lors de l’ouverture de session interactive :

    La base de données de sécurité sur le serveur n’a pas de compte d’ordinateur pour cette relation d’approbation de station de travail.

  • Les connexions interactives avec des comptes basés sur un domaine ne fonctionnent pas. Seules les ouvertures de session avec des comptes locaux fonctionnent.

  • Les messages d’événement suivants sont enregistrés dans le journal système :

    Type d'événement : Erreur
    Source de l’événement : NETLOGON
    Catégorie d’événement : Aucun
    ID d’événement : 5788
    Ordinateur : ComputerName
    Description :
    Échec de la tentative de mise à jour du nom du principal du service (SPN) de l’objet ordinateur dans Active Directory. L’erreur suivante s’est produite : <Message d’erreur détaillé qui varie en fonction de la cause.>

    Type d'événement : Erreur
    Source de l’événement : NETLOGON
    Catégorie d’événement : Aucun
    ID d’événement : 5789
    Ordinateur : Ordinateur
    Description :
    Échec de la tentative de mise à jour du nom d’hôte DNS de l’objet ordinateur dans Active Directory. L’erreur suivante s’est produite : <Message d’erreur détaillé qui varie en fonction de la cause.>

    Remarque

    Les messages d’erreur détaillés pour ces événements sont répertoriés dans la section « Cause ».

Cause

Ce comportement se produit lorsqu’un ordinateur tente d’écrire dans les attributs dNSHostName et servicePrincipalName pour son compte d’ordinateur dans un domaine services de domaine Active Directory (AD DS).

Un ordinateur tente de mettre à jour ces attributs si les conditions suivantes sont remplies :

  • Immédiatement après qu’un ordinateur Windows a joint un domaine, l’ordinateur tente de définir les attributs dNSHostName et servicePrincipalName pour son compte d’ordinateur dans le nouveau domaine.
  • Lorsque le canal de sécurité est établi sur un ordinateur Windows qui est déjà membre d’un domaine AD DS, l’ordinateur tente de mettre à jour les attributs dNSHostName et servicePrincipalName pour son compte d’ordinateur dans le domaine.
  • Sur un contrôleur de domaine Windows, le service Netlogon tente de mettre à jour l’attribut servicePrincipalName toutes les 22 minutes.

Il existe deux causes possibles des échecs de mise à jour :

  • L’ordinateur ne dispose pas des autorisations suffisantes pour effectuer une demande de modification LDAP des attributs dNSHostName ou servicePrincipalName pour son compte d’ordinateur.

    Dans ce cas, les messages d’erreur qui correspondent aux événements décrits dans la section « Symptômes » sont les suivants :

    • Événement 5788

      L’accès est refusé.

    • Événement 5789

      Le fichier spécifié est introuvable.

  • Le suffixe DNS principal de l’ordinateur ne correspond pas au nom DNS du domaine AD DS dont l’ordinateur est membre. Cette configuration est appelée « espace de noms disjoint ».

    Par exemple, l’ordinateur est membre du domaine contoso.comActive Directory . Toutefois, son nom de nom de domaine complet DNS est member1.nyc.contoso.com. Par conséquent, le suffixe DNS principal ne correspond pas au nom de domaine Active Directory.

    La mise à jour est bloquée dans cette configuration, car la validation d’écriture requise des valeurs d’attribut échoue. La validation en écriture échoue car, par défaut, le Gestionnaire des comptes de sécurité (SAM) exige que le suffixe DNS principal d’un ordinateur corresponde au nom DNS du domaine AD DS dont l’ordinateur est membre.

    Dans ce cas, les messages d’erreur qui correspondent aux événements décrits dans la section « Symptômes » sont les suivants :

    • Événement 5788

      La syntaxe d’attribut spécifiée pour le service d’annuaire n’est pas valide.

    • Événement 5789

      Paramètre incorrect.

Résolution

Pour résoudre ce problème, recherchez la cause la plus probable, comme décrit dans la section « Cause ». Ensuite, utilisez la résolution appropriée pour la cause.

Résolution de la cause 1

Pour résoudre ce problème, vous devez vous assurer que le compte d’ordinateur dispose des autorisations suffisantes pour mettre à jour son propre objet ordinateur.

Dans la Rédacteur ACL, assurez-vous qu’il existe une entrée de contrôle d’accès (ACE) pour le compte de fiduciaire « SELF » et qu’il dispose d’un accès « Autoriser » pour les droits étendus suivants :

  • Écriture validée dans le nom d’hôte DNS
  • Écriture validée dans le nom du principal de service

Ensuite, vérifiez toutes les autorisations Refuser qui peuvent s’appliquer. À l’exception des appartenances au groupe de l’ordinateur, les administrateurs suivants s’appliquent également à l’ordinateur :

  • Tout le monde
  • Utilisateurs authentifiés
  • SELF

Les acees qui s’appliquent à ces administrateurs peuvent également refuser l’accès à l’écriture aux attributs, ou refuser les droits étendus « Écriture validée dans le nom d’hôte DNS » ou « Écriture validée au nom du principal du service ».

Résolution pour cause 2

Pour résoudre ce problème, utilisez l’une des méthodes suivantes, le cas échéant :

Méthode 1 : Corriger un espace de noms disjoint involontaire

Si la configuration disjointe est involontaire et si vous souhaitez revenir à un espace de noms contigu, utilisez cette méthode.

Pour plus d’informations sur la façon de rétablir un espace de noms contigu sur Windows Server 2003, consultez l’article Microsoft TechNet suivant :
Passer d’un espace de noms disjoint à un espace de noms contigu
Pour Windows Server 2008 et pour Windows Vista et versions ultérieures, consultez l’article Microsoft TechNet suivant :
Inverser un espace de noms disjoint créé accidentellement

Méthode 2 : Vérifier que la configuration de l’espace de noms disjoint fonctionne correctement

Utilisez cette méthode si vous souhaitez conserver l’espace de noms disjoint. Pour ce faire, procédez comme suit pour apporter des modifications de configuration afin de résoudre les erreurs.

Pour plus d’informations sur la façon de vérifier que l’espace de noms disjoint fonctionne correctement sur Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 avec Service Pack 1 (SP1) et Windows Server 2003 avec Service Pack 2 (SP2), consultez l’article Microsoft TechNet suivant : Créer un espace de noms disjoint
Pour plus d’informations sur la façon de vérifier que l’espace de noms disjoint fonctionne correctement sur Windows Server 2008 R2 et Windows Server 2008, consultez l’article Microsoft TechNet suivant : Créer un espace de noms disjoint

En étendant l’exemple mentionné dans la dernière puce principale de la section « Cause », vous ajoutez nyc.contoso.com en tant que suffixe autorisé à l’attribut.

Plus d’informations

Les versions antérieures de cet article mentionnait la modification des autorisations sur les objets ordinateur pour activer l’accès en écriture général pour résoudre ce problème. Il s’agissait de la seule approche qui existait dans Windows 2000. Toutefois, elle est moins sécurisée que l’utilisation de msDS-AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes empêchent le client d’écrire des noms de service arbitraires dans Active Directory. La « méthode Windows 2000 » permet au client d’écrire des spN qui empêchent Kerberos d’utiliser d’autres serveurs importants (créer des doublons). Lorsque vous utilisez msDS-AllowedDNSSuffixes, des collisions SPN telles que celles-ci peuvent se produire uniquement lorsque l’autre serveur a le même nom d’hôte que l’ordinateur local.

Une trace réseau de la réponse à la demande de modification LDAP affiche les informations suivantes :
victoire : 17368, src : 389 dst : 1044

LDAP : ProtocolOp : ModifyResponse (7)

LDAP : MessageID

LDAP : ProtocolOp = ModifyResponse

LDAP : Code de résultat = Violation de contrainte

LDAP : Message d’erreur = 0000200B : AtrErr : DSID-03151E6D Dans cette trace réseau, 200B hexadécimal est égal à 8203 décimal.

La commande net helpmsg 8203 retourne les informations suivantes : La syntaxe d’attribut spécifiée au service d’annuaire n’est pas valide. » Network Monitor 5.00.943 affiche le code de résultat suivant : « Violation de contrainte ». Winldap.h mappe l’erreur 13 à « LDAP_CONSTRAINT_VIOLATION.

Le nom de domaine DNS et le nom de domaine Active Directory peuvent différer si une ou plusieurs des conditions suivantes sont remplies :

  • La configuration DNS TCP/IP contient un domaine DNS qui diffère du domaine Active Directory dont l’ordinateur est membre, et l’option Modifier le suffixe DNS principal lorsque l’appartenance au domaine change est désactivée. Pour afficher cette option, cliquez avec le bouton droit sur Poste de travail, cliquez sur Propriétés, puis cliquez sur l’onglet Identification réseau .

  • Les ordinateurs Windows Server 2003 ou Windows XP Professionnel peuvent appliquer un paramètre stratégie de groupe qui définit le suffixe principal sur une valeur différente du domaine Active Directory. Le paramètre stratégie de groupe est le suivant : Configuration ordinateur\Modèles d’administration\Réseau\Client DNS : Suffixe DNS principal

  • Le contrôleur de domaine se trouve dans un domaine qui a été renommé par l’utilitaire Rendom.exe. Toutefois, l’administrateur a encore modifié le suffixe DNS du nom de domaine DNS précédent. Le processus de changement de domaine ne met pas à jour le suffixe DNS principal pour qu’il corresponde au nom de domaine DNS actuel après les renommages de noms de domaine DNS. Les domaines d’une forêt Active Directory qui n’ont pas le même nom de domaine hiérarchique se trouvent dans une arborescence de domaine différente. Lorsque différentes arborescences de domaines se trouvent dans une forêt, les domaines racines ne sont pas contigus. Toutefois, cette configuration ne crée pas d’espace de noms DNS disjoint. Vous disposez de plusieurs domaines DNS ou même Dns racine Active Directory. Un espace de noms disjoint est caractérisé par une différence entre le suffixe DNS principal et le nom de domaine Active Directory dont l’ordinateur est membre.

L’espace de noms disjoint peut être utilisé avec précaution dans certains scénarios. Toutefois, elle n’est pas prise en charge dans tous les scénarios.