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.
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 lautetmember1.nyc.contoso.com
jedoch . 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 Trustee-Konto "SELF" vorhanden ist und dass es über "Allow"-Zugriff für die folgenden erweiterten Rechte verfügt:
- Ü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 wiederherstellen 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:
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 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 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.