Så här felsöker du Active Directory-replikeringsfel 5 i Windows Server: Åtkomst nekas

  • Artikel

Den här artikeln beskriver symptom, orsak och lösning på situationer där Active Directory-replikering misslyckas med fel 5: Åtkomst nekas.

Gäller för: Windows Server 2012 R2
Ursprungligt KB-nummer: 3073945

Symptom

Du kan stöta på ett eller flera av följande symptom när Active Directory-replikering misslyckas med fel 5.

Symptom 1

Kommandoradsverktyget Dcdiag.exe rapporterar att Active Directory-replikeringstestet misslyckas med felstatuskoden (5). Rapporten liknar följande:

Testserver: Site_Name\Destination_DC_Name
Starttest: Replikering
*Replikeringskontroll
[Replikeringskontroll, Destination_DC_Name] Ett nytt replikeringsförsök misslyckades:
Från Source_DC till Destination_DC
Namngivningskontext: Directory_Partition_DN_Path
Replikeringen genererade ett fel (5):
Åtkomst nekas.
Felet inträffade vid datumoch tid.
Den senaste framgången inträffade vid datumoch tid.
Antal fel har inträffat sedan den senaste lyckade åtgärden.

Symptom 2

Kommandoradsverktyget Dcdiag.exe rapporterar att funktionen DsBindWithSpnEx misslyckas med fel 5 genom att köra DCDIAG /test:CHECKSECURITYERROR kommandot .

Symptom 3

Kommandoradsverktyget REPADMIN.exe rapporterar att det senaste replikeringsförsöket misslyckades med status 5.

DE REPADMIN-kommandon som ofta anger de fem statusarna inkluderar men är inte begränsade till följande:

  • REPADMIN /KCC
  • REPADMIN /REPLICATE
  • REPADMIN /REPLSUM
  • REPADMIN /SHOWREPL
  • REPADMIN /SHOWREPS
  • REPADMIN /SYNCALL

Exempel på utdata från REPADMIN /SHOWREPL kommandot följer. Dessa utdata visar inkommande replikering från DC_2_Name till DC_1_Name misslyckas med felet "Åtkomst nekas".

Site_name\DC_1_Name
DSA-alternativ: IS_GC
Webbplatsalternativ: (ingen)
DSA-objekt-GUID: GUID
DSA invocationID: invocationID

==== INKOMMANDE GRANNAR===========================================
DC= DomainName,DC=com
Site_name\DC_2_Name via RPC
DSA-objekt-GUID: GUID
Senaste försök @ Datumtid misslyckades, resultat 5 (0x5):
Åtkomst nekas.
<#> på varandra följande fel.
Senaste lyckade @ Datumtid.

Symptom 4

NTDS KCC-, NTDS General- eller Microsoft-Windows-ActiveDirectory_DomainService händelser med de fem statusarna loggas i katalogtjänstloggen i Loggboken.

I följande tabell sammanfattas Active Directory-händelser som ofta anger statusen 8524.

Händelse-ID Source Händelsesträng
1655 Allmänt NTDS Active Directory försökte kommunicera med följande globala katalog och försöken misslyckades.
1925 NTDS KCC Det gick inte att upprätta en replikeringslänk för följande skrivbara katalogpartition.
1926 NTDS KCC Det gick inte att upprätta en replikeringslänk till en skrivskyddad katalogpartition med följande parametrar.

Symptom 5

När du högerklickar på anslutningsobjektet från en källdomänkontrollant i Active Directory-platser och tjänster och sedan väljer Replikera nu misslyckas processen och du får följande fel:

Replikera nu

Följande fel uppstod under försöket att synkronisera namngivningskontexten %katalogpartitionsnamn% från domänkontrollantens käll-DC till domänkontrollantens mål-DC: Åtkomst nekas.

Åtgärden fortsätter inte.

Följande skärmbild representerar ett exempel på felet:

Skärmbild av fönstret Replikera nu som visar ett exempel på felet.

Lösning

