Mistet domenetilliten etter en måned offline? Sjekk først

En bærbar PC står utenfor VPN i seks uker, kommer tilbake, og brukeren kan ikke logge på med en domenekonto. Feilen nevner et tillitsforhold, så noen tilbakestiller datamaskinkontoen, eller tvinger brukeren over på full tunneling, og problemet ser ut til å forsvinne. Ingen av de to handlingene beviste hva som var ødelagt. Et Windows-medlem kan være offline langt utover det vanlige maskinpassordintervallet uten å miste tillit automatisk, så den første jobben er å skille en tilgjengelighetsfeil fra en ekte uoverensstemmelse i hemmeligheten.

Feilen ser ut som tillit, men tre tilstander ser like ut

En bruker kan logge på med hurtiglagrede domenopplysninger, arbeidsstasjonen kan ikke finne en domenekontroller, eller medlemmet og domenet kan faktisk være uenige om datamaskinkontoen. Bare den tredje er et brutt tillitsforhold i streng forstand.

Helsetilstanden til AD-replikering er en fjerde observasjon, og den handler ikke om denne arbeidsstasjonen i det hele tatt. Den beskriver enighet mellom domenekontrollere, og et sunt replikeringsdashbord beviser ikke at denne maskinens lokale hemmelighet samsvarer med datamaskinkontoen.

Den kjente standarden på 30 dager er en endringspolicy, ikke en utløpsfrist offline. Microsofts forklaring av maskinkontoens passord beskriver en koordinert endringsprosess, og en organisasjon kan konfigurere et annet intervall.

Et VPN-ikon beviser ingenting om den sikre kanalen

Tilkoblingen må være god nok til å nå domenetjenester før noen test betyr noe. Det betyr den tiltenkte DNS-oppløseren for domenet, en kontroller som kan finnes, tilgjengelige autentiseringstjenester og en klokke som er nær nok for Kerberos.

Full tunneling kan være et helt gyldig design her. Å bytte til delt tunneling er ikke en forutsetning for et sunt domeneforhold, og å behandle det som en gjør en diagnose om til en arkitekturendring. Sjekk hvilken kontroller arbeidsstasjonen faktisk velger, og ta vare på navnet sammen med feilen.

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

Noter DNS-serveren, den oppløste kontrolleren og den nøyaktige feilteksten. En VPN-klient som rapporterer tilkoblet, forteller deg at tunnelen finnes, ikke at domenestien virker. En kontroller som svarer på Kerberos-porten men ikke på katalogporten, er et brannmurfunne, ikke et tillitsfunne.

Test medlemmet før du reparerer det

På et autorisert Windows-domenemedlem er Test-ComputerSecureChannel -Verbose en skrivebeskyttet kontroll av kanalen mellom maskinen og domenet. Kjør den i maskinkonteksten du undersøker, ikke fra en domenekontroller, som har en annen rolle og andre gjenopprettingsregler. Ta vare på utdataene og avslutningsstatusen i stedet for ordet bestått eller mislyktes. Hvis cmdleten mangler i den builden, er modulen et eget problem.

Resultatet trenger fortsatt kontekst. Hvis maskinen ikke kan nå eller autentisere mot den valgte kontrolleren, er en mislykket test ikke et uavhengig bevis på at et offline-passord har utløpt. Ta vare på den faktiske feilen og kontrolleren som ble brukt, og gjenta testen når stien er kjent god.

Korreler Netlogon-hendelser på medlemmet og på den relevante kontrolleren rundt hendelsen. Bevar maskinnavnet, kildeadressen, tidspunktet og enhver dokumentasjon av kontobytte. En annen brukers vellykkede pålogging, eller et sunt kontrollerdashbord, kan ikke erstatte denne maskinens utveksling.

Reparer bare forholdet du har bevist

Når tilkoblingen er stabil og en administrator har bekreftet at en reparasjon er passende, er cmdletens -Repair-modus med autoriserte legitimasjoner én støttet operasjon for en medlemsarbeidsstasjon. Den endrer forholdet, og den er ikke nok en skrivebeskyttet test.

Hold en godkjent lokal gjenopprettingskonto og en administrasjonssti klar før endringen. Domenekontrollere har en annen gjenopprettingsrolle og må ikke behandles som vanlige arbeidsstasjoner av denne prosedyren. Bruk organisasjonens gjenopprettingsflyt i stedet for å kjøre flere tilbakestillingsverktøy etter hverandre og håpe at ett av dem er det riktige.

Etter reparasjonen, verifiser en ny test av den sikre kanalen og den opprinnelige domenoperasjonen. Bevar brukerprofiler og applikasjonstilstand, og ikke gjør fjerning-og-nytilkobling til den første uforklarte handlingen.

Hva du bør sjekke når feilen kommer tilbake

Hvis feilen kommer tilbake, se på tilbakerulling, dobbel identitet og tidspunktet for kontoendringer i stedet for å tilbakestille den samme kontoen igjen. Et gjenopprettet avbilde, et øyeblikksbilde, en klonet maskinidentitet eller en datamaskinkonto-tilbakestilling gjort et annet sted fortjener alle undersøkelse.

En midlertidig vellykket tilbakestilling er nyttig gjenopprettingsbevis, men det er ikke bevis for at et periodisk VPN forårsaket den opprinnelige uoverensstemmelsen. Den neste forekomsten er den som forteller deg om årsaken noen gang ble fjernet.

Skriv kontrolleren, DNS-serveren og testutdataene i saken. Den registreringen er det som skiller en ekte tillitsfeil fra en bærbar PC som rett og slett ikke fant domenet.