Als Basis für die Erläuterung von NAP wird DHCP gewählt, weil dieses Protokoll für Zugriffe in jedem Netzwerk eine Rolle spielt – auch und gerade, wenn sich Benutzer mit ihren Laptops wieder mit dem Firmennetz verbinden, nachdem sie unterwegs andere Netzwerke genutzt haben.
Um NAP zu testen, bietet sich in jedem Fall die Verwendung einer Virtualisierungslösung, also beispielsweise von Microsofts VirtualPC oder der VMware Workstation an. Damit kann man einfach die verschiedenen erforderlichen Systeme aufsetzen und bei Bedarf beispielsweise auch einen zweiten Netzwerkadapter hinzufügen. Außerdem lassen sich getrennte Netzwerksegmente einfach konfigurieren, sodass man die reale Situation relativ gut abbilden kann.
|
Teil 1 |
|
|
Teil 2 |
Die Basiskonfiguration für eine NAP-Infrastruktur: NPS-Server |
Die Basis
Die Basis für die Testinfrastruktur sind ein Domänencontroller, ein Network Policy Server, der auch als DHCP-Server fungiert, und ein Client. Der Network Policy Server muss mit dem Windows- Server Longhorn arbeiten. Der Domänencontroller kann auch mit dem Windows Server 2003 betrieben werden. Das ist insofern sinnvoll, als man NAP in vielen Fällen zunächst in Umgebungen nutzen wird, in denen die Domänencontroller mit dem Windows Server 2003 betrieben wird und nur ausgewählte Server, beispielsweise für NAP, bereits auf den Windows Server Longhorn umgestellt werden. Der Client muss Windows Vista als Betriebssystem verwenden.
Auf dem Domänencontroller wird auch der DNS-Server benötigt. Es bietet sich an, für die Testumgebung in jedem Fall mit einem dedizierten Netzwerksegment – das sich bei Virtualisierungslösungen ja einfach definieren lässt – zu arbeiten, um eine Beeinflussung der Produktionsumgebung zu vermeiden. Entsprechend wird dort auch ein eigener DNS-Server benötigt. Als IP-Adresse bietet sich eines der privaten Class CSubnetze an, die für Testzwecke vorgesehen sind, also beispielsweise 192.168.0.0 mit der Subnetzmaske 255.255.255.0.
Im Active Directory müssen zumindest ein administrativer Benutzer für die Verwaltung und ein Testbenutzer für den Clientzugriff angelegt werden.
NPS einrichten
Der nächste Schritt ist die Einrichtung des NPS. Der Longhorn-Server muss Mitglied der Active Directory-Domäne werden. Und er muss sich im gleichen Subnetz wie der Domänencontroller befinden.
Der nächste Schritt ist die Einrichtung der Rolle Network Access Services, über die auch NAP unterstützt wird (Bild 1). Mit dieser Rolle werden auch andere Funktionen aktiviert, die für die Steuerung von Netzwerkzugriffen erforderlich sind. Nach einer Erläuterung der Network Access Protection folgt im nächsten Schritt die Festlegung der Dienste innerhalb der Rolle, die eingerichtet werden sollen (Bild 2). Hier müssen zumindest der Network Policy Server und die Health Registration Authority ausgewählt werden. Gegebenenfalls kann man auch noch die RRAS (Routing and Remote Access Services) mit installieren.
Je nach Status des Systems wird ein Dialogfeld angezeigt, in dem auf weitere erforderliche Rollen und Dienste hingewiesen wird, die automatisch mit installiert werden können. Die weiteren Dialogfelder können ohne Änderungen durchlaufen werden.
Um die weitere Konfiguration durchzuführen, wird nach Ende der Installation die Anwendung Network Policy Server gestartet,. Dieses Verwaltungsprogramm findet sich bei den administrativen Anwendungen.
Einrichtung des Security Health Validators
Der erste Schritt ist dabei die Einrichtung des Windows Security Health Validators bei Network Access Protection/System Health Validators. Bei den Eigenschaften können mit Configure die detaillierten Eigenschaften angezeigt werden. Hier können nun Grundeinstellungen gesetzt werden, die bei der Validierung geprüft werden sollen. Dazu zählt beispielsweise A firewall is enabled for all network connections. Für den ersten Test reicht das auch aus. Weitere Optionen sollten nicht gewählt werden, um den Test nicht zu kompliziert zu machen. In der Praxis wird man dagegen, wie in Bild 3, typischerweise weitere Einstellungen verlangen.
Damit ist zunächst definiert worden, dass ein System, das den Windows Security Health Validator verwendet, bestimmte Anforderungen erfüllen muss. Der nächste Schritt ist die Konfiguration der Richtlinie, die definiert, dass der SHV (Security Health Validator) auch genutzt wird. Dazu wird bei System Health Validator Templates mit New eine neue Vorlage erzeugt. In dieser Vorlage lassen sich neben dem Namen zwei Einstellungen setzen:
Der Template type gibt an, welche Bedingungen abgeprüft werden. Typischerweise wird als Erstes eine Vorlage erstellt, die erfordert, dass ein System alle SHV-Prüfungen erfüllt. Dazu wird die Option Client passes all SHV checks ausgewählt. Mit den anderen Optionen kann man Vorlagen erstellen, die auf Fehlersituationen reagieren.
Bei Select which SHVs muss pass wird ausgewählt, welche der verfügbaren SHVs geprüft werden. Aktuell gibt es nur den bereits erwähnten Windows Security Health Validator. Es ist aber zu erwarten, dass im Laufe der Zeit weitere SHVs verfügbar werden, da der Windows Security Health Validator doch eine recht eingeschränkte Funktionalität hat. Man muss zusätzlich mindestens eine weitere Vorlage erstellen für den Fall, dass der Client bei einer Überprüfung Fehler zurückmeldet.
Es folgt die Einrichtung einer Richtlinie für die Autorisierung von Zugriffen. Dazu wird bei Authorization Policies mit Neweine neue Richtlinie erzeugt. Sie ist vom Typ Custom, kann also flexibel angepasst werden. Über diese Richtlinie wird Zugriff gewährt, sodass im Register Overviewdie Option Grant access ausgewählt werden muss (Bild 4). Die Richtlinie wird aktiviert.
Bei Policy Source kann anschließend ausgewählt werden, von welchen Quellen Anforderungen verarbeitet werden. In diesem Fall ist das der DHCP Server. Es können aber auch andere Quellen angegeben werden. Mit Unspecified kann eine Richtlinie für unterschiedliche Quellen verwendet werden.
Anpassung der Bedingungen
Bei der Anpassung der Bedingungen, die für diese Richtlinie gelten sollen, reicht das Spektrum von Verbindungseinstellungen über die Gruppenmitgliedschaft von Benutzern und Systemen bis hin zu zeitlichen Einschränkungen. Im ersten Schritt muss hier bei Network Access Protection/ SHV Templates die definierte Vorlage für den Zugriff angegeben werden (Bild 5). Man kann an dieser Stelle auch direkt Vorlagen erstellen, falls man diesen Schritt nicht im Vorfeld durchgeführt hat. Im Register Settings muss im nächsten Schritt Network Access Protection/NAP Enforcement ausgewählt werden. Da in diesem Fall keine Einschränkungen erfolgen sollen, muss die Option Do not enforce gewählt werden. Da es sich um einen Zugriff im LAN ohne Authentifizierung handelt, sind außerdem bei Contraints/Authentication Method alle Optionen zu deaktivieren, weil sonst eine Netzwerkauthentifizierung des Computers erzwungen würde. Diese Einstellungen sind beispielsweise für WLAN-Zugriffe von Bedeutung. Stattdessen muss die Option Allow clients to connect without negotiating an authentication method gewählt werden. Die erste Richtlinie für die Autorisierung kann nun gespeichert werden.
Im folgenden Schritt muss eine analoge Richtlinie für die Systeme erstellt werden, die die Anforderungen nicht erfüllen. Hier muss bei Network Access Protection/NAP Enforcement die Option Enforce gewählt werden. Im unteren Bereich muss außerdem die Option Update noncompliant computers automatically gesetzt werden. In diesem Fall kann die Anpassung automatisch vom Client vorgenommen werden. Die Einstellungen in den Autorisierungsrichtlinien sind – im Gegensatz zu den Möglichkeiten des Windows Security Health Validators – sehr umfassend.
Wie geht es weiter?
Zentrales Thema des folgenden Teils der Artikelserie ist die NAP-Infrastruktur, deren wichtigstes Element neben den Policy-Servern die Remediation- Server sind.
Sie sorgen dafür, dass Systeme bei Bedarf in einen zulässigen Zustand versetzt werden. Auf deren Rolle und Einrichtung wird ebenfalls eingegangen.