Använd det allmänna kommandoradsverktyget DCDIAG för att köra flera tester. Använd kommandoradsverktyget DCDIAG /TEST:CheckSecurityErrors för att utföra specifika tester. (Dessa tester innehåller en SPN-registreringskontroll.) Kör testerna för att felsöka active directory-åtgärdsreplikering som misslyckas med fel 5 och fel 8453. Tänk dock på att det här verktyget inte körs som en del av standardkörningen av DCDIAG.

Undvik problemet så här:

  1. Kör DCDIAG på måldomänkontrollanten i kommandotolken.
  2. Kör DCDIAG /TEST:CheckSecurityError.
  3. Kör NETDIAG.
  4. Lös eventuella fel som har identifierats av DCDIAG och NETDIAG.
  5. Försök igen med den replikeringsåtgärd som tidigare misslyckades. Om replikeringen fortsätter att misslyckas läser du avsnittet "Orsaker och lösningar".

Orsaker och lösningar

Följande orsaker kan resultera i fel 5. Vissa av dem har lösningar.

Orsak 1: Inställningen RestrictRemoteClients i registret har värdet 2

Om principinställningen Begränsningar för oautentiserade RPC-klienter är aktiverad och är inställd på Autentiseras utan undantag, anges registervärdet RestrictRemoteClients till värdet 0x2 i registerundernyckeln HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\RPC .

Den här principinställningen gör att endast autentiserade RPC-klienter (Remote Procedure Call) kan ansluta till RPC-servrar som körs på den dator där principinställningen tillämpas. Det tillåter inte undantag. Om du väljer det här alternativet kan ett system inte ta emot anonyma fjärrsamtal med hjälp av RPC. Den här inställningen ska aldrig tillämpas på en domänkontrollant.

Lösning

  1. Inaktivera principinställningen Begränsningar för oautentiserade RPC-klienter som begränsar registervärdet RestrictRemoteClients till 2.

    Obs!

    Principinställningen finns i följande sökväg: Datorkonfiguration\Administrativa mallar\System\Fjärrproceduranrop\Begränsningar för oautentiserade RPC-klienter

  2. Ta bort registerinställningen RestrictRemoteClients och starta sedan om.

Se Begränsningar för oautentiserade RPC-klienter: Den grupprincip som slår din domän i ansiktet.

Orsak 2: CrashOnAuditFail-inställningen i måldomänkontrollantens register har värdet 2

Ett CrashOnAduitFail-värde på 2 utlöses om principinställningen Granska: Stäng av systemet omedelbart om det inte går att logga principinställningen för säkerhetsgranskningar i grupprincip är aktiverad och den lokala säkerhetshändelseloggen blir full.

Active Directory-domänkontrollanter är särskilt utsatta för säkerhetsloggar med maximal kapacitet när granskning är aktiverat och storleken på säkerhetshändelseloggen begränsas av alternativen Skriv inte över händelser (rensa loggen manuellt) och Skriv över efter behov i Loggboken eller deras grupprincip motsvarigheter.

Lösning

Viktigt

Följ stegen i det här avsnittet noggrant. Det kan uppstå allvarliga problem om du gör felaktiga ändringar i registret. Innan du ändrar det bör du först säkerhetskopiera registret för att kunna återställa det om problem skulle uppstå.

  1. Rensa säkerhetshändelseloggen och spara den på en annan plats efter behov.
  2. Utvärdera eventuella storleksbegränsningar på säkerhetshändelseloggen igen. Detta inkluderar principbaserade inställningar.
  3. Ta bort och återskapa sedan en CrashOnAuditFail-registerpost enligt följande:Registerundernyckel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
    Värdenamn: CrashOnAuditFail
    Värdetyp: REG_DWORD
    Värdedata: 1
  4. Starta om måldomänkontrollanten.

Orsak 3: Ogiltigt förtroende

Om Active Directory-replikering misslyckas mellan domänkontrollanter i olika domäner bör du kontrollera hälsotillståndet för förtroenderelationer längs förtroendesökvägen.

Du kan testa netdiag-förtroenderelationstestet för att söka efter brutna förtroenden. Verktyget Netdiag.exe identifierar brutna förtroenden genom att visa följande text:

