Mista domenetilliten etter ein månad offline? Sjekk først

Ein berbar PC står utanfor VPN i seks veker, kjem tilbake, og brukaren kan ikkje logge på med ein domenekonto. Feilen nemner eit tillitsforhold, så nokon nullstiller datamaskinkontoen, eller tvingar brukaren over på full tunneling, og problemet ser ut til å forsvinne. Ingen av dei to handlingane prova kva som var øydelagt. Eit Windows-medlem kan vere offline langt utover det vanlege maskinpassordintervallet utan å miste tillit automatisk, så den første jobben er å skilje ein tilgjengefeil frå ein ekte usemje om hemmelegheita.

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

Ein brukar kan logge på med hurtiglagra domenopplysningar, arbeidsstasjonen kan ikkje finne ein domenekontrollar, eller medlemmet og domenet kan faktisk vere usamde om datamaskinkontoen. Berre den tredje er eit brote tillitsforhold i streng forstand.

Helsetilstanden til AD-replikering er ein fjerde observasjon, og han handlar ikkje om denne arbeidsstasjonen i det heile. Han skildrar semje mellom domenekontrollarar, og eit sunt replikeringsdashbord provar ikkje at den lokale hemmelegheita til denne maskina svarar til datamaskinkontoen.

Den kjende standarden på 30 dagar er ein endringspolicy, ikkje ein utløpsfrist offline. Microsofts forklaring av passordet til maskinkontoen skildrar ein koordinert endringsprosess, og ein organisasjon kan setje opp eit anna intervall.

Eit VPN-ikon provar ingenting om den sikre kanalen

Tilkoplinga må vere god nok til å nå domenetenester før nokon test tyder noko. Det tyder den tiltenkte DNS-oppløysaren for domenet, ein kontrollar som kan finnast, tilgjengelege autentiseringstenester og ei klokke som er nær nok for Kerberos.

Full tunneling kan vere eit heilt gyldig design her. Å byte til delt tunneling er ikkje ein føresetnad for eit sunt domeneforhold, og å handsame det som ein gjer ein diagnose om til ei arkitekturendring. Sjekk kva kontrollar arbeidsstasjonen faktisk vel, og ta vare på namnet saman med feilen.

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

Noter DNS-tenaren, den oppløyste kontrollaren og den nøyaktige feilteksten. Ein VPN-klient som rapporterer tilkopla, fortel deg at tunnelen finst, ikkje at domenestien verkar. Ein kontrollar som svarar på Kerberos-porten men ikkje på katalogporten, er eit brannmurfunne, ikkje eit tillitsfunne.

Test medlemmet før du reparerer det

På eit autorisert Windows-domenemedlem er Test-ComputerSecureChannel -Verbose ein skriveverna kontroll av kanalen mellom maskina og domenet. Køyr han i maskinkonteksten du undersøkjer, ikkje frå ein domenekontrollar, som har ei anna rolle og andre gjenopprettingsreglar. Ta vare på utdata og avslutningsstatus i staden for ordet bestått eller mislukkast. Viss cmdleten manglar i den builden, er modulen eit eige problem.

Resultatet treng framleis kontekst. Viss maskina ikkje kan nå eller autentisere mot den valde kontrollaren, er ein mislukka test ikkje eit uavhengig prov på at eit offline-passord har gått ut. Ta vare på den faktiske feilen og kontrollaren som vart brukt, og gjenta testen når stien er kjend god.

Korreler Netlogon-hendingar på medlemmet og på den relevante kontrollaren rundt hendinga. Ta vare på maskinnamnet, kjeldeadressa, tidspunktet og all dokumentasjon av kontobytte. Ei vellukka pålogging frå ein annan brukar, eller eit sunt kontrollardashbord, kan ikkje erstatte utvekslinga til denne maskina.

Reparer berre forholdet du har prova

Når tilkoplinga er stabil og ein administrator har stadfesta at ein reparasjon er høveleg, er -Repair-modusen til cmdleten med autoriserte legitimasjonar éin støtta operasjon for ein medlemsarbeidsstasjon. Han endrar forholdet, og han er ikkje nok ein skriveverna test.

Hald ein godkjend lokal gjenopprettingskonto og ein administrasjonssti klar før endringa. Domenekontrollarar har ei anna gjenopprettingsrolle og må ikkje handsamast som vanlege arbeidsstasjonar av denne prosedyren. Bruk gjenopprettingsflyten til organisasjonen i staden for å køyre fleire nullstillingsverktøy etter kvarandre og håpe at eitt av dei er det rette.

Etter reparasjonen, stadfest ein ny test av den sikre kanalen og den opphavlege domenoperasjonen. Ta vare på brukarprofilar og tilstanden til program, og gjer ikkje fjerning-og-nytilkopling til den første uforklarte handlinga.

Kva du bør sjekke når feilen kjem tilbake

Viss feilen kjem tilbake, sjå på tilbakerulling, dobbel identitet og tidspunktet for kontoendringar i staden for å nullstille den same kontoen igjen. Eit gjenoppretta avbilete, eit augeblinksbilete, ein klona maskinidentitet eller ein datamaskinkonto-nullstilling gjort ein annan stad fortener alle undersøking.

Ein mellombels vellukka nullstilling er nyttig gjenopprettingsprov, men det er ikkje prov på at eit periodisk VPN valda den opphavlege usemja. Den neste førekomsten er den som fortel deg om årsaka nokon gong vart fjerna.

Skriv kontrollaren, DNS-tenaren og testutdata i saka. Den registreringa er det som skil ein ekte tillitsfeil frå ein berbar PC som rett og slett ikkje fann domenet.