Händelse-ID 5788 och 5789 inträffar på en Windows-baserad dator

  • Artikel

Den här artikeln innehåller lösningar på ett problem där händelse-ID 5788 och händelse-ID 5789 loggas när DNS-domännamnet och Active Directory-domännamnet skiljer sig åt på en Windows-baserad dator.

Ursprungligt KB-nummer: 258503

Symptom

Du kan uppleva något av följande problem:

  • I Windows Vista och senare versioner får du följande felmeddelande under interaktiv inloggning:

    Säkerhetsdatabasen på servern har inget datorkonto för den här arbetsstationens förtroenderelation.

  • Interaktiva inloggningar med domänbaserade konton fungerar inte. Endast inloggningar med lokala konton fungerar.

  • Följande händelsemeddelanden loggas i systemloggen:

    Händelsetyp: Fel
    Händelsekälla: NETLOGON
    Händelsekategori: Ingen
    Händelse-ID: 5788
    Dator: ComputerName
    Beskrivning:
    Det gick inte att uppdatera tjänstens huvudnamn (SPN) för datorobjektet i Active Directory. Följande fel uppstod: <Ett detaljerat felmeddelande som varierar beroende på orsaken.>

    Händelsetyp: Fel
    Händelsekälla: NETLOGON
    Händelsekategori: Ingen
    Händelse-ID: 5789
    Dator: Dator
    Beskrivning:
    Det gick inte att uppdatera DNS-värdnamnet för datorobjektet i Active Directory. Följande fel uppstod: <Ett detaljerat felmeddelande som varierar beroende på orsaken.>

    Obs!

    Detaljerade felmeddelanden för dessa händelser visas i avsnittet "Orsak".

Orsak

Det här beteendet inträffar när en dator försöker men inte skriver till attributen dNSHostName och servicePrincipalName för sitt datorkonto i en Active Directory Domain Services-domän (AD DS).

En dator försöker uppdatera dessa attribut om följande villkor är uppfyllda:

  • Omedelbart efter att en Windows-baserad dator ansluter till en domän försöker datorn ange attributen dNSHostName och servicePrincipalName för sitt datorkonto i den nya domänen.
  • När säkerhetskanalen upprättas på en Windows-baserad dator som redan är medlem i en AD DS-domän försöker datorn uppdatera attributen dNSHostName och servicePrincipalName för sitt datorkonto i domänen.
  • På en Windows-baserad domänkontrollant försöker Netlogon-tjänsten uppdatera attributet servicePrincipalName var 22:e minut.

Det finns två möjliga orsaker till uppdateringsfelen:

  • Datorn har inte tillräcklig behörighet för att slutföra en LDAP-ändringsbegäran för attributen dNSHostName eller servicePrincipalName för sitt datorkonto.

    I det här fallet är felmeddelandena som motsvarar de händelser som beskrivs i avsnittet "Symptom" följande:

    • Händelse 5788

      Åtkomst nekas.

    • Händelse 5789

      Det går inte att hitta filen.

  • Datorns primära DNS-suffix matchar inte DNS-namnet på den AD DS-domän som datorn är medlem i. Den här konfigurationen kallas "Disjoint namespace".

    Datorn är till exempel medlem i Active Directory-domänen contoso.com. Dns FQDN-namnet är member1.nyc.contoso.comdock . Därför matchar inte det primära DNS-suffixet Active Directory-domännamnet.

    Uppdateringen blockeras i den här konfigurationen eftersom den nödvändiga skrivverifieringen av attributvärdena misslyckas. Skrivverifieringen misslyckas eftersom SAM (Security Accounts Manager) som standard kräver att en dators primära DNS-suffix matchar DNS-namnet på DEN AD DS-domän som datorn är medlem i.

    I det här fallet är felmeddelandena som motsvarar de händelser som beskrivs i avsnittet "Symptom" följande:

    • Händelse 5788

      Attributsyntaxen som angetts för katalogtjänsten är ogiltig.

    • Händelse 5789

      Parametern är felaktig.

Åtgärd

Lös problemet genom att hitta den troligaste orsaken enligt beskrivningen i avsnittet "Orsak". Använd sedan den lösning som är lämplig för orsaken.

Lösning för orsak 1

För att lösa det här problemet måste du se till att datorkontot har tillräcklig behörighet för att uppdatera sitt eget datorobjekt.

I ACL-redigeraren kontrollerar du att det finns en åtkomstkontrollpost (ACE) för förvaltarkontot "SELF" och att det har "Tillåt" åtkomst för följande utökade rättigheter:

  • Validerad skrivning till DNS-värdnamn
  • Verifierad skrivning till tjänstens huvudnamn

Kontrollera sedan eventuella neka-behörigheter som kan gälla. Med undantag för datorns gruppmedlemskap gäller även följande förvaltare för datorn:

  • Alla
  • Autentiserade användare
  • Själv

De ACL:er som gäller för dessa förvaltare kan också neka åtkomst till att skriva till attribut, eller så kan de neka utökade rättigheter för "Validerad skrivning till DNS-värdnamn" eller "Validerad skrivning till tjänstens huvudnamn".