Förtroenderelationstest. . . . . . : misslyckades
Testa för att säkerställa att DomainSid för domänen "domännamn" är korrekt.
[ALLVARLIGT] Säker kanal till domänen "domännamn" är bruten.
[% variabelstatuskod %]

Om du till exempel har en skog med flera domäner som innehåller en rotdomän (Contoso.COM), en underordnad domän (B.Contoso.COM), en underordnad domän (C.B.Contoso.COM) och en träddomän i samma skog (Fabrikam.COM) och om replikeringen misslyckas mellan domänkontrollanter i barnbarnsdomänen (C.B.Contoso.COM) och träddomänen (Fabrikam.COM)bör du kontrollera förtroendehälsa mellan C.B.Contoso.COM och B.Contoso.COM, mellan B.Contoso.COM och Contoso.COM, och slutligen mellan Contoso.COM och Fabrikam.COM.

Om det finns ett genvägsförtroende mellan måldomänerna behöver du inte verifiera kedjan för förtroendesökväg. I stället bör du verifiera genvägsförtroendet mellan målet och källdomänen.

Sök efter de senaste lösenordsändringarna i förtroendet genom att köra följande kommando:

Repadmin /showobjmeta * <DN path for TDO in question>

Kontrollera att måldomänkontrollanten transitivt inkommande replikerar den skrivbara domänkatalogpartitionen där ändringar av förtroendelösenord kan börja gälla.

Kommandon för att återställa förtroenden från rotdomänen PDC är följande:

netdom trust <Root Domain> /Domain:<Child Domain> /UserD:CHILD /PasswordD:* /UserO:ROOT /PasswordO:* /Reset /TwoWay

Kommandon för att återställa förtroenden från den underordnade domänen PDC är följande:

netdom trust <Child Domain> /Domain:<Root Domain> /UserD:Root /PasswordD:* /UserO:Child /PasswordO:* /Reset /TwoWay

Orsak 4: För lång tidsförskjutning

Kerberos-principinställningar i standarddomänprincipen tillåter en fem minuters skillnad i systemtid (detta är standardvärdet) mellan KDC-domänkontrollanter och Kerberos-målservrar för att förhindra återuppspelningsattacker. I viss dokumentation står det att systemtiden för klienten och Kerberos-målet måste vara inom fem minuter från varandra. I annan dokumentation står det att den tid som är viktig i samband med Kerberos-autentisering är deltat mellan KDC som används av anroparen och tiden på Kerberos-målet. Kerberos bryr sig inte heller om systemtiden på de relevanta domänkontrollanterna matchar aktuell tid. Den bryr sig bara om att den relativa tidsskillnaden mellan KDC och måldomänkontrollanten ligger inom den maximala tidsförskjutning som Kerberos-principen tillåter. (Standardtiden är fem minuter eller mindre.)

I samband med Active Directory-åtgärder är målservern källdomänkontrollanten som kontaktas av måldomänkontrollanten. Varje domänkontrollant i en Active Directory-skog som för närvarande kör KDC-tjänsten är en potentiell KDC. Därför måste du överväga tidsnoggrannhet för alla andra domänkontrollanter mot källdomänkontrollanten. Detta inkluderar tid på själva måldomänkontrollanten.

Du kan använda följande två kommandon för att kontrollera tidsprecisionen:

  • DCDIAG /TEST:CheckSecurityError
  • W32TM /MONITOR

Du hittar exempelutdata från DCDIAG /TEST:CheckSecurityError i avsnittet "Mer information". Det här exemplet visar överdriven tidsförskjutning på Windows Server 2003-baserade och Windows Server 2008 R2-baserade domänkontrollanter.

Leta efter LSASRV 40960-händelser på måldomänkontrollanten vid tidpunkten för den misslyckade replikeringsbegäran. Leta efter händelser som citerar en GUID i CNAME-posten för källdomänkontrollanten med utökat fel 0xc000133. Leta efter händelser som liknar följande:

Tiden på den primära domänkontrollanten skiljer sig från tiden på säkerhetskopieringsdomänkontrollanten eller medlemsservern med för stor mängd

Nätverksspårningar som avbildar måldatorn som ansluter till en delad mapp på källdomänkontrollanten (och även andra åtgärder) kan visa felet "Ett utökat fel har inträffat" på skärmen, men en nätverksspårning visar följande:

