Ereignis-IDs 5788 und 5789 auf einem Windows-basierten Computer

Dieser Artikel bietet Lösungen für ein Problem, bei dem die Ereignis-ID 5788 und die Ereignis-ID 5789 protokolliert werden, wenn sich der DNS-Domänenname und der Active Directory-Domänenname auf einem Windows-basierten Computer unterscheiden.

Gilt für: Windows 7 Service Pack 1, Windows Server 2012 R2
Ursprüngliche KB-Nummer: 258503

Symptome

Möglicherweise tritt eines der folgenden Probleme auf:

  • Unter Windows Vista und höheren Versionen erhalten Sie während der interaktiven Anmeldung die folgende Fehlermeldung:

    Die Sicherheitsdatenbank auf dem Server verfügt nicht über ein Computerkonto für diese Arbeitsstationsvertrauensstellung.

  • Interaktive Anmeldungen mit domänenbasierten Konten funktionieren nicht. Nur Anmeldungen mit lokalen Konten funktionieren.

  • Die folgenden Ereignismeldungen werden im Systemprotokoll protokolliert:

    Ereignistyp: Fehler
    Ereignisquelle: NETLOGON
    Ereigniskategorie: Keine
    Ereignis-ID: 5788
    Computer: ComputerName
    Beschreibung:
    Fehler beim Aktualisieren des Dienstprinzipalnamens (Service Principal Name, SPN) des Computerobjekts in Active Directory. Der folgende Fehler ist aufgetreten: <Detaillierte Fehlermeldung, die je nach Ursache variiert.>

    Ereignistyp: Fehler
    Ereignisquelle: NETLOGON
    Ereigniskategorie: Keine
    Ereignis-ID: 5789
    Computer: Computer
    Beschreibung:
    Fehler beim Aktualisieren des DNS-Hostnamens des Computerobjekts in Active Directory. Der folgende Fehler ist aufgetreten: <Detaillierte Fehlermeldung, die je nach Ursache variiert.>

    Hinweis

    Ausführliche Fehlermeldungen für diese Ereignisse sind im Abschnitt "Ursache" aufgeführt.

Ursache

Dieses Verhalten tritt auf, wenn ein Computer versucht, aber nicht in die Attribute dNSHostName und servicePrincipalName für sein Computerkonto in einer AD DS-Domäne (Active Directory Domain Services) schreibt.

Ein Computer versucht, diese Attribute zu aktualisieren, wenn die folgenden Bedingungen zutreffen:

  • Unmittelbar nachdem ein Windows-basierter Computer einer Domäne beigetreten ist, versucht der Computer, die Attribute dNSHostName und servicePrincipalName für sein Computerkonto in der neuen Domäne festzulegen.
  • Wenn der Sicherheitskanal auf einem Windows-basierten Computer eingerichtet wird, der bereits Mitglied einer AD DS-Domäne ist, versucht der Computer, die Attribute dNSHostName und servicePrincipalName für sein Computerkonto in der Domäne zu aktualisieren.
  • Auf einem Windows-basierten Domänencontroller versucht der Netlogon-Dienst alle 22 Minuten, das Attribut servicePrincipalName zu aktualisieren.

Es gibt zwei mögliche Ursachen für Updatefehler:

  • Der Computer verfügt nicht über ausreichende Berechtigungen zum Ausführen einer LDAP-Änderungsanforderung des dNSHostName- oder servicePrincipalName-Attributs für sein Computerkonto.

    In diesem Fall lauten die Fehlermeldungen, die den im Abschnitt "Symptome" beschriebenen Ereignissen entsprechen, wie folgt:

    • Ereignis 5788

      Der Zugriff wurde verweigert.

    • Ereignis 5789

      Die angegebene Datei wurde nicht gefunden.

  • Das primäre DNS-Suffix des Computers stimmt nicht mit dem DNS-Namen der AD DS-Domäne überein, deren Mitglied der Computer ist. Diese Konfiguration wird als "Nicht zusammenhängender Namespace" bezeichnet.

    Der Computer ist beispielsweise Mitglied der Active Directory-Domäne contoso.com. Der DNS-FQDN-Name lautet member1.nyc.contoso.comjedoch . Daher stimmt das primäre DNS-Suffix nicht mit dem Active Directory-Domänennamen überein.

    Das Update wird in dieser Konfiguration blockiert, da die erforderliche Schreibüberprüfung der Attributwerte fehlschlägt. Die Schreibüberprüfung schlägt fehl, da der Security Accounts Manager (SAM) standardmäßig erfordert, dass das primäre DNS-Suffix eines Computers mit dem DNS-Namen der AD DS-Domäne übereinstimmt, deren Computer Mitglied ist.

    In diesem Fall lauten die Fehlermeldungen, die den im Abschnitt "Symptome" beschriebenen Ereignissen entsprechen, wie folgt:

    • Ereignis 5788

      Die für den Verzeichnisdienst angegebene Attributsyntax ist ungültig.

    • Ereignis 5789

      Falscher Parameter.

