Azure VPN Client 3.4 trennt stündlich: Anmeldehäufigkeit

Ein Benutzer stellt die Verbindung her, arbeitet, und wird dann einmal pro Stunde mit der Meldung getrennt, die Authentifizierung bei Microsoft Entra sei abgelaufen. Das erneute Verbinden funktioniert, und der Zyklus wiederholt sich wie nach der Stoppuhr. Auf einem Point-to-Site-Gateway, an dem nichts bereitgestellt wurde, deutet dieses Muster auf die Anmeldedaten statt auf den Tunnel hin. Azure VPN Client 3.4.0 erzwingt seitdem die Anmeldehäufigkeit von Conditional Access während einer bestehenden Sitzung – eine Richtlinie, die frühere Clients nur bei der Anmeldung auswerteten.

Gehen Sie die sechs Prüfungen unten der Reihe nach durch. Jede bestätigt den Zeitplan oder schließt ihn aus, und wer zu früh aufhört, baut ein Gateway ohne Grund neu.

Schritt 1: die genaue Meldung lesen

Der Wortlaut trennt die Ebenen. Eine Meldung über ablaufende Entra-Authentifizierung ist eine Aussage über das Token; ein Tunnel- oder Security-Assoziationsfehler ist es nicht. Notieren Sie auch die verstrichene Zeit, gemessen vom Verbinden bis zur Trennung und nicht ab Beginn des Arbeitstags.

Kann der Benutzer sofort erneut verbinden und zeigt das Gateway weiterhin einen gesunden Tunnel, liegt Token-Ablauf vor und kein toter Peer.

Schritt 2: die Client-Version ermitteln

Lesen Sie die Version in der App ab, nicht im Deployment-Datensatz. Die Änderung kam mit 3.4.0, sodass 3.3.1 und älter einen bestehenden Tunnel unabhängig von der Richtlinie am Leben halten. Ein nicht verwalteter Laptop mit älterem Build verhält sich einwandfrei, während der Rest des Teams stündlich getrennt wird – genau die Art Aufteilung, die Leute zurück zum Gateway schickt. Die Version ist eine Eigenschaft des Clients, und das Gateway weiß nicht, welcher Build verbunden ist.

Aktualisieren Sie zuerst ein Testgerät und beobachten Sie die Uhr. Ein Gerät, das nach dem Update im Richtlinienintervall zu trennen beginnt, bestätigt den Mechanismus, ohne die Produktionsrichtlinie anzufassen.

Schritt 3: finden, wo die Richtlinie liegt

Die Anmeldehäufigkeit ist eine Conditional-Access-Einstellung in der Richtlinie, die auf die Enterprise-Anwendung Azure VPN zielt. Sie liegt nicht in der VPN-Gateway-Ressource, nicht in der Point-to-Site-Konfiguration und nicht im Clientprofil. Suchen Sie in der Richtlinienliste die Azure-VPN-App und lesen Sie die Sitzungssteuerungen.

Zwei Richtlinien können für einen Benutzer gelten, und die strengere gewinnt; ein Wert, den Sie nie festgelegt haben, kann also der wirksame sein. Prüfen Sie sowohl eine mandantenweite Basisrichtlinie als auch die app-spezifische. Auch der Berichtsumfang zählt: Eine Richtlinie, die eine Gruppe ausschließt, erzeugt eine Population mit anderem Verhalten und ohne offensichtliche Erklärung.

Schritt 4: rechnen

Die Trennung erfolgt eine Stunde nach dem Wert der Anmeldehäufigkeit – im Verhalten, das Microsoft für diesen Client dokumentiert. Eine Häufigkeit von sieben Stunden ergibt also rund acht Stunden Konnektivität. Wegen dieses Versatzes wirkt ein für einen achtstündigen Arbeitstag gewählter Wert am Nachmittag kaputt, während ein neunstündiger Test gut aussieht. Übersetzen Sie die Beschwerde in Zahlen, bevor Sie etwas ändern: Verbindungszeit, Trennungszeit, Differenz, dann Vergleich mit dem Richtlinienwert plus einer Stunde.

Passt die Differenz nicht zu dieser Summe, ist die Zeitplan-Hypothese falsch, und Sie sollten aufhören, an der Richtlinie zu drehen.

Schritt 5: Zeitplan und Rekey trennen

IPsec-Rekey, Dead-Peer-Erkennung und Idle-Timeouts erzeugen unregelmäßige Abbrüche, gebunden an Verkehrsvolumen oder Stille, nicht an eine Stoppuhr. Ein Benutzer, der mitten in der Übertragung getrennt wird, und einer, der nach einem untätigen Mittagessen getrennt wird, beschreiben verschiedene Mechanismen. Fragen Sie, was der Benutzer in der Minute vor der Trennung getan hat.

Zertifikatsprobleme sehen wieder anders aus: Der Client kann keine Verbindung aufbauen, statt eine laufende Sitzung zu verlieren, und der Fehler ist sofort da. Eine MFA-Aufforderung, die nie abschließt, zeigt sich als Hänger, nicht als saubere stündliche Trennung mit anschließend erfolgreicher Wiederverbindung.

Schritt 6: ohne Überraschung ausrollen

Kündigen Sie das Client-Update an, bevor es über den Store zu den Benutzern gelangt, denn die Verhaltensänderung wird mit dem Client ausgeliefert. Wählen Sie die Häufigkeit aus der Anforderung: ein Wert, der den Arbeitstag abdeckt, für die Nutzbarkeit, oder ein kurzer Wert, wenn ein verlorener Laptop schnell den Zugang verlieren muss. Halten Sie fest, welche Anforderung gewonnen hat, denn dieselbe Einstellung erzeugt sowohl den Schutz als auch die Beschwerde. Bestätigen Sie die Wahl dann auf einem Gerät mit dem neuen Build, statt aus einem Pilotprojekt mit dem alten zu extrapolieren.

Bewahren Sie Meldung, Version, Richtlinienwert und das gemessene Intervall in einer Notiz auf. Dieser Datensatz beantwortet den nächsten Bericht in einer Minute statt mit einem Neuaufbau.