–> KerberosV5 KerberosV5:TGS Request Realm: <– TGS-begäran från käll-DC
<– Kerberosvs Kerberosvs:KRB_ERROR – KRB_AP_ERR_TKE_NVV (33) <– TGS-svar där "KRB_AP_ERR_TKE_NYV
<- mappar till "Biljetten är ännu inte giltig" <– mappar till "Biljetten är inte giltig ännu"

Svaret TKE_NYV anger att datumintervallet för TGS-biljetten är nyare än tiden på målet. Detta indikerar överdriven tidsförskjutning.

Obs!

  • W32TM /MONITOR kontrollerar endast tiden på domänkontrollanter i domänen för testdatorer, så du måste köra detta i varje domän och jämföra tiden mellan domänerna.
  • När tidsskillnaden är för stor på Windows Server 2008 R2-baserade måldomänkontrollanter, replikerar du nu kommandot i DSSITE. MSC misslyckas med felet "Det finns en tids- och/eller datumskillnad mellan klienten och servern" på skärmen. Den här felsträngen mappar till fel 1398 decimal eller 0x576 hexadecimal med ERROR_TIME_SKEW symboliska felnamnet.

Mer information finns i Ställa in klocksynkroniseringstolerans för att förhindra återuppspelningsattacker.

Orsak 5: Det finns en ogiltig säkerhetskanal eller ett matchningsfel för lösenord på käll- eller måldomänkontrollanten

Verifiera säkerhetskanalen genom att köra något av följande kommandon:

  • nltest /sc:query
  • netdom verify

På villkor återställer du måldomänkontrollantens lösenord med hjälp av NETDOM /RESETPWD.

Lösning

  1. Inaktivera tjänsten Kerberos Key Distribution Center (KDC) på domänkontrollanten som startas om.

  2. Från konsolen för måldomänkontrollanten kör du NETDOM RESETPWD för att återställa lösenordet för måldomänkontrollanten på följande sätt:

    c:\>netdom resetpwd /server: server_name /userd: domain_name\administrator /passwordd: administrator_password

  3. Kontrollera att sannolika KDC:er och källdomänkontrollanten (om dessa finns i samma domän) inkommande replikeringskunskaper om måldomänkontrollantens nya lösenord.

  4. Starta om måldomänkontrollanten för att uppdatera Kerberos-biljetter och försök utföra replikeringsåtgärden igen.

Se Så här använder du Netdom.exe för att återställa lösenord för datorkonton för en domänkontrollant.

Orsak 6: Användarbehörigheten "Åtkomst till den här datorn från nätverket" beviljas inte till en användare som utlöser replikering

I en standardinstallation av Windows är standardprincipen för domänkontrollant länkad till domänkontrollantens organisationsenhet (OU). Organisationsenheten beviljar åtkomst till den här datorn från nätverksanvändare till följande säkerhetsgrupper:

Lokal princip Standardprincip för domänkontrollant
Administratörer Administratörer
Autentiserade användare Autentiserade användare
Alla Alla
Företagsdomänkontrollanter Företagsdomänkontrollanter
[Åtkomst som är kompatibel med för Windows 2000] För Windows 2000-kompatibel åtkomst

Om Active Directory-åtgärder misslyckas med fel 5 bör du kontrollera följande punkter:

  • Säkerhetsgrupper i tabellen beviljas åtkomst till den här datorn från nätverksanvändare direkt i standarddomänkontrollantens princip.
  • Domänkontrollantens datorkonton finns i domänkontrollantens organisationsenhet.
  • Standardprincipen för domänkontrollanten är länkad till domänkontrollantens organisationsenhet eller till alternativa organisationsenheter som är värd för datorkonton.
  • grupprincip tillämpas på måldomänkontrollanten som för närvarande loggar fel 5.
  • Behörigheten Neka åtkomst till den här datorn från nätverksanvändarrätt är aktiverad eller refererar inte till direkta eller transitiva grupper som säkerhetskontexten som används av domänkontrollanten eller användarkontot som utlöser replikering.
  • Principprioritet, blockerat arv, WMI-filtrering (Microsoft Windows Management Instrumentation) eller liknande hindrar inte principinställningen från att tillämpas på domänkontrollantrolldatorer.

