Freigeben über


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

Dieser Artikel enthält Lösungen für ein Problem, bei dem ereignis-ID 5788 und Ereignis-ID 5789 protokolliert werden, wenn der DNS-Domänenname und der Active Directory-Domänenname auf einem Windows-basierten Computer unterschiedlich sind.

Ursprüngliche KB-Nummer: 258503

Symptome

Möglicherweise treten 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 Vertrauensstellung der Arbeitsstation.

  • 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 Versuch, den Dienstprinzipalnamen (Service Principal Name, SPN) des Computerobjekts in Active Directory zu aktualisieren. 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 Versuch, den DNS-Hostnamen des Computerobjekts in Active Directory zu aktualisieren. Der folgende Fehler ist aufgetreten: <Detaillierte Fehlermeldung, die je nach Ursache variiert.>

    Notiz

    Detaillierte Fehlermeldungen für diese Ereignisse werden 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-Domäne Services) schreibt.

Ein Computer versucht, diese Attribute zu aktualisieren, wenn die folgenden Bedingungen erfüllt sind:

  • Unmittelbar nach dem Beitritt eines Windows-basierten Computers zu einer Domäne 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 dNSHostName- und servicePrincipalName-Attribute für sein Computerkonto in der Domäne zu aktualisieren.
  • Auf einem Windows-basierten Domänencontroller versucht der Netlogon-Dienst alle 22 Minuten, das ServicePrincipalName-Attribut zu aktualisieren.

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

  • Der Computer verfügt nicht über ausreichende Berechtigungen, um eine LDAP-Änderungsanforderung der Attribute dNSHostName oder servicePrincipalName für sein Computerkonto abzuschließen.

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

    • Ereignis 5788

      Zugriff 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 "Disjoint-Namespace" bezeichnet.

    Der Computer ist z. B. Mitglied der Active Directory-Domäne contoso.com. Der NAME des DNS-FQDN ist 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 standardmäßig der Security Accounts Manager (SAM) 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 sind 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

      „Der Parameter ist falsch.“

Lösung

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

Lösung für Ursache 1

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

Stellen Sie im ACL-Editor sicher, dass für das Trustee-Konto "SELF" ein Zugriffssteuerungseintrag (Access Control Entry, ACE) vorhanden ist und dass er zugriff auf die folgenden erweiterten Rechte hat:

  • Überprüfter Schreibzugriff auf DNS-Hostname
  • Überprüfter Schreibzugriff auf den Dienstprinzipalnamen

Überprüfen Sie dann alle Verweigerungsberechtigungen, die gelten können. Mit Ausnahme der Gruppenmitgliedschaften des Computers gelten auch die folgenden Trustees für den Computer:

  • Jeder
  • Authentifizierte Benutzer
  • SELF

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

Lösung für Ursache 2

Um dieses Problem zu beheben, verwenden Sie ggf. 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 zurückkehren möchten, verwenden Sie diese Methode.

Weitere Informationen zum Wiederherstellen eines 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:
Rückgängigmachen eines versehentlich erstellten nicht zusammenhängenden Namespaces

Methode 2: Überprüfen, ob die nicht zusammenhängende Namespacekonfiguration 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 nicht zusammenhängende 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: Create a Disjoint Namespace
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 Hauptzeichenpunkt im Abschnitt "Ursache" erwähnt wird, würden Sie dem Attribut ein zulässiges Suffix hinzufügen nyc.contoso.com .

Weitere Informationen

Ältere Versionen dieses Artikels haben erwähnt, dass die Berechtigungen für die Computerobjekte geändert werden, um den 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änken den Client ein, beliebige SPNs in Active Directory zu schreiben. Die "Windows 2000-Methode" ermöglicht dem Client das Schreiben von SPNs, die das Arbeiten mit anderen wichtigen Servern blockieren (Erstellen von Duplikaten). Wenn Sie msDS-AllowedDNSuffixes verwenden, können SPN-Kollisionen wie solche 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 Net helpmsg 8203-Befehl gibt die folgenden Informationen zurück: Die für den Verzeichnisdienst angegebene Attributsyntax ist ungültig." Der Netzwerkmonitor 5.00.943 zeigt den folgenden Ergebniscode an: "Einschränkungsverletzung". Winldap.h ordnet Fehler 13 "LDAP_CONSTRAINT_VIOLATION zu.

Der DNS-Domänenname und der Active Directory-Domänenname können variieren, wenn eine oder mehrere der folgenden Bedingungen erfüllt sind:

  • Die TCP/IP-DNS-Konfiguration enthält eine DNS-Domäne, die sich von der Active Directory-Domäne unterscheidet, von der der Computer Mitglied ist, und das primäre DNS-Suffix ändern, wenn die Option für domänenmitgliedschaftsänderungen deaktiviert ist. Um diese Option anzuzeigen, klicken Sie mit der rechten Maustaste auf "Arbeitsplatz", klicken Sie auf "Eigenschaften", und klicken Sie dann auf die Registerkarte "Netzwerkidentifizierung ".

  • Windows Server 2003- oder Windows XP Professional-basierte Computer können eine Gruppenrichtlinieneinstellung anwenden, die das primäre Suffix auf einen Wert festlegt, der sich von der Active Directory-Domäne unterscheidet. Die Gruppenrichtlinieneinstellung 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 das DNS-Suffix jedoch noch aus dem vorherigen DNS-Domänennamen geändert. Der Domänenbenennungsprozess aktualisiert das primäre DNS-Suffix nicht so, dass er dem aktuellen DNS-Domänennamen entspricht, nachdem er die DNS-Domänennamen umbenannt hat. 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 unterschiedliche 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 zeichnet sich durch einen Unterschied zwischen dem primären DNS-Suffix und dem Active Directory-Domänennamen aus, dessen Mitglied der Computer ist.

Der nicht zusammenhängende Namespace kann in einigen Szenarien mit Vorsicht verwendet werden. Es wird jedoch in allen Szenarien nicht unterstützt.