Lösung

Um dieses Problem zu beheben, suchen Sie die wahrscheinlichste Ursache, wie im Abschnitt "Ursache" beschrieben. Verwenden Sie dann die für die Ursache geeignete Auflösung.

Lösung für Ursache 1

Um dieses Problem zu beheben, müssen Sie sicherstellen, dass das Computerkonto über ausreichende Berechtigungen zum Aktualisieren seines eigenen Computerobjekts verfügt.

Stellen Sie im ACL-Editor sicher, dass ein Zugriffssteuerungseintrag (ACE) für das Vertrauensstellungskonto "SELF" vorhanden ist und dass es "Allow"-Zugriff für die folgenden erweiterten Rechte hat:

  • Überprüfter Schreibvorgang in DNS-Hostname
  • Überprüfter Schreibvorgang in Dienstprinzipalname

Überprüfen Sie dann alle möglicherweise zutreffenden Ablehnungsberechtigungen. Mit Ausnahme der Gruppenmitgliedschaften des Computers gelten die folgenden Vertrauensstellungen auch für den Computer:

  • Jeder
  • Authentifizierte Benutzer
  • SELBST

Die ACEs, die für diese Vertrauenshänder gelten, können auch den Zugriff auf Schreibvorgänge in Attribute verweigern oder die erweiterten Rechte "Überprüfter Schreibzugriff auf DNS-Hostname" oder "Überprüfter Schreibzugriff in Dienstprinzipalname" verweigern.

Lösung für Ursache 2

Um dieses Problem zu beheben, verwenden Sie je nach Bedarf eine der folgenden Methoden:

Methode 1: Korrigieren eines unbeabsichtigten, nicht zusammenhängenden Namespaces

Wenn die nicht zusammenhängende Konfiguration unbeabsichtigt ist und Sie zu einem zusammenhängenden Namespace rückgängig machen möchten, verwenden Sie diese Methode.

Weitere Informationen zum rückgängig machen zu einem zusammenhängenden Namespace unter Windows Server 2003 finden Sie im folgenden Microsoft TechNet-Artikel:
Übergang von einem disjoint-Namespace zu einem zusammenhängenden Namespace
Informationen zu Windows Server 2008 und windows Vista und höheren Versionen finden Sie im folgenden Microsoft TechNet-Artikel:
Umkehren eines versehentlich erstellten nicht zusammenhängenden Namespaces

Methode 2: Überprüfen, ob die Konfiguration des nicht zusammenhängenden Namespaces ordnungsgemäß funktioniert

Verwenden Sie diese Methode, wenn Sie den nicht zusammenhängenden Namespace beibehalten möchten. Führen Sie dazu die folgenden Schritte aus, um einige Konfigurationsänderungen vorzunehmen, um die Fehler zu beheben.

Weitere Informationen zum Überprüfen, ob der getrennte Namespace unter Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 mit Service Pack 1 (SP1) und Windows Server 2003 mit Service Pack 2 (SP2) ordnungsgemäß funktioniert, finden Sie im folgenden Microsoft TechNet-Artikel: Erstellen eines nicht zusammenhängenden Namespaces.
Weitere Informationen zum Überprüfen, ob der nicht zusammenhängende Namespace unter Windows Server 2008 R2 und Windows Server 2008 ordnungsgemäß funktioniert, finden Sie im folgenden Microsoft TechNet-Artikel: Erstellen eines nicht zusammenhängenden Namespaces.

Durch Erweitern des Beispiels, das im letzten hauptpunkt im Abschnitt "Ursache" erwähnt wird, würden Sie dem Attribut als zulässiges Suffix hinzufügen nyc.contoso.com .