Obs!

  • Principinställningar kan verifieras med RSOP. MSC-verktyget. GPRESULT /Z är dock det bästa verktyget eftersom det är mer exakt.
  • Den lokala principen har företräde framför en princip som definieras på webbplatser, domäner och organisationsenheten.
  • En gång i tiden var det vanligt att administratörer tar bort grupperna "Företagsdomänkontrollanter" och "Alla" från principinställningen "Åtkomst till den här datorn från nätverket" i standarddomänkontrollantens princip. Att ta bort båda grupperna är dock allvarligt. Det finns ingen anledning att ta bort "Enterprise-domänkontrollanter" från den här principinställningen, eftersom endast domänkontrollanter är medlemmar i den här gruppen.

Orsak 7: Det finns ett matchningsfel för SMB-signering mellan käll- och måldomänkontrollanterna

Sekretessinställning Registersökväg
Microsoft-nätverksklient: Signera kommunikation digitalt (om servern tillåter) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Enablesecuritysignature
Microsoft-nätverksklient: Signera kommunikation digitalt (alltid) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanworkstation\Parameters\Requiresecuritysignature
Microsoft-nätverksserver: Signera kommunikation digitalt (om servern tillåter) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Enablesecuritysignature
Microsoft-nätverksserver: Signera kommunikation digitalt (alltid) HKEY_LOCAL_MACHINE\SYSTEM\CCS\Services\Lanmanserver\Parameters\Requiresecuritysignature

Du bör fokusera på felmatchade SMB-signeringar mellan mål- och källdomänkontrollanterna. De klassiska fallen omfattar en inställning som är aktiverad eller obligatorisk på ena sidan men inaktiverad på den andra.

Orsak 8: UDP-formaterad Kerberos-paketfragmentering

Nätverksroutrar och växlar kan fragment eller helt släppa stora UDP-formaterade nätverkspaket (User Datagram Protocol) som används av Kerberos och tilläggsmekanismer för DNS (EDNS0). Datorer som kör Windows 2000 Server- eller Windows Server 2003-operativsystemfamiljer är särskilt sårbara för UDP-fragmentering på datorer som kör Windows Server 2008 eller Windows Server 2008 R2.

Lösning

  1. Från konsolen för måldomänkontrollanten pingar du källdomänkontrollanten med dess fullständigt kvalificerade datornamn för att identifiera det största paket som stöds av nätverksvägen. Det gör du genom att köra följande kommando:

    c:\>Ping <Source_DC_hostname>.<Fully_Qualified_Computer_Name> -f -l 1472

  2. Om det största icke-fragmenterade paketet är mindre än 1 472 byte kan du prova någon av följande metoder (i prioritetsordning):

    • Ändra nätverksinfrastrukturen så att den har lämpligt stöd för stora UDP-ramar. Detta kan kräva uppgradering av inbyggd programvara eller konfigurationsändring på routrar, växlar eller brandväggar.
    • Ange maxpacketsize (på måldomänkontrollanten) till det största paket som identifieras av ping-f -l-kommandot mindre än 8 byte för att ta hänsyn till TCP-huvudet och starta sedan om den ändrade domänkontrollanten.
    • Ange maxpacketsize (på måldomänkontrollanten) till värdet 1 Detta utlöser Kerberos-autentisering för att använda en TCP. Starta om den ändrade domänkontrollanten för att ändringen ska börja gälla.

  3. Försök igen med den misslyckade Active Directory-åtgärden.

Orsak 9: Nätverkskort har funktionen För stor avlastning aktiverad

Lösning

  1. Öppna nätverkskortsegenskaper på måldomänkontrollanten.
  2. Klicka på knappen Konfigurera .
  3. Välj fliken Avancerat.
  4. Inaktivera egenskapen IPv4 Large Send Offload .
  5. Starta om domänkontrollanten.

Orsak 10: Ogiltig Kerberos-sfär

