NPS-Gruppenrichtlinie ist keine Durchsetzung von VPN-Ressourcen

Zwei Gruppen, zwei Zugriffsprofile, ein VPN-Gateway, und am Ende erreichen beide Gruppen dieselben Server. Der übliche Grund ist keine defekte Richtlinie, sondern eine fehlende zweite Hälfte des Entwurfs: NPS entscheidet, wer eine Sitzung aufbauen darf, und etwas anderes muss entscheiden, was diese Sitzung erreichen darf. Existiert nur die erste Hälfte, gelingt die Autorisierung für jeden, der sich authentifiziert. Die Richtlinie tut ihre Arbeit, und der Entwurf ist trotzdem unvollständig.

Eine gruppenbezogene Netzwerkrichtlinie ist ein Beleg über die Zulassung. Sie ist kein Beleg über Pakete, und die Lücke zwischen diesen beiden Aussagen ist der Ort, an dem der größte Teil dieser Arbeit stattfindet.

Finden Sie die Richtlinie, die die Sitzung tatsächlich zugelassen hat

NPS wertet geordnete Netzwerkrichtlinien aus, und die erste aktivierte Regel, deren Bedingungen passen, gewinnt. Bedingungen können Gruppenmitgliedschaft von Benutzer oder Computer, Verbindungstyp, Uhrzeit und Gerätezustand umfassen. Eine breite Richtlinie weiter oben in der Liste lässt eine Verbindung daher zu, bevor eine engere Regel weiter unten überhaupt betrachtet wird. Die Reihenfolge ist kein Detail der Oberfläche; die Reihenfolge ist die Richtlinie.

Lesen Sie die Liste der Reihe nach und bestimmen Sie die passende, und notieren Sie dann, welche Einstellungen sie zurückgegeben hat. Der Gruppenname im Editor ist nicht das Ergebnis; das Ergebnis ist die Autorisierung, die der Server erhielt. Halten Sie Benutzerautorisierung und Geräteautorisierung getrennt, wo das Deployment beide nutzt, denn ein Konto, das einen Tunnel öffnen darf, ist nicht automatisch ein Konto, das jeden internen Dienst erreichen sollte.

Die RADIUS-Antwort ist eine Anweisung, kein Filter

Ein Filter-Id-Attribut trägt den Namen einer Filterliste. Es liefert keinen übertragbaren Satz von Paketfilterregeln, den jeder Empfänger versteht, und einen Namen zu senden, den das Gateway nie definiert hat, erzwingt überhaupt nichts. Dieselbe Vorsicht gilt für VLAN-Attribute: Eine Tunnelsitzung einem VLAN zuzuordnen ist für sich genommen keine geroutete Zugriffsregel für diesen Benutzer.

Hier tut ein Entwurf, der auf der NPS-Seite vollständig aussieht, stillschweigend nichts. Bestätigen Sie anhand der Dokumentation des Gateway-Herstellers, welche Autorisierungsattribute unterstützt werden und was der Empfänger mit jedem einzelnen tut, statt anzunehmen, ein Standardattributname bedeute Standardverhalten.

Setzen Sie die Durchsetzung dorthin, wo der Verkehr vorbeikommt

Ein Gateway, das die Pakete des Benutzers verarbeitet, kann einen Filter pro Sitzung anwenden, eine Gruppe auf eine Gateway-Richtlinie abbilden oder der Sitzung eine Adresse aus einem abgesonderten Pool geben, den eine Firewall anders behandelt. Jede dieser Möglichkeiten kann funktionieren, und sie scheitern auf unterschiedliche Weise. Bestimmen Sie, welchen Mechanismus Ihr Gateway unterstützt, bevor Sie die Richtlinie schreiben, die ihn benennt. Schreiben Sie dann auf, was mit einer Sitzung geschieht, wenn dieser Mechanismus fehlt, denn Stille ist der Standard.

Beschreiben Sie die beabsichtigte Berechtigung in vier Teilen: Quellidentität oder Gruppe, Ziel, Protokoll und Port. Fügen Sie die Abhängigkeiten hinzu, die der Benutzer wirklich braucht, etwa DNS oder einen Authentifizierungsdienst, sonst bricht die Einschränkung Anmeldeabläufe, die niemand zu testen gedachte. Schreiben Sie die Regel gegen die Schnittstelle, die tatsächlich filtert, nicht gegen die Schnittstelle, die zufällig im Editor offen ist.

Berücksichtigen Sie auch die Übersetzung. Sieht eine nachgelagerte Firewall für jeden Tunnelbenutzer eine übersetzte Quelladresse, kann sie Einzelpersonen allein anhand dieser Adresse nicht unterscheiden, und eine Regel, die so geschrieben ist, als könnte sie es, wird entweder nutzlos oder zu weit.

Clientprofile leben auf der nicht vertrauenswürdigen Seite

Ein verwaltetes VPN-Profil kann Routen, Regeln für geteilte Tunnel oder Anwendungsfilter verteilen, und diese prägen, wie sich ein wohlerzogenes Gerät verhält. Sie sind kein Schutz für den Dienst, denn der Client ist die Partei, die Sie einschränken wollen. Eine Route in einem Profil zu entfernen ist ebenfalls keine Autorisierung, da ein Client einen anderen Weg zum selben Ziel haben kann.

Behandeln Sie Clienteinstellungen als Komfort und Gateway-Einstellungen als Kontrolle. Wenn beide sich widersprechen, hat das Gateway recht, weil es das ist, was die Pakete sieht.

Nehmen Sie mit zwei Konten ab, dann verfolgen Sie der Reihe nach

Erstellen Sie zwei gewöhnliche Testkonten mit unterschiedlichen beabsichtigten Berechtigungen, bauen Sie frische Sitzungen auf und prüfen Sie die wirksame Gateway-Richtlinie für jedes. Testen Sie dann eine harmlose erlaubte Operation und eine ausdrücklich verweigerte Ressource. Ein fehlgeschlagener Ping beweist für sich genommen sehr wenig, da ICMP gefiltert sein kann, während der dahinterliegende TCP-Dienst fröhlich antwortet.

Wenn beide Konten weiterhin breiten Zugriff erhalten, verfolgen Sie in fester Reihenfolge: welche Richtlinie passte, welche Autorisierung die Antwort trug und was das Gateway damit tat. Vor der Bestätigung, dass der Empfänger sie umsetzt, weitere NPS-Attribute hinzuzufügen, ist der Weg, auf dem ein kleines Autorisierungsproblem zu einem Änderungsfenster ohne Ergebnis wird.