Ein Benutzer in einer VPN-Gruppe erhält dadurch keinen Zugriff

Das Konto sitzt in der richtigen Gruppe, die Anmeldung gelingt, und die Verbindung wird trotzdem abgelehnt oder erreicht nichts Brauchbares. Der Reflex ist, den Benutzer in weitere Gruppen zu stecken, bis etwas nachgibt, und so werden weit mehr Rechte vergeben als im Ticket stand. Gruppenmitgliedschaft ist ein Eingangswert für die Autorisierungsentscheidung, nie die Entscheidung selbst: Das Gateway sammelt Fakten über die Sitzung, gleicht sie mit geordneter Policy ab und entscheidet erst dann, worauf die Sitzung zugreifen darf. Ist eine andere Bedingung gescheitert, ändert die Gruppe nichts außer Ihrer Angriffsfläche.

Gruppenmitgliedschaft ist eine Bedingung, keine Berechtigung

In RADIUS kommt die Gruppe als Autorisierungsattribut an, und Attribute beschreiben die Sitzung, statt sie zu erteilen. Der Server antwortet mit Access-Accept oder Access-Reject; bei Annahme kann er Filter-Id, Class oder die Tunnelattribute aus RFC 2868 anhängen, und das Netzwerkgerät am anderen Ende interpretiert sie, wie es der Hersteller entschieden hat. Nichts im Protokoll bildet eine Gruppe auf Vollzugriff ab; diese Abbildung schreibt, wer die Policy auf dem Gateway oder dem Netzwerkzugangsserver konfiguriert hat, und sie kann so eng wie ein einzelner Host sein.

Deshalb verhält sich ein identischer Gruppenname auf zwei Systemen unterschiedlich. Microsoft NPS baut Netzwerkrichtlinien aus Bedingungen, Einschränkungen und Einstellungen und wertet sie in einer festgelegten Reihenfolge aus. OpenVPN Access Server hat sein eigenes Gruppen- und Zugriffsregelmodell, während ein Community-OpenVPN-Server die ganze Frage oft an ein client-connect-Skript oder eine Datei in client-config-dir delegiert. Jedes verbraucht eine Gruppe; keines teilt die Prioritätslogik des anderen.

Es entscheidet die Regel, die gepasst hat, nicht die Gruppe, die Sie erwartet haben

Die meisten Engines stoppen bei der ersten passenden Richtlinie oder bei der spezifischsten. Wenn Richtlinie 3 verweigert und Richtlinie 7 erlaubt, kann eine Sitzung scheitern, ohne je die Regel zu erreichen, die sie durchgelassen hätte. Die Reihenfolge ist eine echte Einstellung auf NPS und den meisten NAC-Produkten und verschiebt sich über Jahre.

Die Bedingungen, die mit der Gruppe mitlaufen, sind die andere Hälfte. Gerätezustand, Authentifizierungsmethode, abgeschlossene MFA, Quellnetz, Zertifikatsantragsteller oder ein Zeitfenster können in derselben Richtlinie stehen. Fehlt eine davon, passt die Richtlinie nicht, die Engine fällt durch, und es gilt die Standardverweigerung. Aus Sicht des Benutzers sieht es aus, als werde die Gruppe ignoriert; aus Sicht der Engine wurde die Gruppe nie gefragt.

Verzeichnisdetails erzeugen dieselbe Illusion. Eine Richtlinie, die auf Windows-Gruppenmitgliedschaft prüft, liest die SIDs im Token des Benutzers, und dort werden nur Sicherheitsgruppen aufgelistet, eine Verteilergruppe erscheint nie. Die Primärgruppe steht in einem eigenen Feld statt in der Liste, sodass eine darauf festgelegte Richtlinie still scheitern kann.

Lesen Sie den Accept- oder Deny-Eintrag, bevor Sie eine Gruppe anfassen

Erst eine Frage: hat die Anfrage überhaupt die Autorisierungsstufe erreicht? Bei NPS steht die Antwort im Ereignisprotokoll, wo 6272 gewährten Zugriff, 6273 eine Ablehnung und 6274 eine Anfrage vermerkt, die der Server vor der Policy-Auswertung verwarf. Diese drei Nummern teilen das Problem in drei verschiedene Untersuchungen, und nur eine davon betrifft Gruppen.

Ist das Protokoll nicht erreichbar, fragen Sie den Server direkt und lesen Sie, was er zurückgibt. Eine Antwort ohne Filter-Id und ohne Tunnelattribute heißt, der Server hält die Sitzung für unauffällig und das Gateway wendet eigene Regeln an. Eine Antwort mit Attributen, die der Durchsetzungspunkt nicht umsetzt, ist ein anderer Fehler: Die Autorisierung ging durch, und das Gerät ignorierte das Ergebnis.

radtest alice 'password' 10.0.0.5 0 testing123

Vergleichen Sie die zurückgegebenen Attribute mit denen, die das Gateway dokumentiert, nicht mit dem, was der Gruppenname nahelegt. Dieser Vergleich trennt meist ein Policy-Problem von einem Durchsetzungsproblem.

Eine Gruppenänderung wirkt nicht rückwirkend

Autorisierungsattribute werden einmal zurückgegeben, bei der Authentifizierung der Sitzung. Das Gateway speichert sie an der Sitzung und liest das Verzeichnis nicht für jedes Paket neu, deshalb läuft eine bestehende Sitzung weiter, nachdem Sie jemanden aus einer Gruppe entfernt haben, und eine neue kann scheitern, während die alte noch läuft.

Damit eine Änderung greift, brauchen Sie eine neue Autorisierungsentscheidung, nicht nur frische Schlüssel. Wo der Server RFC 5176 dynamische Autorisierung unterstützt, erzwingt eine Disconnect-Request oder CoA-Request an UDP 3799 die Neubewertung der Sitzung; andernfalls trennen Sie den Client und lassen ihn neu verbinden. Eine Neuverhandlung erneuert die Tunnelschlüssel und lässt das Autorisierungsergebnis normalerweise unberührt.

Reparieren Sie die Bedingung, nicht die Gruppe

Sobald Sie wissen, welche Richtlinie gegriffen hat, ist die Reparatur meist klein: Ordnen Sie eine Verweigerung um, die die gewünschte Erlaubnis überschattet, ergänzen Sie die fehlende Geräte- oder MFA-Bedingung in der Richtlinie, die Sie meinten, oder schreiben Sie eine enge Regel für die eine Ressource, statt den Benutzer in eine Gruppe mit zehn weiteren zu heben.

Eine kurze Schleife hält die Änderung ehrlich:

• Reproduzieren Sie die Ablehnung mit dem ursprünglichen Konto und notieren Sie die Ereignis-ID, bevor Sie etwas ändern.
• Ändern Sie ein Objekt, eine Richtlinienreihenfolge, eine einzelne Bedingung oder eine Gruppe, und halten Sie fest, welches.
• Öffnen Sie eine neue Sitzung, bestätigen Sie, dass die Erlaubnis im Protokoll erscheint, und dass die Ressource wirklich aufgeht.
• Testen Sie einen Benutzer, der weiterhin abgelehnt werden soll, damit die Reparatur die Richtlinie nicht versehentlich geöffnet hat.

Ist die Erlaubnis korrekt und die Ressource öffnet trotzdem nicht, ist das Problem in dem Moment auf Routing oder Namensauflösung übergegangen, in dem die Autorisierung durchging. Halten Sie diese beiden Fehler auseinander, und das nächste Ticket dauert Minuten statt eines Nachmittags.