Zugangskontrolle mithilfe von NAP- und NAC-Lösungen – Teil 4

Network Policy Server für Client-Health-Checks konfigurieren

09.12.2008 | Autor / Redakteur: Johann Baumeister / Stephan Augsten

Erst der Gesundheits-Check eines NAP-Systems entscheidet, ob sich ein Client mit dem Netzwerk verbinden darf.
Erst der Gesundheits-Check eines NAP-Systems entscheidet, ob sich ein Client mit dem Netzwerk verbinden darf.

Quarantänesysteme wie Network Access Protection von Microsoft halten unsichere Endgeräte vom Produktiv-Netzwerk fern. Hierzu prüfen sie den Gesundheitsstatus der Clients und verwehren im Ernstfall die Verbindung, bis eventuelle Probleme behoben sind. In diesem Teil unserer Artikelserie zur Netzwerk-Verbindungskontrolle beschreiben wir, wie der Network Policy Server zum DHCP-basierten Health-Checker konfiguriert wird.

NAP benötigt zur Sicherheitsüberprüfung der Clients Softwarekomponenten auf der Server- und der Clientseite. Serverseitig übernimmt dieses der System Health Validator, auf der Clientseite kommt der System Health Agent zum Einsatz. Zur Prüfung des Clientzustands tauschen die beiden Module Nachrichten aus, wie etwa Health Certificates und Health Statements.

Der Network Policy Server (NPS) hat die Aufgabe, den „Gesundheitszustand“ (System Health) der Clients zu prüfen. Die Vorgaben dazu sind in den „Health Requirements“ als Anforderungen festgeschrieben.

Einrichten des NPS als NAP Health Policy Server

Zur Konfiguration des NPS steht ein Assistent bereit, der NAP Configuration Wizard. Der Assistent unterstützt bei der Definition aller beteiligten Komponenten. Dazu zählen die folgenden Elemente:

  • System Health Validators

Die System Health Validator (SHV) bestimmen die benötigte Konfiguration, die ein Client erfüllen muss, wenn er eine Verbindung zum Netzwerk aufbauen möchte. Für das Testszenario soll das eine aktive Windows Firewall auf dem Clientsystem sein.

  • Health Policies

In den Health Policies wird festgelegt, welche SHVs zu Grunde gelegt werden und wie diese bei der Ermittlung der Zugangsberechtigung angewandt werden. Auf der Grundlage der SHV-Prüfungen wird dann eine Health Status, also der Gesundheitszustand des Clients, festgelegt.

Prinzipiell lassen sich hier natürlich mehrere Stati einstellen, je nach dem Umfang der geforderten Prüfungen. Für unser Testszenario sollen hier lediglich zwei Gesundheitsstati unterschieden werden: „compliant“ und „noncompliant“. Falls der Client die geforderte Windows Firewall aufweist und die Anforderungen erfüllt, gilt er als „compliant“, im anderen Fall erhält er den Zustand „noncompliant“.

  • Network Policies

Die Network Policies beruhen auf Bedingungen und weiteren Einstellungen. Sie werden benötigt, um zu prüfen, wer eine Verbindung mit dem Netzwerk aufbauen darf oder eben nicht.

Für unseren Testfall sollen zwei Bedingungen eingerichtet werden: Eine Network Policy, die angewandt wird, wenn der Clientrechner eine Übereinstimmung mit den geforderten Gesundheitsanforderungen (Health Requirements) aufweist, also compliant ist. Eine zweite Policy greift, wenn der Client diese Übereinstimmung nicht aufweist, also noncompliant ist.

Im Testfall sollen die Compliant-Rechner den vollständigen Zugang zum Netzwerk erhalten. Rechner, die die geforderten Bedingungen nicht aufweisen und noncompliant sind, werden stattdessen in ein eigenes Subnetz gepackt. Dazu erhalten sie eine andere IP-Adresse zugewiesen. Wenn die Noncompliant-Geräte ihren Zustand wechseln und später dann compliant werden, so sollen sie auch automatisch in das Unternehmensnetz mit dem vollständigen Zugang eingehängt werden.

  • Connection Request Policies

Connection Request Policies sind Bedingungen und Einstellungen, die den Netzwerkszugang prüfen und bei der Ermittlung der Bedingungen unterstützen. Für diesen Test wird eine Connection Request Policies herangezogen, die DHCP zur Prüfung des Clientzugangs und seiner Authentication verwendet.

  • RADIUS Clients and Servers

RADIUS-Clients unterstützen als Network Access Server bei der Prüfung des Zugangs. Remote DHCP Server werden als RADIUS-Clients auf dem Network Policy Server (NPS) eingerichtet.

  • Remediation Server Groups

Durch die Remediation (Wiederherstellung) wird ein „noncompliant Client“ in den compliant Zustand gebracht. Wird beispielsweise ein Update der Virensignaturdatei benötigt, so kann diese durch den Remediation Server bereitgestellt werden. Nach der Remediation durch den Remediation Server ist der Client wieder compliant. Im Testszenario werden die noncompliant Geräte in ein eigenes Subnetz gebracht, in dem sich auch der Remediation Sever befindet.

Seite 2: Die Verwendung des Assistenten zur Konfiguration des NPS

Inhalt des Artikels:

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 2018304 / Zugangs- und Zutrittskontrolle)