Mistede domænetilliden efter en måned offline? Tjek først

En bærbar computer ligger uden for VPN i seks uger, kommer tilbage, og brugeren kan ikke logge ind med en domænekonto. Fejlen nævner et tillidsforhold, så nogen nulstiller computerkontoen eller tvinger brugeren over på fuld tunneling, og problemet ser ud til at forsvinde. Ingen af de to handlinger beviste, hvad der var i stykker. Et Windows-medlem kan være offline langt ud over det sædvanlige maskinadgangskodeinterval uden automatisk at miste tillid, så den første opgave er at skelne en tilgængelighedsfejl fra en egentlig uoverensstemmelse i hemmeligheden.

Fejlen ligner tillid, men tre tilstande ser ens ud

En bruger kan logge ind med cachelagrede domæneoplysninger, arbejdsstationen kan ikke finde en domænecontroller, eller medlemmet og domænet kan reelt være uenige om computerkontoen. Kun den tredje er et brudt tillidsforhold i streng forstand.

Tilstanden af AD-replikering er en fjerde observation, og den handler slet ikke om denne arbejdsstation. Den beskriver enighed mellem domænecontrollere, og et sundt replikeringsdashboard beviser ikke, at denne maskines lokale hemmelighed matcher dens computerkonto.

Den velkendte standard på 30 dage er en ændringspolitik, ikke en offline-udløbsfrist. Microsofts forklaring af maskinkontoens adgangskode beskriver en koordineret ændringsproces, og en organisation kan konfigurere et andet interval.

Et VPN-ikon beviser intet om den sikre kanal

Forbindelsen skal være god nok til at nå domænetjenester, før nogen test betyder noget. Det betyder den tilsigtede DNS-resolver for domænet, en controller der kan findes, tilgængelige godkendelsestjenester og et ur, der er tæt nok på til Kerberos.

Fuld tunneling kan være et helt gyldigt design her. At skifte til delt tunneling er ikke en forudsætning for et sundt domæneforhold, og at behandle det som en gør en diagnose til en arkitekturændring. Tjek, hvilken controller arbejdsstationen faktisk vælger, og gem det navn sammen med fejlen.

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

Noter DNS-serveren, den opløste controller og den præcise fejltekst. En VPN-klient, der rapporterer, at den er forbundet, fortæller dig, at tunnelen findes, ikke at domænevejen virker. En controller, der svarer på Kerberos-porten, men ikke på katalogporten, er et firewall-fund, ikke et tillidsfund.

Test medlemmet, før du reparerer det

På et autoriseret Windows-domænemedlem er Test-ComputerSecureChannel -Verbose en skrivebeskyttet kontrol af kanalen mellem maskinen og domænet. Kør den i den maskinekontekst, du undersøger, ikke fra en domænecontroller, som har en anden rolle og andre gendannelsesregler. Gem outputtet og exitstatus i stedet for ordet bestået eller fejlet. Hvis cmdletten mangler i den build, er modulet et separat problem.

Resultatet kræver stadig kontekst. Hvis maskinen ikke kan nå eller godkende over for den valgte controller, er en mislykket test ikke et uafhængigt bevis på, at en offline adgangskode er udløbet. Gem den faktiske fejl og den anvendte controller, og gentag testen, når vejen er kendt god.

Korrelér Netlogon-hændelser på medlemmet og på den relevante controller omkring hændelsen. Bevar maskinnavnet, kildeadressen, tidspunktet og enhver dokumentation for kontoskift. En anden brugers vellykkede login eller et sundt controller-dashboard kan ikke erstatte denne maskines udveksling.

Reparer kun det forhold, du har bevist

Når forbindelsen er stabil, og en administrator har bekræftet, at en reparation er passende, er cmdletens -Repair-tilstand med autoriserede legitimationsoplysninger én understøttet handling for en medlemsarbejdsstation. Den ændrer forholdet og er ikke endnu en skrivebeskyttet test.

Hold en godkendt lokal gendannelseskonto og en administrationsvej klar før ændringen. Domænecontrollere har en anden gendannelsesrolle og må ikke behandles som almindelige arbejdsstationer af denne procedure. Brug organisationens gendannelsesarbejdsgang i stedet for at køre flere nulstillingsværktøjer efter hinanden og håbe på, at et af dem er det rigtige.

Efter reparationen skal du bekræfte en ny test af den sikre kanal og den oprindelige domænehandling. Bevar brugerprofiler og applikationstilstand, og gør ikke fjern-og-genindmeld til den første uforklarede handling.

Hvad du skal tjekke, når fejlen vender tilbage

Hvis fejlen kommer tilbage, så se på tilbagerulning, dobbelt identitet og tidspunktet for kontoændringer i stedet for at nulstille den samme konto igen. Et gendannet billede, et snapshot, en klonet maskinidentitet eller en computerkonto-nulstilling udført andre steder fortjener alle undersøgelse.

En midlertidig vellykket nulstilling er nyttig dokumentation for gendannelse, men det er ikke bevis for, at en periodisk VPN forårsagede den oprindelige uoverensstemmelse. Den næste forekomst er den, der fortæller dig, om årsagen nogensinde blev fjernet.

Skriv controlleren, DNS-serveren og testoutputtet i sagen. Den registrering er det, der skelner en egentlig tillidsfejl fra en bærbar computer, der simpelthen ikke kunne finde domænet.