Warum ein VPN die Uhr eines domänengebundenen Laptops nicht repariert

Ein Mitarbeiter im Homeoffice baut die VPN-Verbindung auf, der Tunnel steht, und Anmeldungen beginnen mit einem Authentifizierungsfehler zu scheitern, der die Zeit erwähnt. Am Tunnel ist nichts defekt. Ein VPN trägt Pakete zwischen Netzen; es gibt zwei Rechnern keine gemeinsame Uhr, und Domänenauthentifizierung, Zertifikatsprüfung und Audit-Korrelation hängen alle von Uhren ab, die nah genug übereinstimmen. Daraus folgen drei Entscheidungen: wem die Zeit in der Domäne gehört, was das Gerät tatsächlich verwendet und was passiert, während das Gerät roampt.

Ein Pfad ist keine Uhr

Die Kerberos-Authentifizierung enthält zeitkritische Daten und lehnt Anfragen ab, die außerhalb einer konfigurierten Toleranz liegen, die in Windows-Domänen standardmäßig fünf Minuten beträgt. Zertifikate tragen Gültigkeitsintervalle, sodass ein Gerät, dessen Uhr weit genug vorausgeht, ein gültiges Zertifikat als noch nicht gültig behandelt. Audit-Datensätze mehrerer Rechner korrelieren nur, wenn ihre Uhren nah beieinander liegen, und das zählt beim ersten Mal, wenn eine Incident-Review fragt, was zuerst geschah.

Diese drei Abhängigkeiten sind unabhängig vom Tunnel. Ein VPN aufzubauen ändert die Erreichbarkeit, und Erreichbarkeit ist das, was ein Gerät eine Zeitquelle finden lässt; sie ist nicht die Quelle.

Halten Sie die angezeigte Zeitzone von der Uhr selbst getrennt. Zwei Laptops, die unterschiedliche Ortszeiten anzeigen, können perfekt synchronisiert sein, und zwei, die dieselbe Stunde anzeigen, können um Minuten auseinanderliegen, wenn ihre Zeitzoneneinstellungen abweichen. Die Zeitzone zu ändern ist keine Reparatur einer falschen Uhr, und ein Datum zurückzusetzen, damit ein abgelaufenes Zertifikat funktioniert, bricht jede andere zeitabhängige Prüfung auf dem Rechner.

Entscheiden Sie, wem die Zeit in der Domäne gehört

Domänengebundene Windows-Mitglieder folgen normalerweise der Zeithierarchie von Active Directory, statt jedes Mal einen öffentlichen Server abzufragen. Diese Kette endet beim PDC-Emulator der Gesamtstrukturwurzel, dessen Referenz die verbindliche Quelle der Organisation ist.

Zwei Bedingungen entscheiden über die Referenz: ob die Richtlinie einen externen Zeitdienst zulässt und ob das Netzwerk eine genehmigte interne Quelle von jedem Standort aus zuverlässig erreicht. Sind beide unklar, lautet die praktische Antwort, die Hierarchie intakt zu lassen und die Erreichbarkeit zu reparieren, statt Clients auf einen öffentlichen Pool zu zeigen. Eine dritte Bedingung entscheidet den Fehlerpfad: was das Gerät tun soll, wenn keine der Quellen erreichbar ist. Das vorab zu klären vermeidet die improvisierte Lösung, einen öffentlichen Server auf einem Laptop festzunageln.

Diese Wahl gehört den Domänen- und Zeitadministratoren, nicht dem Design des Fernzugriffs. Ein Laptop, der sich selbst als verlässliche Zeitautorität konfiguriert, ist eine andere Architektur, und es ist selten die, die die Sicherheitsprüfung genehmigt hat.

Lesen Sie, was das Gerät tatsächlich verwendet

Zwei schreibgeschützte Befehle dokumentieren den aktuellen Zustand auf einem verwalteten Windows-Gerät, und es lohnt sich, sie vor und nach einer Änderung zu erfassen:

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

Notieren Sie die gewählte Quelle, die letzte erfolgreiche Synchronisierung und die Stratum- oder Referenzkennung neben der Verwaltungsrichtlinie des Geräts. Eine erfolgreiche manuelle Synchronisierung beweist, dass der Befehl funktioniert, nicht dass die Richtlinie einen Neustart oder einen Rollenwechsel übersteht.

Zeigt die Quelle die lokale CMOS-Uhr, synchronisiert das Gerät überhaupt nicht, was meist bedeutet, dass der Domänencontroller beim Start nicht erreichbar war oder der Zeitdienst per Richtlinie deaktiviert wurde. Zeigt sie einen öffentlichen Server, gewinnt etwas außerhalb der Domänenhierarchie, und das ist eine Richtlinienfrage, keine Netzwerkfrage.

Entscheiden Sie, was beim Roaming passiert

Während der Trennung verlässt sich ein Gerät auf seine lokale Uhr und auf alle Zeitgeber, die es erreichen kann. Laptops driften, und ein Gerät, das wochenlang offline war, kann weit genug abweichen, um die erste Kerberos-Anfrage nach dem Wiederverbinden scheitern zu lassen.

Beim Wiederverbinden braucht das Gerät Domänenerkennung und den vorgesehenen Weg zum Zeitdienst, nicht nur eine Route zu einer Dateifreigabe. Testen Sie das, indem Sie außerhalb des Netzes neu starten, das VPN verbinden und die Quelle erneut lesen, statt anzunehmen, die Hierarchie habe sich selbst wiederhergestellt.

Virtuelle Maschinen fügen einen weiteren Zeitgeber hinzu. Die Zeitintegration des Hypervisors ist in vielen Designs eine legitime Quelle, aber ihre Rolle sollte bewusst gewählt und mit der Domänenrichtlinie abgestimmt werden. Zwei Zeitgeber, die sich widersprechen, erzeugen eine Uhr, die stabil aussieht und falsch ist.

Halten Sie die Mitgliederrichtlinie von der Autorität getrennt

Die gewöhnliche Mitgliederkonfiguration und die Konfiguration des autoritativen Servers sind verschiedene Probleme mit unterschiedlicher Änderungskontrolle. Sie zu vermischen ist der Weg, auf dem eine routinemäßige Laptop-Richtlinienänderung am Ende die Referenz für die gesamte Gesamtstruktur verändert.

Schreiben Sie den Entscheidungsvermerk als vier Zeilen: die verbindliche Quelle, die Hierarchie, die sie trägt, das Verhalten beim Roaming und der Befehl, der den Zustand auf einem Gerät belegt. Sind die ersten drei dokumentiert und der vierte wiederholbar, wird ein zeitbezogener Anmeldefehler zu einer Fünf-Minuten-Prüfung statt zu einer Suche durch VPN-Protokolle.