Lösning för orsak 2

Lös problemet genom att använda någon av följande metoder, beroende på vad som är lämpligt:

Metod 1: Korrigera ett oavsiktligt osammanhängande namnområde

Om den osammanhängande konfigurationen är oavsiktlig och om du vill återgå till ett sammanhängande namnområde använder du den här metoden.

Mer information om hur du återgår till ett sammanhängande namnområde på Windows Server 2003 finns i följande Microsoft TechNet-artikel:
Övergång från ett osammanhängande namnområde till ett sammanhängande namnområde
För Windows Server 2008 och för Windows Vista och senare versioner, se följande Microsoft TechNet-artikel:
Omvända en oavsiktligt skapad uppdelad namnrymd

Metod 2: Kontrollera att den uppdelade namnområdeskonfigurationen fungerar som den ska

Använd den här metoden om du vill behålla det uppdelade namnområdet. Det gör du genom att följa de här stegen för att göra några konfigurationsändringar för att lösa felen.

Mer information om hur du verifierar att den uppdelade namnrymden fungerar korrekt på Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 med Service Pack 1 (SP1) och Windows Server 2003 med Service Pack 2 (SP2) finns i följande Microsoft TechNet-artikel: Skapa en uppdelad namnrymd
Mer information om hur du verifierar att det uppdelade namnområdet fungerar korrekt på Windows Server 2008 R2 och Windows Server 2008 finns i följande Microsoft TechNet-artikel: Skapa en uppdelad namnrymd

Genom att utöka exemplet som nämns i den sista stora punktpunkten i avsnittet "Orsak" lägger du till nyc.contoso.com som ett tillåtet suffix till attributet.

Mer information

Äldre versioner av den här artikeln nämnde att ändra behörigheterna för datorobjekten för att aktivera allmän skrivåtkomst för att lösa det här problemet. Detta var den enda metoden som fanns i Windows 2000. Det är dock mindre säkert än att använda msDS-AllowedDNSSuffix.

msDS-AllowedDNSSuffixes begränsar klienten från att skriva godtyckliga SPN till Active Directory. Med metoden "Windows 2000" kan klienten skriva SPN:er som blockerar Kerberos från att arbeta med andra viktiga servrar (skapa dubbletter). När du använder msDS-AllowedDNSSuffix kan SPN-kollisioner som dessa endast inträffa när den andra servern har samma värdnamn som den lokala datorn.

En nätverksspårning av svaret på LDAP-ändringsbegäran visar följande information:
win: 17368, src: 389 dst: 1044

LDAP: ProtocolOp: ModifyResponse (7)

LDAP: MessageID

LDAP: ProtocolOp = ModifyResponse

LDAP: Resultatkod = Begränsningsfel

LDAP: Felmeddelande = 0000200B: AtrErr: DSID-03151E6D I den här nätverksspårningen är 200B hexadecimalt lika med 8 203 decimaler.

Kommandot net helpmsg 8203 returnerar följande information: Attributsyntaxen som anges för katalogtjänsten är ogiltig." Network Monitor 5.00.943 visar följande resultatkod: "Begränsningsöverträdelse". Winldap.h mappar fel 13 till "LDAP_CONSTRAINT_VIOLATION.

DNS-domännamnet och Active Directory-domännamnet kan skilja sig om ett eller flera av följande villkor är uppfyllda:

  • TCP/IP DNS-konfigurationen innehåller en DNS-domän som skiljer sig från den Active Directory-domän som datorn är medlem i och alternativet Ändra primär DNS-suffix när domänmedlemskapsändringar inaktiveras. Om du vill visa det här alternativet högerklickar du på Min dator, klickar på Egenskaper och klickar sedan på fliken Nätverksidentifiering .

  • Windows Server 2003-baserade eller Windows XP Professional-baserade datorer kan använda en grupprincipinställning som anger det primära suffixet till ett värde som skiljer sig från Active Directory-domänen. Grupprincipinställningen är följande: Datorkonfiguration\Administrativa mallar\Nätverk\DNS-klient: Primär DNS-suffix

  • Domänkontrollanten finns i en domän som har bytt namn av verktyget Rendom.exe. Administratören ändrade dock DNS-suffixet från det tidigare DNS-domännamnet. Domänbytesprocessen uppdaterar inte det primära DNS-suffixet så att det matchar det aktuella DNS-domännamnet efter namnbyte av DNS-domännamn. Domäner i en Active Directory-skog som inte har samma hierarkiska domännamn finns i ett annat domänträd. När olika domänträd finns i en skog är rotdomänerna inte sammanhängande. Den här konfigurationen skapar dock inte ett osammanhängande DNS-namnområde. Du har flera DNS-rotdomäner eller till och med Active Directory DNS-rotdomäner. Ett disjoint namnområde kännetecknas av en skillnad mellan det primära DNS-suffixet och det Active Directory-domännamn som datorn är medlem i.

Uppdelad namnrymd kan användas med försiktighet i vissa scenarier. Det stöds dock inte i alla scenarier.