Nabigo ang pagtitiwala sa domain pagkatapos ng isang buwang offline? Suriin muna

Isang laptop ang nananatili sa labas ng VPN nang anim na linggo, bumabalik, at hindi makapasok ang user gamit ang domain account. Binanggit ng error ang isang relasyon ng pagtitiwala, kaya may nagre-reset ng computer account, o pinipilit ang user sa full tunneling, at tila nawawala ang problema. Wala sa dalawang aksyon ang nagpatunay kung ano ang sira. Ang isang member ng Windows ay makapananatiling offline nang malayo lampas sa karaniwang agwat ng password ng makina nang hindi awtomatikong nawawala ang pagtitiwala, kaya ang unang gawain ay ihiwalay ang pagkabigo sa pag-abot mula sa tunay na hindi pagkakatugma ng sikreto.

Mukhang pagtitiwala ang error, ngunit tatlong estado ang magkatulad

Maaaring mag-sign in ang user gamit ang naka-cache na impormasyon ng domain, maaaring hindi mahanap ng workstation ang isang domain controller, o maaaring talagang hindi magkasundo ang member at ang domain tungkol sa computer account. Ang pangatlo lamang ang sirang relasyon ng pagtitiwala sa mahigpit na kahulugan.

Ang kalusugan ng AD replication ay ikaapat na obserbasyon, at wala itong kinalaman sa workstation na ito. Inilalarawan nito ang kasunduan sa pagitan ng mga domain controller, at ang malusog na dashboard ng replication ay hindi nagpapatunay na ang lokal na sikreto ng makinang ito ay tumutugma sa computer account nito.

Ang pamilyar na default na 30 araw ay patakaran ng pagbabago, hindi deadline ng pag-expire offline. Ang paliwanag ng Microsoft tungkol sa password ng machine account ay naglalarawan ng koordinadong proseso ng pagbabago, at ang isang organisasyon ay makakapag-configure ng ibang agwat.

Walang pinatutunayan ang icon ng VPN tungkol sa secure channel

Dapat sapat ang konektibidad upang maabot ang mga serbisyo ng domain bago may kahulugan ang anumang pagsubok. Ibig sabihin nito ang inilaan na DNS resolver ng domain, mahanap na controller, naaabot na mga serbisyo ng authentication at orasan na sapat na malapit para sa Kerberos.

Ang full tunneling ay maaaring maging ganap na wastong disenyo dito. Ang paglipat sa split tunneling ay hindi paunang kondisyon para sa malusog na relasyon sa domain, at ang pagtrato dito bilang ganoon ay ginagawang pagbabago sa arkitektura ang isang diagnosis. Suriin kung aling controller ang aktwal na pinipili ng workstation, at itago ang pangalang iyon kasama ng error.

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

Itala ang DNS server, ang naresolba na controller at ang eksaktong teksto ng error. Ang VPN client na nag-uulat na konektado ay nagsasabi na may tunnel, hindi na gumagana ang landas ng domain. Ang controller na sumasagot sa Kerberos port ngunit hindi sa directory port ay natuklasan ng firewall, hindi natuklasan ng pagtitiwala.

Subukan ang member bago ito ayusin

Sa isang awtorisadong member ng domain na Windows, ang Test-ComputerSecureChannel -Verbose ay basahin-lamang na pagsusuri ng channel sa pagitan ng makina at ng domain. Patakbuhin ito sa konteksto ng makinang iniimbestigahan mo, hindi mula sa domain controller, na may ibang tungkulin at ibang panuntunan sa pag-recover. Itala ang output at ang exit status sa halip na ang salitang pumasa o nabigo. Kung wala ang cmdlet sa build na iyon, ang module ay hiwalay na problema.

Kailangan pa rin ng konteksto ang resulta. Kung hindi maabot o ma-authenticate ng makina ang piniling controller, ang nabigong pagsubok ay hindi malayang patunay na nag-expire ang offline na password. Itago ang aktwal na error at ang ginamit na controller, at ulitin ang pagsubok kapag ang landas ay kilalang mabuti.

Iugnay ang mga kaganapan ng Netlogon sa member at sa kaugnay na controller sa paligid ng insidente. Itago ang pangalan ng makina, ang source address, ang oras at anumang ebidensya ng pagbabago ng account. Ang matagumpay na pag-login ng ibang user, o malusog na dashboard ng controller, ay hindi makapapalit sa palitan ng makinang ito.

Ayusin lamang ang relasyong napatunayan mo

Kapag matatag na ang konektibidad at nakumpirma ng administrator na angkop ang pag-aayos, ang -Repair mode ng cmdlet na may awtorisadong kredensyal ay isang sinusuportahang operasyon para sa member workstation. Binabago nito ang relasyon, at hindi ito isa pang basahin-lamang na pagsubok.

Panatilihing magagamit ang isang aprubadong lokal na recovery account at isang landas ng pamamahala bago ang pagbabago. Ang mga domain controller ay may ibang tungkulin sa recovery at hindi dapat ituring ng pamamaraang ito bilang ordinaryong workstation. Gamitin ang daloy ng recovery ng organisasyon sa halip na magpatakbo ng maraming tool sa pag-reset nang sunud-sunod at umasang isa sa kanila ang tama.

Pagkatapos ng pag-aayos, i-verify ang bagong pagsubok ng secure channel at ang orihinal na operasyon ng domain. Panatilihin ang mga profile ng user at ang estado ng application, at huwag gawing unang hindi maipaliwanag na aksyon ang pag-alis-at-muling-pagsali.

Ano ang susuriin kapag bumalik ang pagkabigo

Kung bumalik ang pagkabigo, tingnan ang rollback, doble na pagkakakilanlan at ang oras ng mga pagbabago sa account sa halip na i-reset muli ang parehong account. Ang naibalik na image, snapshot, na-clone na pagkakakilanlan ng makina, o pag-reset ng computer account na ginawa sa ibang lugar ay lahat karapat-dapat imbestigahan.

Ang pansamantalang matagumpay na pag-reset ay kapaki-pakinabang na ebidensya ng recovery, ngunit hindi ito patunay na ang pana-panahong VPN ang naging sanhi ng orihinal na hindi pagkakatugma. Ang susunod na pangyayari ang magsasabi kung ang sanhi ay naalis kailanman.

Isulat ang controller, ang DNS server at ang output ng pagsubok sa ticket. Ang rekord na iyon ang nagtatangi ng tunay na pagkabigo ng pagtitiwala mula sa isang laptop na hindi lamang mahanap ang domain.