Varför ett VPN inte lagar klockan på en domänansluten bärbar dator

En distansarbetare ansluter VPN, tunneln kommer upp och inloggningar börjar misslyckas med ett autentiseringsfel som nämner tid. Inget på tunneln är trasigt. Ett VPN bär paket mellan nätverk; det ger inte två maskiner en gemensam klocka, och domänautentisering, certifikatvalidering och revisionskorrelation är alla beroende av klockor som stämmer tillräckligt nära. Av det följer tre beslut: vem som äger tiden i domänen, vad enheten faktiskt använder och vad som händer medan enheten roamar.

En väg är inte en klocka

Kerberos-autentisering innehåller tidskänsliga data och avvisar förfrågningar utanför en konfigurerad tolerans, som är fem minuter som standard i Windows-domäner. Certifikat har giltighetsintervall, så en enhet vars klocka går tillräckligt före behandlar ett giltigt certifikat som ännu inte giltigt. Revisionsposter från flera maskiner korrelerar bara om deras klockor är nära varandra, och det spelar roll första gången en incidentgenomgång frågar vad som hände först.

De tre beroendena är oberoende av tunneln. Att resa ett VPN ändrar nåbarheten, och nåbarhet är det som låter en enhet hitta en tidskälla; det är inte källan.

Håll den visade tidszonen åtskild från klockan själv. Två bärbara datorer som visar olika lokal tid kan vara perfekt synkroniserade, och två som visar samma timme kan skilja sig med minuter om deras tidszonsinställningar skiljer sig. Att ändra tidszonen är inte en reparation av en felaktig klocka, och att flytta ett datum bakåt för att få ett utgånget certifikat att fungera bryter varje annan tidsberoende kontroll på maskinen.

Bestäm vem som äger tiden i domänen

Domänanslutna Windows-medlemmar följer normalt Active Directorys tidshierarki i stället för att fråga en offentlig server varje gång. Kedjan slutar vid skogsrotens PDC-emulator, vars referens är organisationens auktoritativa källa.

Två villkor avgör referensen: om policy tillåter en extern tidstjänst och om nätverket pålitligt kan nå en godkänd intern källa från varje plats. Om båda är oklara är det praktiska svaret att hålla hierarkin intakt och reparera nåbarheten i stället för att peka klienter mot en offentlig pool. Ett tredje villkor avgör felvägen: vad enheten ska göra när ingen av källorna kan nås. Att avgöra det i förväg undviker den improviserade lösningen att fästa en offentlig server på en enda bärbar dator.

Det valet tillhör domän- och tidsadministratörerna, inte designen för fjärråtkomst. En bärbar dator som konfigurerar sig själv som tidsauktoritet är en annan arkitektur, och det är sällan den som säkerhetsgranskningen godkände.

Läs vad enheten faktiskt använder

Två skrivskyddade kommandon dokumenterar det aktuella tillståndet på en hanterad Windows-enhet, och de är värda att registrera före och efter en ändring:

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

Notera den valda källan, den senaste lyckade synkroniseringen och stratum eller referensidentifierare bredvid enhetens hanteringspolicy. En lyckad manuell synkronisering bevisar att kommandot fungerar, inte att policyn överlever en omstart eller en rolländring.

Om källan visar den lokala CMOS-klockan synkroniserar enheten inte alls, vilket oftast betyder att domänkontrollanten inte var nåbar vid start eller att tidstjänsten inaktiverades av policy. Om den visar en offentlig server vinner något utanför domänhierarkin, och det är en policyfråga, inte en nätverksfråga.

Bestäm vad som händer vid roaming

Medan enheten är frånkopplad förlitar den sig på sin lokala klocka och på de tidsleverantörer den kan nå. Bärbara datorer driver, och en enhet som varit offline i veckor kan avvika tillräckligt för att den första Kerberos-förfrågan efter återanslutning ska misslyckas.

Vid återanslutning behöver enheten domänidentifiering och den avsedda vägen till tidstjänsten, inte bara en rutt till en filresurs. Testa det genom att starta om utanför nätverket, ansluta VPN och läsa källan igen i stället för att anta att hierarkin återställde sig själv.

Virtuella maskiner lägger till ytterligare en leverantör. Hypervisorns tidsintegrering är en legitim källa i många designer, men dess roll bör väljas medvetet och samordnas med domänpolicyn. Två leverantörer som är oense ger en klocka som ser stabil ut och är fel.

Håll medlemspolicyn åtskild från auktoriteten

Vanlig medlemskonfiguration och konfigurationen av den auktoritativa servern är olika problem med olika ändringskontroll. Att blanda dem är sättet på vilket en rutinmässig ändring av bärbar-dator-policy till slut ändrar referensen för hela skogen.

Skriv beslutet som fyra rader: den auktoritativa källan, hierarkin som bär den, beteendet vid roaming och kommandot som bevisar tillståndet på en enhet. Om de tre första är dokumenterade och det fjärde upprepbart blir ett tidsrelaterat inloggningsfel en femminuterskontroll i stället för en jakt genom VPN-loggar.