Bakit hindi inaayos ng VPN ang orasan ng laptop na konektado sa domain

Isang manggagawang malayo ang nagkokonekta ng VPN, tumataas ang tunnel, at nagsisimulang mabigo ang mga pag-login dahil sa error sa pagpapatotoo na nagbabanggit ng oras. Wala namang sira sa tunnel. Nagdadala ang VPN ng packet sa pagitan ng mga network; hindi ito nagbibigay ng pinagsasaluhang orasan sa dalawang makina, at ang pagpapatotoo ng domain, pagpapatunay ng sertipiko at ugnayan ng audit ay nakadepende sa mga orasang tugma nang sapat. Mula roon ay tatlong desisyon ang sumusunod: sino ang may-ari ng oras sa domain, ano talaga ang ginagamit ng device, at ano ang nangyayari habang nagroaming ang device.

Ang landas ay hindi orasan

Ang pagpapatotoo ng Kerberos ay may data na sensitibo sa oras at tinatanggihan ang mga kahilingang labas sa naka-configure na tolerance, na lima minuto bilang default sa mga domain ng Windows. May mga agwat ng validity ang mga sertipiko, kaya itinuturing ng device na masyadong nauuna ang orasan ang isang valid na sertipiko bilang hindi pa valid. Ang mga rekord ng audit mula sa maraming makina ay nag-uugnay lamang kung malapit ang kanilang mga orasan, at mahalaga ito sa unang pagkakataon na magtanong ang pagsusuri ng insidente kung ano ang nauna.

Ang tatlong dependency na iyon ay independiyente sa tunnel. Binabago ng pag-angat ng VPN ang maabot, at ang maabot ang nagpapahintulot sa device na makahanap ng pinagmulan ng oras; hindi ito ang pinagmulan.

Panatilihing hiwalay ang ipinapakitang time zone sa orasan mismo. Dalawang laptop na nagpapakita ng magkaibang lokal na oras ay maaaring ganap na naka-sync, at dalawang nagpapakita ng parehong oras ay maaaring magkaiba ng minuto kung magkaiba ang kanilang mga setting ng time zone. Ang pagpapalit ng time zone ay hindi pagkukumpuni ng maling orasan, at ang pag-urong ng petsa para gumana ang isang expired na sertipiko ay sisira sa lahat ng iba pang pagsusuring nakadepende sa oras sa makina.

Magpasya kung sino ang may-ari ng oras sa domain

Ang mga miyembro ng Windows na konektado sa domain ay karaniwang sumusunod sa hierarchy ng oras ng Active Directory sa halip na magtanong sa pampublikong server tuwing gagamitin. Nagtatapos ang chain na iyon sa PDC emulator ng ugat ng forest, na ang reference ay ang awtoritatibong pinagmulan ng organisasyon.

Dalawang kondisyon ang nagpapasya sa reference: kung pinapayagan ng patakaran ang panlabas na serbisyo ng oras, at kung maaabot ng network nang mapagkakatiwalaan ang isang aprubadong panloob na pinagmulan mula sa bawat site. Kung malabo ang dalawa, ang praktikal na sagot ay panatilihing buo ang hierarchy at ayusin ang maabot sa halip na ituro ang mga client sa pampublikong pool. Ang ikatlong kondisyon ang nagpapasya sa landas ng kabiguan: ano ang dapat gawin ng device kapag wala sa dalawang pinagmulan ang maabot. Ang pagpapasya nito nang maaga ay umiiwas sa improvisadong pagtatama ng pagpako ng pampublikong server sa isang laptop.

Ang pagpipiliang iyon ay pag-aari ng mga administrador ng domain at oras, hindi ng disenyo ng malayong pag-access. Ang laptop na nagko-configure sa sarili bilang mapagkakatiwalaang awtoridad ng oras ay ibang arkitektura, at bihirang ito ang inaprubahan ng pagsusuri ng seguridad.

Basahin kung ano talaga ang ginagamit ng device

Dalawang utos na basahin lamang ang nagdodokumento ng kasalukuyang kalagayan sa isang pinamamahalaang device na Windows, at sulit itong itala bago at pagkatapos ng pagbabago:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Itala ang napiling pinagmulan, ang huling matagumpay na pag-sync at ang stratum o reference identifier sa tabi ng patakaran ng pamamahala ng device. Ang isang matagumpay na manu-manong pag-sync ay nagpapatunay na gumagana ang utos, hindi na ang patakaran ay makakaligtas sa reboot o pagbabago ng papel.

Kung ang pinagmulan ay nagpapakita ng lokal na CMOS na orasan, hindi talaga nagsi-sync ang device, na kadalasang nangangahulugang hindi maabot ang domain controller noong boot o hindi pinagana ng patakaran ang serbisyo ng oras. Kung nagpapakita ito ng pampublikong server, may nananalo sa labas ng hierarchy ng domain, at ito ay tanong ng patakaran, hindi ng network.

Magpasya kung ano ang mangyayari habang nagroaming

Habang nakadiskonekta, umaasa ang device sa lokal nitong orasan at sa anumang tagapagbigay ng oras na maaabot nito. Nagd-drift ang mga laptop, at ang device na linggo nang offline ay maaaring lumihis nang sapat para mabigo ang unang kahilingan ng Kerberos pagkatapos ng muling pagkonekta.

Sa muling pagkonekta, kailangan ng device ang pagtuklas ng domain at ang inaasahang landas sa serbisyo ng oras, hindi lamang ruta patungo sa file share. Subukan ito sa pamamagitan ng pag-reboot sa labas ng network, pagkonekta ng VPN at muling pagbasa ng pinagmulan sa halip na ipagpalagay na nagpabalik ang hierarchy sa sarili nito.

Nagdaragdag ng isa pang tagapagbigay ang mga virtual machine. Ang integrasyon ng oras ng hypervisor ay lehitimong pinagmulan sa maraming disenyo, ngunit ang papel nito ay dapat piniling sadya at iugnay sa patakaran ng domain. Dalawang tagapagbigay na hindi nagkakasundo ay gumagawa ng orasang mukhang matatag at mali.

Panatilihing hiwalay ang patakaran ng miyembro sa awtoridad

Ang karaniwang configuration ng miyembro at ang configuration ng awtoritatibong server ay magkaibang problema na may magkaibang kontrol sa pagbabago. Ang paghahalo sa kanila ay ang paraan kung paano ang rutinang pagbabago ng patakaran ng laptop ay nagtatapos na binabago ang reference para sa buong forest.

Isulat ang rekord ng desisyon sa apat na linya: ang awtoritatibong pinagmulan, ang hierarchy na nagdadala nito, ang pag-uugali habang nagroaming, at ang utos na nagpapatunay ng kalagayan sa isang device. Kung ang unang tatlo ay nadokumento at ang ikaapat ay nauulit, ang kabiguan sa pag-login na may kaugnayan sa oras ay magiging limang minutong pagsusuri sa halip na paghahanap sa mga log ng VPN.