Weitere Informationen

Ältere Versionen dieses Artikels erwähnten das Ändern der Berechtigungen für die Computerobjekte, um allgemeinen Schreibzugriff zu ermöglichen, um dieses Problem zu beheben. Dies war der einzige Ansatz, der in Windows 2000 existierte. Es ist jedoch weniger sicher als die Verwendung von msDS-AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes schränkt ein, dass der Client beliebige SPNs in Active Directory schreibt. Die "Windows 2000-Methode" ermöglicht es dem Client, SPNs zu schreiben, die Kerberos daran hindern, mit anderen wichtigen Servern zu arbeiten (Duplikate erstellen). Wenn Sie msDS-AllowedDNSSuffixes verwenden, können SPN-Konflikte wie diese nur auftreten, wenn der andere Server denselben Hostnamen wie der lokale Computer hat.

Eine Netzwerkablaufverfolgung der Antwort auf die LDAP-Änderungsanforderung zeigt die folgenden Informationen an:
win: 17368, src: 389 dst: 1044

LDAP: ProtocolOp: ModifyResponse (7)

LDAP: MessageID

LDAP: ProtocolOp = ModifyResponse

LDAP: Ergebniscode = Einschränkungsverletzung

LDAP: Fehlermeldung = 0000200B: AtrErr: DSID-03151E6D In dieser Netzwerkablaufverfolgung ist 200B hexadezimal gleich 8203 dezimal.

Der Befehl net helpmsg 8203 gibt die folgenden Informationen zurück: Die für den Verzeichnisdienst angegebene Attributsyntax ist ungültig." Network Monitor 5.00.943 zeigt den folgenden Ergebniscode an: "Einschränkungsverletzung". Winldap.h ordnet Fehler 13 "LDAP_CONSTRAINT_VIOLATION.

Der DNS-Domänenname und der Active Directory-Domänenname können sich unterscheiden, wenn mindestens eine der folgenden Bedingungen zutrifft:

  • Die TCP/IP-DNS-Konfiguration enthält eine DNS-Domäne, die sich von der Active Directory-Domäne unterscheidet, deren Mitglied der Computer ist, und die Option Primäres DNS-Suffix ändern, wenn sich die Domänenmitgliedschaft ändert deaktiviert ist. Klicken Sie zum Anzeigen dieser Option mit der rechten Maustaste auf Arbeitsplatz, klicken Sie auf Eigenschaften, und klicken Sie dann auf die Registerkarte Netzwerkidentifikation .

  • Windows Server 2003- oder Windows XP Professional-basierte Computer können eine Gruppenrichtlinie Einstellung anwenden, die das primäre Suffix auf einen Wert festlegt, der sich von der Active Directory-Domäne unterscheidet. Die Gruppenrichtlinie Einstellung lautet wie folgt: Computerkonfiguration\Administrative Vorlagen\Netzwerk\DNS-Client: Primäres DNS-Suffix

  • Der Domänencontroller befindet sich in einer Domäne, die vom Hilfsprogramm Rendom.exe umbenannt wurde. Der Administrator hat jedoch das DNS-Suffix vom vorherigen DNS-Domänennamen geändert. Der Domänenbenennungsprozess aktualisiert das primäre DNS-Suffix nicht so, dass es dem aktuellen DNS-Domänennamen entspricht, nachdem DNS-Domänennamen umbenannt wurden. Domänen in einer Active Directory-Gesamtstruktur, die nicht über denselben hierarchischen Domänennamen verfügen, befinden sich in einer anderen Domänenstruktur. Wenn sich verschiedene Domänenstrukturen in einer Gesamtstruktur befinden, sind die Stammdomänen nicht zusammenhängend. Diese Konfiguration erstellt jedoch keinen nicht zusammenhängenden DNS-Namespace. Sie verfügen über mehrere DNS- oder sogar Active Directory-DNS-Stammdomänen. Ein nicht zusammenhängender Namespace ist durch einen Unterschied zwischen dem primären DNS-Suffix und dem Active Directory-Domänennamen gekennzeichnet, dessen Mitglied der Computer ist.

Disjoint-Namespace kann in einigen Szenarien mit Vorsicht verwendet werden. Es wird jedoch nicht in allen Szenarien unterstützt.