Domänförtroendet bröts efter en månad offline? Kontrollera först

En bärbar dator står utanför VPN i sex veckor, kommer tillbaka, och användaren kan inte logga in med ett domänkonto. Felet nämner en förtroenderelation, så någon återställer datorkontot, eller tvingar användaren till full tunneling, och problemet verkar försvinna. Ingen av åtgärderna bevisade vad som var trasigt. En Windows-medlem kan vara offline långt över det vanliga maskinlösenordsintervallet utan att automatiskt förlora förtroendet, så den första uppgiften är att skilja ett nåbarhetsfel från en verklig avvikelse i hemligheten.

Felet ser ut som förtroende, men tre tillstånd ser likadana ut

En användare kan logga in med cachelagrade domänuppgifter, arbetsstationen kanske inte hittar någon domänkontrollant, eller så kan medlemmen och domänen faktiskt vara oense om datorkontot. Bara det tredje är en bruten förtroenderelation i strikt mening.

AD-replikeringens hälsa är en fjärde observation, och den handlar inte alls om den här arbetsstationen. Den beskriver enighet mellan domänkontrollanter, och en frisk replikeringspanel bevisar inte att den här maskinens lokala hemlighet matchar dess datorkonto.

Det välkända standardvärdet på 30 dagar är en ändringspolicy, inte en utgångsdeadline offline. Microsofts förklaring av maskinkontots lösenord beskriver en samordnad ändringsprocess, och en organisation kan konfigurera ett annat intervall.

En VPN-ikon bevisar ingenting om den säkra kanalen

Anslutningen måste vara tillräckligt bra för att nå domäntjänster innan något test betyder något. Det innebär den avsedda DNS-upplösaren för domänen, en kontrollant som går att hitta, nåbara autentiseringstjänster och en klocka som ligger tillräckligt nära för Kerberos.

Full tunneling kan vara en helt giltig design här. Att byta till delad tunneling är ingen förutsättning för en frisk domänrelation, och att behandla det som en gör en diagnos till en arkitekturändring. Kontrollera vilken kontrollant arbetsstationen faktiskt väljer, och spara namnet tillsammans med felet.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Anteckna DNS-servern, den upplösta kontrollanten och den exakta feltexten. En VPN-klient som rapporterar ansluten säger att tunneln finns, inte att domänvägen fungerar. En kontrollant som svarar på Kerberos-porten men inte på katalogporten är ett brandväggsfynd, inte ett förtroendefynd.

Testa medlemmen innan du reparerar den

På en auktoriserad Windows-domänmedlem är Test-ComputerSecureChannel -Verbose en skrivskyddad kontroll av kanalen mellan maskinen och domänen. Kör den i den maskinkontext du undersöker, inte från en domänkontrollant, som har en annan roll och andra återställningsregler. Spara utdata och slutstatus i stället för ordet godkänd eller misslyckad. Om cmdleten saknas i den versionen är modulen ett separat problem.

Resultatet behöver fortfarande sammanhang. Om maskinen inte kan nå eller autentisera mot den valda kontrollanten är ett misslyckat test inte ett oberoende bevis för att ett offlinelösenord har gått ut. Spara det faktiska felet och den använda kontrollanten, och upprepa testet när vägen är känd som god.

Korrelera Netlogon-händelser på medlemmen och på den relevanta kontrollanten kring incidenten. Bevara maskinnamnet, källadressen, tiden och varje bevis på kontobyte. En annan användares lyckade inloggning, eller en frisk kontrollantpanel, kan inte ersätta den här maskinens utbyte.

Reparera bara den relation du har bevisat

När anslutningen är stabil och en administratör har bekräftat att en reparation är lämplig, är cmdletens -Repair-läge med auktoriserade autentiseringsuppgifter en enda stödd åtgärd för en medlemsarbetsstation. Det ändrar relationen, och det är inte ännu ett skrivskyddat test.

Håll ett godkänt lokalt återställningskonto och en administrationsväg tillgängliga före ändringen. Domänkontrollanter har en annan återställningsroll och får inte behandlas som vanliga arbetsstationer av den här proceduren. Använd organisationens återställningsflöde i stället för att köra flera återställningsverktyg efter varandra och hoppas att ett av dem är det rätta.

Efter reparationen, verifiera ett nytt test av den säkra kanalen och den ursprungliga domänåtgärden. Bevara användarprofiler och applikationstillstånd, och gör inte borttagning-och-återanslutning till den första oförklarade åtgärden.

Vad du bör kontrollera när felet återkommer

Om felet återkommer, titta på återställning, dubbel identitet och tidpunkten för kontoändringar i stället för att återställa samma konto igen. En återställd avbildning, en ögonblicksbild, en klonad maskinidentitet eller en datorkontoåterställning som gjorts någon annanstans förtjänar alla utredning.

En tillfälligt lyckad återställning är ett användbart återställningsbevis, men det är inte bevis för att ett intermittent VPN orsakade den ursprungliga avvikelsen. Nästa förekomst är den som talar om ifall orsaken någonsin togs bort.

Skriv kontrollanten, DNS-servern och testutdata i ärendet. Den anteckningen är det som skiljer ett verkligt förtroendefel från en bärbar dator som helt enkelt inte hittade domänen.