Partager via

Les ID d’événement 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.

Numéro de 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. Seuls les connexions avec des comptes locaux fonctionnent.

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

    Type d’événement : Erreur
    Source d’événement : NETLOGON
    Catégorie d’événement : Aucune
    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 d’événement : NETLOGON
    Catégorie d’événement : Aucune
    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.>

    Note

    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, mais n’écrit pas 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 la jonction d’un ordinateur Windows à 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 n’est pas autorisé à 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 système ne peut pas trouver le fichier spécifié.

  • 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 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 d’écriture échoue, car, par défaut, le Gestionnaire de comptes de sécurité (SAM) requiert que le suffixe DNS principal d’un ordinateur correspond 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

      Le paramètre est 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 pour 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 d’ordinateur.

Dans l’Éditeur de liste de contrôle d’accès, assurez-vous qu’il existe une entrée de contrôle d’accès (ACE) pour le compte d’administrateur « SELF » et qu’il dispose d’un accès « Autoriser » pour les droits étendus suivants :

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

Vérifiez ensuite les autorisations Refuser qui peuvent s’appliquer. À l’exclusion des appartenances de groupe de l’ordinateur, les fiduciaires suivants s’appliquent également à l’ordinateur :

  • Tout le monde
  • Utilisateurs authentifiés
  • SELF

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

Résolution pour la 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 disjoint 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 revenir à 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 accidentellement créé

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 pour 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 le dernier point de puce principal de la section « Cause », vous devez ajouter nyc.contoso.com en tant que suffixe autorisé à l’attribut.

Plus d’informations

Les versions antérieures de cet article ont mentionné la modification des autorisations sur les objets ordinateur pour permettre 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, il est moins sécurisé que l’utilisation de msDS-AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes empêche le client d’écrire des SPN 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, les 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 :
win : 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, l’hexadécimal 200B 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 le suffixe DNS principal lorsque l’option Modification de l’appartenance au domaine est désactivée. Pour afficher cette option, cliquez avec le bouton droit sur Mon ordinateur, cliquez sur Propriétés, puis sur l’onglet Identification réseau.

  • Les ordinateurs Windows Server 2003 ou Windows XP Professionnel peuvent appliquer un paramètre de stratégie de groupe qui définit le suffixe principal à une valeur différente du domaine Active Directory. Le paramètre de 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 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 renommage de domaine ne met pas à jour le suffixe DNS principal pour qu’il corresponde au nom de domaine DNS actuel suivant 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érents arborescences de domaine 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 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, il n’est pas pris en charge dans tous les scénarios.