Kerberos-sfären är ogiltig om ett eller flera av följande villkor är uppfyllda:

  • KDCNames-registerposten innehåller felaktigt det lokala Active Directory-domännamnet.
  • PolAcDmN-registernyckeln och PolPrDmN-registernyckeln matchar inte.

Lösningar

Viktigt

Följ stegen i det här avsnittet noggrant. Det kan uppstå allvarliga problem om du gör felaktiga ändringar i registret. Innan du ändrar det bör du först säkerhetskopiera registret för att kunna återställa det om problem skulle uppstå.

Lösning för fel KDCNames-registerpost

  1. Kör REGEDIT på måldomänkontrollanten.

  2. Leta upp följande undernyckel i registret: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Domains

  3. För varje <Fully_Qualified_Domain> under undernyckeln kontrollerar du att värdet för KdcNames-registerposten refererar till en giltig extern Kerberos-sfär och inte till den lokala domänen eller en annan domän i samma Active Directory-skog.

Lösning för matchning av PolAcDmN- och PolPrDmN-registernycklar

Obs!

Den här metoden är endast giltig för domänkontrollanter som kör Windows 2000 Server.

  1. Starta Registereditorn.

  2. I navigeringsfönstret expanderar du Säkerhet.

  3. På menyn Säkerhet klickar du på Behörigheter för att ge den lokala gruppen Administratörer fullständig kontroll över säkerhetsdatafilen och dess underordnade containrar och objekt.

  4. Leta upp följande undernyckel i registret:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolPrDmN

  5. I fönstret till höger i Registereditorn klickar du på posten Inget namn: REG_NONE registerpost en gång.

  6. På menyn Visa klickar du på Visa binära data.

  7. I avsnittet Format i dialogrutan klickar du på Byte.

    Domännamnet visas som en sträng till höger i dialogrutan Binära data . Domännamnet är samma som Kerberos-sfären.

  8. Leta upp följande undernyckel i registret:
    HKEY_LOCAL_MACHINE\SECURITY\Policy\PolACDmN

  9. Dubbelklicka på posten Inget namn: REG_NONE i den högra rutan i Registereditorn.

  10. I dialogrutan Binär redigerare klistrar du in värdet från registerundernyckeln PolPrDmN. (Värdet från registerundernyckeln PolPrDmN är NetBIOS-domännamnet).

  11. Starta om domänkontrollanten. Om domänkontrollanten inte fungerar korrekt kan du läsa andra metoder.

Orsak 11: Det finns ett kompatibilitetsfel för LAN Manager (LM-kompatibilitet) mellan käll- och måldomänkontrollanterna

Orsak 12: Tjänstens huvudnamn är antingen inte registrerade eller finns inte på grund av enkel replikeringsfördröjning eller ett replikeringsfel

Orsak 13: Antivirusprogram använder en filtreringsdrivrutin för minibrandväggsnätverkskort på käll- eller måldomänkontrollanten

Status

Microsoft har bekräftat att det är ett problem i de Microsoft-produkter som listas i avsnittet "Gäller för".

Mer information

Active Directory-fel och händelser som de som beskrivs i avsnittet "Symptom" kan också misslyckas med fel 8453 tillsammans med följande, liknande felsträng:

Replikeringsåtkomst nekades.

Följande situationer kan orsaka att Active Directory-åtgärder misslyckas med fel 8453. Dessa situationer orsakar dock inte fel med fel 5.

  • Namnkontexthuvud (NC) tillåts inte med behörigheten Replikera katalogändringar.
  • Säkerhetsobjektet som startar replikeringen är inte medlem i en grupp som beviljas behörigheten Replikera katalogändringar.
  • Flaggor saknas i attributet UserAccountControl. Dessa inkluderar flaggan SERVER_TRUST_ACCOUNT och flaggan TRUSTED_FOR_DELEGATION.
  • Den skrivskyddade domänkontrollanten (RODC) är ansluten till domänen utan att ADPREP /RODCPREP kommandot körs först.

Exempel på utdata från DCDIAG /TEST:CheckSecurityError

Exempel på DCDIAG /test:CHECKSECURITYERROR-utdata från en Windows Server 2008 R2-domänkontrollant följer. Dessa utdata orsakas av för hög tidsförskjutning.

