Încrederea domeniului a eșuat după o lună offline? Verificați mai întâi

Un laptop stă șase săptămâni în afara VPN, revine, iar utilizatorul nu se poate autentifica cu un cont de domeniu. Eroarea menționează o relație de încredere, așa că cineva resetează contul de computer, sau forțează utilizatorul pe tunel complet, iar problema pare să dispară. Niciuna dintre acțiuni nu a dovedit ce era stricat. Un membru Windows poate rămâne offline mult peste intervalul obișnuit al parolei mașinii fără a pierde automat încrederea, deci prima sarcină este să separi o defecțiune de accesibilitate de o nepotrivire reală a secretului.

Eroarea arată ca încredere, dar trei stări se aseamănă

Un utilizator poate să se autentifice cu informații de domeniu din cache, stația de lucru poate să nu găsească un controler de domeniu, sau membrul și domeniul pot să nu fie într-adevăr de acord cu privire la contul de computer. Doar al treilea este o relație de încredere ruptă în sens strict.

Starea replicării AD este o a patra observație și nu are nicio legătură cu această stație de lucru. Descrie acordul dintre controlerele de domeniu, iar un panou de replicare sănătos nu dovedește că secretul local al acestei mașini corespunde contului ei de computer.

Valoarea implicită cunoscută de 30 de zile este o politică de schimbare, nu un termen de expirare offline. Explicația Microsoft despre parola contului de mașină descrie un proces de schimbare coordonat, iar o organizație poate configura un alt interval.

O pictogramă VPN nu dovedește nimic despre canalul securizat

Conectivitatea trebuie să fie suficient de bună pentru a ajunge la serviciile de domeniu înainte ca vreun test să însemne ceva. Asta înseamnă resolverul DNS de domeniu prevăzut, un controler localizabil, servicii de autentificare accesibile și un ceas suficient de aproape pentru Kerberos.

Tunelul complet poate fi un design perfect valid aici. Trecerea la tunel divizat nu este o condiție prealabilă pentru o relație de domeniu sănătoasă, iar tratarea lui ca atare transformă un diagnostic într-o schimbare de arhitectură. Verificați ce controler alege de fapt stația de lucru și păstrați acel nume împreună cu eroarea.

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

Notați serverul DNS, controlerul rezolvat și textul exact al erorii. Un client VPN care raportează conectat vă spune că tunelul există, nu că calea către domeniu funcționează. Un controler care răspunde pe portul Kerberos dar nu pe portul de director este o constatare de firewall, nu una de încredere.

Testați membrul înainte de a-l repara

Pe un membru de domeniu Windows autorizat, Test-ComputerSecureChannel -Verbose este o verificare doar-citire a canalului dintre mașină și domeniu. Rulați-o în contextul mașinii pe care o investigați, nu de pe un controler de domeniu, care are alt rol și alte reguli de recuperare. Înregistrați ieșirea și starea de ieșire în locul cuvântului trecut sau eșuat. Dacă cmdletul lipsește în acea compilare, modulul este o problemă separată.

Rezultatul are încă nevoie de context. Dacă mașina nu poate ajunge la controlerul ales sau nu se poate autentifica la el, un test eșuat nu este o dovadă independentă că o parolă offline a expirat. Păstrați eroarea reală și controlerul folosit, și repetați testul când calea este cunoscută ca bună.

Corelați evenimentele Netlogon pe membru și pe controlerul relevant în jurul incidentului. Păstrați numele mașinii, adresa sursă, ora și orice dovadă a schimbării contului. O autentificare reușită a altui utilizator, sau un panou de controler sănătos, nu pot înlocui schimbul acestei mașini.

Reparați doar relația pe care ați dovedit-o

Odată ce conectivitatea este stabilă și un administrator a confirmat că o reparație este potrivită, modul -Repair al cmdletului cu acreditări autorizate este o operațiune acceptată pentru o stație de lucru membru. Schimbă relația și nu este un alt test doar-citire.

Țineți disponibile un cont local de recuperare aprobat și o cale de administrare înainte de schimbare. Controlerele de domeniu au un alt rol de recuperare, iar această procedură nu trebuie să le trateze ca stații de lucru obișnuite. Folosiți fluxul de recuperare al organizației în loc să rulați mai multe instrumente de resetare în succesiune și să sperați că unul dintre ele este cel corect.

După reparație, verificați un test nou al canalului securizat și operația de domeniu originală. Păstrați profilurile utilizatorilor și starea aplicațiilor, și nu faceți din eliminare-și-realăturare prima acțiune neexplicată.

Ce de verificat când defecțiunea revine

Dacă defecțiunea revine, priviți revenirea, identitatea duplicată și momentul schimbărilor de cont, în loc să resetați din nou același cont. O imagine restaurată, un instantaneu, o identitate de mașină clonată sau o resetare de cont de computer făcută în altă parte merită toate o investigație.

O resetare reușită temporar este o dovadă de recuperare utilă, dar nu este dovada că un VPN intermitent a cauzat nepotrivirea inițială. Următoarea apariție este cea care vă spune dacă cauza a fost vreodată înlăturată.

Scrieți controlerul, serverul DNS și ieșirea testului în tichet. Acea înregistrare este cea care distinge o defecțiune reală de încredere de un laptop care pur și simplu nu a putut găsi domeniul.