Domēna uzticēšanās sabojājās pēc mēneša bezsaistē? Vispirms pārbaudiet

Klēpjdators sešas nedēļas atrodas ārpus VPN, atgriežas, un lietotājs nevar pieteikties ar domēna kontu. Kļūda piemin uzticēšanās attiecības, tāpēc kāds atiestata datora kontu vai piespiež lietotāju uz pilnu tuneli, un problēma it kā pazūd. Neviens no abiem pasākumiem nepierādīja, kas bija salūzis. Windows dalībnieks var palikt bezsaistē krietni ilgāk par ierasto mašīnas paroles intervālu un automātiski nezaudēt uzticēšanos, tāpēc pirmais uzdevums ir atdalīt sasniedzamības kļūmi no īstas noslēpuma neatbilstības.

Kļūda izskatās pēc uzticēšanās, bet trīs stāvokļi ir līdzīgi

Lietotājs var pieteikties ar kešatmiņā saglabātu domēna informāciju, darbstacija var neatrast domēna kontrolieri, vai dalībnieks un domēns var patiešām nesaskanēt par datora kontu. Tikai trešais ir salauztas uzticēšanās attiecības stingrā nozīmē.

AD replikācijas veselība ir ceturtais novērojums, un tas nemaz neattiecas uz šo darbstaciju. Tas apraksta vienošanos starp domēna kontrolieriem, un veselīgs replikācijas panelis nepierāda, ka šīs mašīnas vietējais noslēpums atbilst tās datora kontam.

Pazīstamā 30 dienu noklusējuma vērtība ir maiņas politika, nevis bezsaistes derīguma termiņš. Microsoft skaidrojums par mašīnas konta paroli apraksta koordinētu maiņas procesu, un organizācija var konfigurēt citu intervālu.

VPN ikona neko nepierāda par drošo kanālu

Savienojumam jābūt pietiekami labam, lai sasniegtu domēna pakalpojumus, pirms jebkurš tests kaut ko nozīmē. Tas nozīmē paredzēto domēna DNS atrisinātāju, atrodamu kontrolieri, sasniedzamus autentifikācijas pakalpojumus un Kerberos pietiekami tuvu pulksteni.

Pilns tunelis šeit var būt pilnīgi pamatots risinājums. Pāreja uz sadalītu tuneli nav veselīgu domēna attiecību priekšnoteikums, un tā uzskatīšana par tādu pārvērš diagnozi arhitektūras maiņā. Pārbaudiet, kuru kontrolieri darbstacija patiešām izvēlas, un saglabājiet šo nosaukumu kopā ar kļūdu.

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

Pierakstiet DNS serveri, atrisināto kontrolieri un precīzo kļūdas tekstu. VPN klients, kas ziņo par savienojumu, pasaka, ka tunelis pastāv, nevis ka domēna ceļš darbojas. Kontrolieris, kas atbild uz Kerberos portu, bet ne uz kataloga portu, ir ugunsmūra atradums, nevis uzticēšanās atradums.

Pārbaudiet dalībnieku pirms tā labošanas

Autorizētā Windows domēna dalībniekā Test-ComputerSecureChannel -Verbose ir tikai lasāma pārbaude kanālam starp mašīnu un domēnu. Palaidiet to pētāmās mašīnas kontekstā, nevis no domēna kontroliera, kuram ir cita loma un citi atjaunošanas noteikumi. Fiksējiet izvadi un iziešanas statusu, nevis vārdu izdevās vai neizdevās. Ja šajā būvē cmdlet nav, modulis ir atsevišķa problēma.

Rezultātam joprojām vajadzīgs konteksts. Ja mašīna nevar sasniegt izvēlēto kontrolieri vai tajā autentificēties, neizdevies tests nav neatkarīgs pierādījums, ka bezsaistes parole ir beigusies. Saglabājiet īsto kļūdu un izmantoto kontrolieri, un atkārtojiet testu, kad ceļš ir zināms labs.

Korelējiet Netlogon notikumus dalībniekā un attiecīgajā kontrolierī ap incidentu. Saglabājiet mašīnas nosaukumu, avota adresi, laiku un jebkādus konta maiņas pierādījumus. Cita lietotāja veiksmīga pieteikšanās vai veselīgs kontroliera panelis nevar aizstāt šīs mašīnas apmaiņu.

Labojiet tikai tās attiecības, kuras esat pierādījis

Kad savienojums ir stabils un administrators ir apstiprinājis, ka labošana ir piemērota, cmdlet režīms -Repair ar autorizētiem akreditācijas datiem ir viena atbalstīta darbība dalībnieka darbstacijai. Tas maina attiecības, un tas nav vēl viens tikai lasāms tests.

Pirms izmaiņām turiet pieejamu apstiprinātu vietējo atjaunošanas kontu un pārvaldības ceļu. Domēna kontrolieriem ir cita atjaunošanas loma, un šī procedūra nedrīkst tos uzskatīt par parastām darbstacijām. Izmantojiet organizācijas atjaunošanas plūsmu, nevis pēc kārtas palaidiet vairākus atiestatīšanas rīkus un ceriet, ka viens no tiem ir pareizais.

Pēc labošanas pārbaudiet jaunu drošā kanāla testu un sākotnējo domēna darbību. Saglabājiet lietotāju profilus un lietojumprogrammu stāvokli, un nepadariet noņemšanu-un-atkārtotu-pievienošanos par pirmo neizskaidroto darbību.

Ko pārbaudīt, kad kļūme atgriežas

Ja kļūme atgriežas, skatieties uz atritināšanu, dubultotu identitāti un konta izmaiņu laiku, nevis atiestatiet to pašu kontu vēlreiz. Atjaunots attēls, momentuzņēmums, klonēta mašīnas identitāte vai citur veikta datora konta atiestatīšana visi ir izmeklēšanas vērti.

Īslaicīgi veiksmīga atiestatīšana ir noderīgs atjaunošanas pierādījums, bet ne pierādījums, ka pārtraukta VPN izraisīja sākotnējo neatbilstību. Nākamā parādīšanās pateiks, vai cēlonis vispār tika novērsts.

Ierakstiet kontrolieri, DNS serveri un testa izvadi biļetē. Tieši šis ieraksts atšķir īstu uzticēšanās kļūmi no klēpjdatora, kas vienkārši nevarēja atrast domēnu.