Utföra primära tester Testserver: <Site_Name>\<Destination_DC_Name> Starttest: CheckSecurityError
Käll-DC-källdomänkontrollanten <> har ett möjligt säkerhetsfel (1398).
Diagnostisera...
Tidsförskjutningsfel mellan klienten och 1 domänkontrollanter! ERROR_ACCESS_DENIED
eller ned-dator som tagits emot av:
<Käll-DC> [<Source DC>] DsBindWithSpnEx() misslyckades med fel 1398,
Det finns en tids- och/eller datumskillnad mellan klienten och servern..
Ignorera DC-käll-DC <> i konvergenstestet av objektet
CN=<Destination_DC,OU>=Domain Controllers,DC=<DomainName,DC>=com, eftersom vi
kan inte ansluta!
......................... <> Destination_DC misslyckade testet CheckSecurityError

Exempel på DCDIAG /CHECKSECURITYERROR-utdata från en Windows Server 2003-baserad domänkontrollant följer. Detta orsakas av överdriven tidsförskjutning.

Utföra primära tester
Testserver: <Site_Name>\<Destination_DC_Name>
Starttest: CheckSecurityError
Käll-DC-källdomänkontrollanten <>har ett möjligt säkerhetsfel (5). Diagnostisera...
Tidsförskjutningsfel mellan klienten och 1 domänkontrollanter! ERROR_ACCESS_DENIED eller ned dator som tagits emot av: <Käll-DC>
<Dc-källdomänkontrollant>_has möjligt säkerhetsfel (5). Diagnostisera...
Tidsförskjutningsfel: 7 205 sekunder skiljer sig mellan:.
<Käll-DC>
<Destination_DC>
[<Source DC>] DsBindWithSpnEx() misslyckades med fel 5,
Åtkomst nekas..
Ignorera DC <Source DC>i konvergenstestet av objektet CN=<Destination_DC,OU>=Domain Controllers,DC=<DomainName,DC>=com, eftersom vi inte kan ansluta!
......................... <>Destination_DC misslyckade testet CheckSecurityError

Exempel på DCDIAG /CHECKSECURITYERROR-utdata följer. Den visar saknade SPN-namn. (Utdata kan variera från miljö till miljö.)

Utföra primära tester
Testserver: <platsnamn>\<dc-namn>
Test utelämnas av användarbegäran: Annonsering
Starttest: CheckSecurityError
* Dr Auth: Påbörjar säkerhetsfelkontroll"
KDC KDC <DC> hittades för domän-DNS-namnet <på AD-domänen> i platsplatsnamnet <>
Kontrollera datorkontot för DC <DC-namn> på DC <DC-namn>
* SPN saknas:LDAP/<värdnamn>.<DNS-domännamn>/<DNS-domännamn>
* SPN saknas:LDAP/<värdnamn>.<DNS-domännamn>
* SPN saknas:LDAP/<värdnamn>
* SPN saknas:LDAP/<värdnamn>.<DNS-domännamn>/<NetBIOS-domännamn>
* SPN saknas:LDAP/bba727ef-be4e-477d-9796-63b6cee3bSf.<skogsrotsdomän DN>
* SPN hittade :E3514235-4B06-I1D1-ABØ4-00c04fc2dcd2/<NTDS Inställningsobjekt GUID>/<skogsrotdomänens DNS-namn>
* SPN saknas:HOST/<hostname>.<DNS-domännamn>/<DNS-domännamn>
* SPN hittade :HOST/<hostname>.<DNS-domännamn>
* SPN hittades :HOST/<hostname>
* SPN saknas:HOST/<hostname>.<DNS-domännamn>/<NetBIOS-domännamn>
* SPN saknas:GC/<värdnamn>.<DNS-domännamn>/<DNS-domännamn> Det går inte att verifiera datorkontot (<DN-sökvägen för dc-datorkontot>) för <DC-namn> på <domänkontrollantens namn>.

Datainsamling

Om du behöver hjälp från Microsofts support rekommenderar vi att du samlar in informationen genom att följa stegen i Samla in information med hjälp av TSS för Active Directory-replikeringsproblem.