Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 14 »Innere Sicherheit«
Pfeil 14.1 Netzwerkrichtlinien- und Zugriffsdienste
Pfeil 14.1.1 Wie funktioniert NAP?
Pfeil 14.1.2 Netzwerkrichtlinienserver
Pfeil 14.1.3 Client vorbereiten
Pfeil 14.1.4 Mehrstufiges NAP-Konzept vorbereiten
Pfeil 14.1.5 NAP für DHCP-Zugriff
Pfeil 14.1.6 Und die anderen Netzwerkverbindungsmethoden?
Pfeil 14.2 Windows-Firewall
Pfeil 14.2.1 Eingehende und ausgehende Regeln
Pfeil 14.2.2 Basiskonfiguration
Pfeil 14.2.3 Regeln im Detail
Pfeil 14.2.4 Verbindungssicherheitsregeln
Pfeil 14.3 Windows Server Update Services (WSUS)
Pfeil 14.3.1 Die Funktionsweise
Pfeil 14.3.2 Erstkonfiguration mit dem Assistenten
Pfeil 14.3.3 Konfiguration und Betrieb
Pfeil 14.3.4 Updates genehmigen
Pfeil 14.3.5 Gruppenrichtlinie konfigurieren
Pfeil 14.3.6 Kurzer Blick auf den WSUS-Client
Pfeil 14.3.7 Mit Berichten arbeiten
Pfeil 14.4 VPNs mit Windows Server 2012 R2
Pfeil 14.4.1 Gateway-Architektur
Pfeil 14.4.2 Grundkonfiguration des VPN-Servers
Pfeil 14.4.3 VPN einrichten (allgemein)
Pfeil 14.4.4 Einwahlberechtigung
Pfeil 14.4.5 PPTP-VPN
Pfeil 14.4.6 L2TP-VPN
Pfeil 14.4.7 SSTP
Pfeil 14.4.8 Automatischer Modus
Pfeil 14.4.9 Connection Manager Administration Kit (CMAK, Verbindungs-Manager-Verwaltungskit)

14»Innere Sicherheit« Zur nächsten Überschrift

Diesen Zorn des Apollon, des fernhintreffenden Herrschers.
Gerne will ich’s ansagen; doch du verheiße mit Eidschwur,
Daß du gewiß willfährig mit Wort und Händen mir helfest.
Denn leicht möcht’ erzürnen ein Mann, der mächtiges Ansehns
Argos Völker beherrscht, und dem die Achaier gehorchen.

Der erste Gedanke beim Thema »Sicherheit« richtet sich naturgemäß immer »nach außen«: So ziemlich jeder macht sich Gedanken, ob auch niemand die Firewall überwinden kann und dergleichen. Erwiesenermaßen kommen die meisten – sagen wir mal – »Probleme« von innen:

  • Es gibt mutwillige »Angriffe«, wenn Mitarbeiter einfach experimentieren (sprich irgendwelches »Zeug« aus dem Internet ausprobieren), sich für die entgangene Beförderung rächen wollen oder, was natürlich am heftigsten ist, sich Unternehmenswissen aneignen wollen, um dieses zu verkaufen.
  • Deutlich mehr Probleme entstehen durch grobe Fahrlässigkeit. Die meisten Benutzer lassen sich nur allzu gern auf suspekte Websites locken, öffnen jeden Mailanhang und tragen mehr oder weniger gefährliches Datenmaterial auf USB-Sticks herum.

Dies wird enorm dadurch »gefördert«, dass die Systeme nicht auf technisch einwandfreiem Stand sind. Dies beginnt bei fehlenden oder seit Monaten nicht mehr aktualisierten Virenscannern und endet bei Systemen, die noch nie einen Patch gesehen haben – aus welchen Gründen das auch immer so sein mag.

Windows Server 2012 R2 enthält etliche Komponenten, die den »Zustand« der Systeme verbessern und verhindern, dass sich potenziell »kranke« Systeme überhaupt mit dem Netz verbinden können. Einige Beispiele:

  • Mit den Netzwerkrichtlinien- und Zugriffsdiensten lässt sich unter anderem verhindern, dass Systeme ohne Virenschutz und/oder aktuelle Patches Zugriff auf das Netz erhalten.
  • Die integrierte Windows-Firewall sorgt dafür, dass auf Server und Clients nur im Rahmen der vorgesehenen Möglichkeiten zugegriffen werden kann.
  • Die Windows Server Update Services (WSUS) sorgen für die Verteilung von Patches im Netz.

Sicherheit ist ein Prozess

Das Thema »Sicherheit« ist in Windows Server 2012 R2 natürlich nicht nur durch diese Komponenten vertreten. So gut wie alle Komponenten des Betriebssystems können und müssen in irgendeiner Form vor unautorisiertem Zugriff geschützt werden, was Windows Server 2012 R2 selbstverständlich auch ermöglicht. Im Grunde genommen gelten aber die altbekannten »Weisheiten«:

  • Sicherheit ist kein »Einmal-Projekt«, sondern ein fortwährender Prozess.
  • Eine IT-Umgebung ist nur so sicher, wie sie konfiguriert wird. Das heißt: Gegen schlampige Konfiguration und Administration hilft auch modernste Technologie nicht.
  • Gehen die Benutzer nicht verantwortungsvoll mit den zur Verfügung gestellten Systemen um, ergeben sich dramatische Sicherheitslücken. Dabei sind sowohl Fahrlässigkeit als auch Vorsatz zu berücksichtigen.

Rheinwerk Computing - Zum Seitenanfang

14.1 Netzwerkrichtlinien- und Zugriffsdienste Zur nächsten ÜberschriftZur vorigen Überschrift

Unter dem Stichwort Netzwerkrichtlinien- und Zugriffsdienste sind diverse Technologien zu finden, die helfen, den Zugang zum Netz einerseits zu realisieren (z. B. Remote Access Service), aber auch abzusichern (z. B. Network Policy Server). Bei Netzwerkrichtlinien- und Zugriffsdienste handelt es sich um eine Rolle, deren Komponenten über die entsprechende Funktion des Server-Managers installiert werden. Abbildung 14.1 zeigt die Komponenten, die Sie im Installationsdialog auswählen können.

  • Netzwerkrichtlinienserver: Mit dieser Komponente können Sie organisationsweise Regeln definieren und durchsetzen, mit denen der Zugriff auf das Netz gesichert werden kann.
  • Host Credential Authorization-Protokoll: Diese Komponente dient zur Interaktion mit dem Cisco Access Control Server.
  • Integritätsregistrierungsstelle: Diese Komponente überprüft den Zustand des Clients und stellt ein Zertifikat aus, das auf der ermittelten Integrität des Clients beasiert. Diese wird benötigt, wenn Netzwerkzugriffsschutz (NAP) in Verbindung mit IPSec eingesetzt werden soll.

NAP

In diesem Abschnitt werden wir uns mit den Netzwerkrichtlinien beschäftigen, auch als Network Access Protection , kurz NAP, bekannt.

Ich werde im weiteren Verlauf des Kapitels die Kurzbezeichnung NAP verwenden.

Abbildung

Abbildung 14.1 Diese Komponenten gehören zur Rolle »Netzwerkrichtlinien- und Zugriffsdienste«.


Rheinwerk Computing - Zum Seitenanfang

14.1.1 Wie funktioniert NAP? Zur nächsten ÜberschriftZur vorigen Überschrift

Ich möchte an dieser Stelle NAP nicht bis ins letzte theoretische Detail diskutieren, sondern Ihnen eine grundsätzliche Idee von der Funktionsweise geben. Abbildung 14.2 zeigt eine stark vereinfachte Darstellung:

  • Wenn ein Client auf das Netz zugreifen möchte, muss er sich zunächst mit einem der NAP Enforcement Points (NAP-Erzwingungspunkte) auseinandersetzen. NAP-Unterstützung gibt es für verschiedene Netzwerkverbindungsmethoden, beispielsweise DHCP, VPN, Terminaldienstegateway, IPSec und auch für drahtlose und drahtgebundene 802.1X-Geräte (z. B. Switches, WLAN-AccessPoints).
  • An dem Erzwingungspunkt wird der »Gesundheitszustand« des Clients überprüft. Beispielsweise wird abgefragt, ob aktuelle Virenpattern vorhanden sind, ob eine Firewall für alle Netzwerkverbindungen aktiv ist und ob die aktuellen Patches eingespielt worden sind.

    Technisch funktioniert das so, dass auf den Clients ein Stück Software, nämlich der NAP-Agent mit diversen Unterkomponenten, vorhanden sein muss, der diese Daten einsammelt und das Ergebnis an den jeweiligen Erzwingungspunkt (z. B. den DHCP-Server) übermittelt.

  • Das Ergebnis der »Gesundheitsprüfung« sendet der Erzwingungspunkt an den Netzwerkrichtlinienserver, der anhand der dort konfigurierten Richtlinien entscheidet, ob dem Client Zugriff gewährt werden soll – oder eben nicht.
  • Wird dem Client Zugriff gewährt, kann er auf die produktiven Server zugreifen.
  • Wird dem Client kein Zugriff gewährt, weil er nicht alle Bedingungen für einen »gesunden Client« erfüllt, erhält er keinen Zugriff auf die produktiven Server. Stattdessen erhält er Zugriff auf einen oder mehrere Wartungsserver. Die Idee ist, dass er sich von diesen Wartungsservern die fehlenden Dateien, also insbesondere Virenpattern, Patches etc. holen kann. Nach dem Updatevorgang wird er dann nochmals einer Prüfung unterzogen, die er dann hoffentlich besteht.

Abbildung

Abbildung 14.2 Die Idee hinter NAP in stark vereinfachter Darstellung

In Abbildung 14.3 lernen Sie einige wesentliche Komponenten von NAP in einer etwas technischeren Darstellung kennen:

Zunächst zum Client:

  • Auf dem Client läuft ein NAP Agent, der übrigens für Windows Vista/7/8/8.1 und Windows XP SP3 verfügbar ist.
  • Dieser Agent verfügt über beliebig viele System Health Agents (SHA), die in der Lage sind, den »Gesundheitszustand« des Clients zu überprüfen. Hierzu gehört zum Beispiel, die Versionsnummer der aktuellsten Virensignatur zu ermitteln, den Zustand der Firewall (aktiviert/nicht aktiviert) zu überprüfen und Diverses mehr.

    Dritthersteller können beliebige eigene SHAs programmieren, die beispielsweise die Versionsstände bestimmter Softwareprodukte prüfen oder schauen, ob der Monitor auch den aktuellen Ergonomiebestimmungen entspricht.

  • Weiterhin sind an den NAP-Agenten beliebig viele Enforcement Clients angebunden. Es gibt beispielsweise einen Enforcement Client für DHCP, der die Kommunikationsvorgänge mit dem DHCP-Enforcement Server abwickelt.

Abbildung

Abbildung 14.3 Die Komponenten des NAP-Clients und des NAP-Servers

Auf der Serverseite sieht es folgendermaßen aus (von unten nach oben):

  • Zunächst gibt es verschiedene Enforcement Server. Dies können einerseits Windows-basierte Server (DHCP, Terminaldienstegateway, VPN-Server) sein, allerdings zählen auch 802.1X-Netzwerkgeräte (Switches, WLAN-AccessPoints) zu dieser Kategorie. Diese kommunizieren mit dem Enforcement Client.
  • Der NPS Service ist letztendlich ein RADIUS-Server, der die Kommunikation mit den Enforcement Clients übernimmt. Der NAP Administration Server nimmt die Informationen über den Zugriff verlangenden Client vom NPS Service entgegen und leitet sie an die System Health Validators weiter.
  • Die System Health Validators (SHV), von denen es ebenfalls beliebig viele geben kann, werten die empfangenen »Gesundheitszustandsinformationen« des Clients aus und prüfen, ob diese den aktuellen Anforderungen entsprechen. Ein SHV »weiß« zum Beispiel, ob es ausreicht, wenn das aktuelle Virenpattern vom 03.10.2008 stammt.

Diese Komponenten kommunizieren miteinander, und auch dabei gilt es einige Begriffe zu lernen (Abbildung 14.4):

  • Die System Health Agents (SHA) ermitteln den Status in ihrem jeweiligen Gebiet (z. B. Virenpattern, Firewall-Status etc.) und leiten das Ergebnis in einem Statement of Health (SoH) an den NAP Agent weiter.
  • Die diversen SoHs werden in einem System Statement of Health (SSoH) zusammengefasst, das vom NAP Agent an den jeweiligen Enforcement Client übergeben wird.
  • Der Enforcement Client übergibt das SSoH an den Enforcement Server.
  • Der Enforcement Server leitet das SSoH an den NAP Administration Server weiter.
  • Der NAP Administration Server zerlegt das SSoH in die ursprünglichen SoHs, die an den jeweiligen System Health Validator (SHV) übergeben werden.

Aus Gründen der Übersichtlichkeit ist es nicht eingezeichnet, es gibt aber auch einen Rückweg:

  • Die SHVs generieren jeweils eine SoHR, eine Statement of Health Response, in der einerseits angegeben ist, ob der Client kompatibel mit den Anforderungen ist; andererseits werden darin auch die Probleme (z. B. »Virenpattern zu alt«) benannt.
  • Die diversen SoHRs werden zu einer SSoHR, einer System Statement of Health Response, zusammengefasst und zurück zum Client übertragen.

Weiterhin ermittelt der NAP Administration Server anhand der SoHRs, ob dem Client voller Zugriff gewährt werden soll oder ob er nur beschränkten Zugriff, nämlich auf die Wartungsserver, erhält.

Es kann individuell konfiguriert werden, ob alle SHVs »kompatibel« melden müssen oder ob es für vollen Zugriff auch noch ausreichend ist, wenn ein oder mehrere SHVs »nicht-kompatibel« melden.

Ich möchte Ihnen dringend raten, sich diese Vorgänge zumindest ungefähr einzuprägen – Sie werden die Komponenten und Vorgänge später wiedererkennen.

Kommunikation

Die Kommunikation zwischen Enforcement Server und NPS Service läuft übrigens über das RADIUS-Protokoll ab. Aus diesem Grund können 802.1X-Komponenten recht problemlos eingebunden werden, indem diese als RADIUS-Client definiert werden. Sie müssen aber in der Lage sein, die SSoHs bzw. SSoHRs weiterzuleiten.

Abbildung

Abbildung 14.4 Die Kommunikationsvorgänge bei NAP


Rheinwerk Computing - Zum Seitenanfang

14.1.2 Netzwerkrichtlinienserver Zur nächsten ÜberschriftZur vorigen Überschrift

Der Netzwerkrichtlinienserver (NPS, Network Policy Server) ermöglicht die Durchsetzung von organisationsweiten Regeln für die Kontrolle des Zugriffs von Clients. Die Hauptkomponenten sind der mit Windows Server 2008 erstmalig verfügbare Netzwerkzugriffsschutz (NAP, Network Access Protection) und der RADIUS Server-Dienst.

Abbildung 14.5 gibt einen ersten Überblick über das Konfigurationswerkzeug. Sie sehen hier eine Vielzahl von Komponenten, deren Bedeutung Sie nun kennenlernen werden.

Ich möchte an dieser Stelle nun nicht jedes einzelne Element vorstellen, das im Netzwerkrichtlinienserver-Konfigurationswerkzeug zu sehen ist; ich möchte Ihnen aber jeweils ein Stichwort mitgeben. Sie werden die Elemente anhand eines Beispiels genauer kennenlernen:

  • Verbindungsanforderungsrichtlinien: Diese Richtlinien legen fest, welche Verbindungen zum Netzwerkrichtlinienserver aufgebaut werden können. Mit diversen Bedingungen können Sie Einschränkungen definieren, beispielsweise bezüglich der Uhrzeit, des Herstellers der zugreifenden Komponente, des Benutzers und für vieles andere mehr. Mit einer solchen Richtlinie wird übrigens auch festgelegt, dass ein Zugriff an einen zentralen Netzwerkrichtlinienserver weitergeleitet werden soll.
  • Netzwerkrichtlinien: Mit den Netzwerkrichtlinien wird letztendlich festgelegt, welche Bedingungen zu einer Genehmigung oder einer Verweigerung des Zugriffs führen.

    Abbildung

    Abbildung 14.5 Das Konfigurationswerkzeug des Netzwerkrichtlinienservers

  • Integritätsrichtlinien: Mit den Integritätsrichtlinien werden letztendlich die Bedingungen formuliert, die von einer Netzwerkrichtlinie ausgewertet werden. Hier wird insbesondere formuliert, welche Systemintegritätsprüfungen (SHV, System Health Validator) durchgeführt werden sollen.
  • Systemintegritätsprüfungen: Hinter diesem Stichwort verbergen sich die SHVs, die System Health Validators. Standardmäßig wird eine Systemintegritätsprüfung mitgeliefert, die solche Aspekte wie Virenpattern, Firewallstatus und dergleichen mehr auswertet.
  • Wartungsservergruppen: In Wartungsservergruppen werden diejenigen Server definiert, auf die ein Client Zugriff hat, wenn erkannt wurde, dass er als nicht zu den Richtlinien kompatibel ist. Von diesen Servern kann sich der Client die benötigten Updates, Virenpattern etc. herunterladen.

Kontoführung

Hinter dem Stichwort Kontoführung verbirgt sich die Konfiguration der Protokollierung. Diese wird in diesem Buch zwar nicht weiter beschrieben, trotzdem sollten Sie diese Einstellmöglichkeit anschauen, um zu wissen, welche Protokollierungsoptionen einstellbar sind. Die Konfigurationsdialoge sind selbsterklärend.


Rheinwerk Computing - Zum Seitenanfang

14.1.3 Client vorbereiten Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn ein Client in einer NAP-aktivierten Umgebung arbeiten soll, müssen Sie zunächst einige Einstellungen vornehmen. Windows 8.1/7/Vista und Windows XP (SP3) sind zwar grundsätzlich NAP-fähig, allerdings müssen Sie zwei Konfigurationsschritte durchführen:

  • Der Dienst NAP-Agent muss auf den Starttyp Automatisch gestellt werden. Sinnvollerweise starten Sie ihn auch direkt (Abbildung 14.6).
  • Die benötigten Erzwingungsclients müssen aktiviert werden.

Abbildung

Abbildung 14.6 Auf dem Client muss der NAP-Agent-Dienst gestartet werden.

Was ist ein Erzwingungsclient? Beim Netzwerkzugriffsschutz (NAP) wird der »Gesundheitszustand« des Clients überprüft und das Ergebnis an den Netzwerkrichtlinienserver übermittelt, der dann entscheidet, ob der Client zugriffsberechtigt ist – oder eben nicht.

Um die notwendigen Konfigurationsarbeiten »von Hand« zu erledigen, öffnen Sie in der MMC das Snap-In NAP-Clientkonfiguration, das in Abbildung 14.7 zu sehen ist.

Ist ein Erzwingungsclient erfolgreich aktiviert worden, finden Sie im Ereignisprotokoll einen entsprechenden Eintrag. Normalerweise gibt es zwar keine Probleme, einmal mehr kontrollieren kann aber im Zweifelsfall nicht schaden.

Abbildung

Abbildung 14.7 Aktivieren Sie bei Bedarf in diesem Snap-In die benötigten Erzwingungsclients.

Ein Administrator, der NAP im Netz einführen möchte, muss nun natürlich nicht durchs Haus laufen und Dutzende, Hunderte oder Tausende PCs per Hand konfigurieren: Selbstverständlich können die NAP-Clienteinstellungen auch per Gruppenrichtlinie verteilt werden. Abbildung 14.8 zeigt die entsprechenden Einstellungen.

Abbildung

Abbildung 14.8 Die NAP-Clientkonfiguration ist natürlich auch per Gruppenrichtlinie möglich.


Rheinwerk Computing - Zum Seitenanfang

14.1.4 Mehrstufiges NAP-Konzept vorbereiten Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie sich für die Einführung des Netzwerkzugriffsschutzes entscheiden, werden Sie vermutlich nicht »nur« eine, sondern mehrere Netzwerkverbindungsmethoden schützen wollen, also etwa DHCP und das Terminaldienstegateway. Nun ist es aber, um die beiden genannten Beispiele für Netzwerkverbindungsmethoden weiter zu betrachten, sowohl beim DHCP-Server als auch beim Terminaldienstegateway erforderlich, den Netzwerkrichtlinienserver (NPS) auf dem jeweiligen Dienste-Server zu installieren. Die meisten Administratoren dürften kaum erbaut sein, wenn die Verwaltung der Richtlinien jeweils lokal auf dem DHCP-Server, Terminaldienstegateway oder dergleichen stattfinden müsste – vielleicht gibt es ja auch mehrere davon.

In einer mittleren und größeren Umgebung wird also in etwa die Architektur aus Abbildung 14.9 gewünscht werden:

  • Der Client wendet sich mit seinem Zugriffswunsch an einen Server, beispielsweise einen DHCP-Server oder ein Terminaldienstegateway.
  • Auf den Servern ist zwar jeweils der Netzwerkrichtlinienserver installiert, diese sind aber so konfiguriert, dass sie die Anfragen an einen zentralen Netzwerkrichtlinien-Server weiterleiten.
  • Der zentrale Netzwerkrichtlinienserver prüft anhand der dort konfigurierten Richtlinien den Zugriff und übermittelt das Ergebnis.

Abbildung

Abbildung 14.9 Wenn mehrere Netzwerkverbindungsmethoden durch NAP geschützt werden, kann trotzdem ein zentraler NPS-Server verwendet werden.

Da die Komponenten des Netzwerkzugriffsschutzes per RADIUS-Protokoll miteinander kommunizieren, agieren die Netzwerkrichtlinienserver auf den Servern (wie DHCP, Terminaldienstegateway etc.) technisch gesehen als RADIUS-Proxy.

Diese Architektur aufzubauen ist zwar nicht allzu schwierig, erschließt sich aber auch nicht unbedingt ganz intuitiv, sodass ich es Ihnen vorführe.

Konfiguration auf dem zentralen Netzwerkrichtlinienserver

Bei der Konfiguration von einem RADIUS-Client bzw. Proxy auf der einen und dem RADIUS-Server auf der anderen Seite muss unter anderem ein gemeinsamer geheimer Schlüssel ausgetauscht werden. Da der Dialog zum Anlegen eines RADIUS-Clients diesen Schlüssel generieren kann, bietet es sich an, mit ihm zu beginnen; prinzipiell ginge es aber auch »andersherum«.

Rufen Sie also auf dem zentralen Netzwerkrichtlinienserver den Menüpunkt RADIUS-Client · Neu auf; Abbildung 14.10 zeigt, wo dieser zu finden ist.

Abbildung

Abbildung 14.10 Dieser Menüpunkt startet das Anlegen eines RADIUS-Clients.

Abbildung 14.11 zeigt den sich nun öffnenden Dialog. Die Einstellmöglichkeiten sind so weit selbsterklärend. Ich würde empfehlen, den gemeinsamen geheimen Schlüssel automatisch generieren zu lassen. Kopieren Sie den erzeugten Schlüssel (Zwischenablage), denn er muss ein wenig später im Client eingetragen werden.

Abbildung

Abbildung 14.11 In diesem Dialog wird der RADIUS-Client angelegt. Kopieren Sie den »gemeinsamen geheimen Schlüssel«.

Abbildung

Abbildung 14.12 Auf der zweiten Registerkarte des Dialogs geben Sie ein, dass der RADIUS-Client NAP-fähig ist. Der RADIUS-Client ist in diesem Fall ja der DHCP-Server von Microsoft.

Konfiguration auf den RADIUS-Proxy-Servern

Auf den RADIUS-Proxy-Servern (z. B. dem DHCP-Server oder dem Remote Desktop-Dienstegateway) muss der zentrale Netzwerkrichtlinienserver eingetragen werden. Hierzu wird eine neue RADIUS-Remoteservergruppe erzeugt, deren Mitglied der zentrale NPS ist.

Starten Sie die Konfiguration im Netzwerkrichtlinienserver-Snap-In mit dem Menüpunkt RADIUS-Remoteservergruppe · Neu (Abbildung 14.13).

Abbildung

Abbildung 14.13 Der Netzwerkrichtlinienserver, an den die Zugriffe weitergeleitet werden sollen, wird in einer neu zu erstellenden RADIUS-Remoteservergruppe angelegt.

In dem sich daraufhin öffnenden Dialog wird zunächst der Gruppenname der neuen RADIUS-Remoteservergruppe abgefragt. Weiterhin existiert eine Liste, in der beliebig viele RADIUS-Server eingetragen werden können. Wir erfassen hier nur einen, nämlich unseren zentralen NPS (Abbildung 14.14).

Die spannende Registerkarte beim Anlegen des RADIUS-Servers ist in Abbildung 14.15 zu sehen, denn hier wird der zuvor generierte gemeinsame geheime Schlüssel eingetragen. Die übrigen Einstellungen können Sie unverändert übernehmen.

Abbildung

Abbildung 14.14 In der neuen RADIUS-Remoteservergruppe wird der zentrale Netzwerkrichtlinienserver eingetragen.

Abbildung

Abbildung 14.15 Auf dieser Registerkarte tragen Sie den zuvor erzeugten »gemeinsamen geheimen Schlüssel« ein.

Nun müssen Sie noch festlegen, dass alle Anforderungen an die zuvor angelegte RADIUS-Remoteservergruppe weitergeleitet werden sollen. Hierzu wechseln Sie in die Rubrik Verbindungsanforderungsrichtlinien (Abbildung 14.16) und rufen der Einfachheit halber die Eigenschaften der vorhandenen Richtlinie auf. Auf der Registerkarte Einstellungen findet sich im Abschnitt Authentifizierung die gesuchte Einstellung.

Abbildung

Abbildung 14.16 In einer Verbindungsanforderungsrichtlinie wird festgelegt, dass die Anforderungen an eine »RADIUS-Remoteservergruppe« weitergeleitet werden sollen.


Rheinwerk Computing - Zum Seitenanfang

14.1.5 NAP für DHCP-ZugriffZur nächsten ÜberschriftZur vorigen Überschrift

Die Absicherung des DHCP-Zugriffs hat einen Vorteil und einen Nachteil:

  • Sie ist vergleichsweise einfach zu implementieren und umfasst dabei vermutlich fast alle Clients – vorausgesetzt, die Adressvergabe erfolgt über DHCP, wovon man aber zumeist ausgehen kann.
  • Für einen »Dunkelmann« (oder natürlich auch eine »Dunkelfrau«), der bzw. die mutwillig einen »kranken« PC in das Netz schleusen möchte, ist DHCP-NAP sehr einfach zu umgehen, da es genügt, einfach eine statische IP-Adresse einzutragen.

Trotz dieses nicht ganz unwesentlichen Nachteils gilt: Wenn Sie sich darüber im Klaren sind, dass DHCP-NAP nicht gegen mutwillige Sabotage hilft, ist es durchaus eine sinnvolle Technologie, mit der sich ohne großen Aufwand verhindern lässt, dass PCs ans Netz gelangen, die laut den Richtlinien gefährdet sind.

Kein IPv6

Wichtig zu erwähnen ist, dass DHCP NAP kein IPv6 unterstützt. Da meiner Erfahrung und Einschätzung nach die meisten Unternehmen und Organisationen auf absehbare Zeit weiterhin primär IPv4 verwenden werden, sehe ich darin kein wesentliches Manko von DHCP NAP – momentan jedenfalls nicht.

Erster Installationsschritt und Netzwerkrichtlinienserver-Design

Bevor wir die eigentliche Einrichtung durchführen, ist eine Vorüberlegung notwendig: Auf jeden Fall muss auf dem DHCP-Server der Netzwerkrichtlinienserver installiert werden. Sie könnten die Richtlinien nun direkt auf diesem Server implementieren – und alles klappt.

Wenn Sie, wie weiter vorn in Abschnitt 14.1.4 beschrieben, einen zentralen Netzwerkrichtlinienserver verwenden möchten, müssen Sie zuerst den NPS-Server-Rollendienst auf dem DHCP-Server installieren und als RADIUS-Proxy konfigurieren. Dies habe ich ebenfalls in Abschnitt 14.1.4 gezeigt.

Demnach sind die ersten Schritte:

  • Wenn die Richtlinien direkt auf dem DHCP-Server konfiguriert werden sollen, müssen Sie dort nur den Rollendienst Netzwerkrichtlinienserver installieren.
  • Falls die Richtlinienverarbeitung auf einem zentralen Netzwerkrichtlinienserver durchgeführt werden soll, installieren Sie zunächst die Rolle Netzwerkrichtlinienserver auf dem DHCP-Server und konfigurieren diesen dann als RADIUS-Proxy.

Einrichtung mit dem Assistenten

Sie können nun natürlich die benötigten Richtlinien (Verbindungsanforderungsrichtlinie, Netzwerkrichtlinie, Integritätsrichtlinie) per Hand erstellen – oder Sie machen sich das Leben ein bisschen einfacher und lassen den Assistenten für sich arbeiten. Den Einstieg zu dem Assistenten finden Sie, wenn Sie den obersten Knoten des Netzwerkrichtlinienserver-Verwaltungswerkzeugs selektieren und wie in Abbildung 14.17 gezeigt den Link NAP konfigurieren auswählen.

Hinweis

Wenn Sie mehrere Netzwerkrichtlinienserver einsetzen, also einen »zentralen« und einen auf dem DHCP-Server (als RADIUS-Proxy), werden die Richtlinien auf dem zentralen NPS angelegt.

Abbildung

Abbildung 14.17 Hier wird der Assistent gestartet.

Der Assistent möchte zunächst von Ihnen wissen, für welche Netzwerkverbindungsmethode Sie nun Richtlinien erzeugen möchten. Gemäß der Zielsetzung dieses Abschnitts wählen Sie DHCP aus (Abbildung 14.18). In der Abbildung verdeckt die heruntergeklappte Combobox ein Textfeld, in das Sie den Namen der Richtlinie eingeben.

Abbildung

Abbildung 14.18 Zunächst wählen Sie die Netzwerkverbindungsmethode und optional die RADIUS-Clients aus.

Auf der nächsten Dialogseite (Abbildung 14.19) können Sie die NAP-Erzwingungsserver angeben, auf denen DHCP-Server ausgeführt wird. Ob hier etwas eingetragen werden muss, hängt vom Gesamtszenario ab:

  • Falls Sie die Richtlinien auf dem DHCP-Server abarbeiten lassen möchten, tragen Sie hier keinen RADIUS-Client ein.
  • Ansonsten tragen Sie den DHCP-Server mit installiertem NPS als RADIUS-Client ein. Falls Sie die RADIUS-Client-zu-Server-Verbindung nicht bereits wie weiter vorn gezeigt eingerichtet haben, führt ein Klick auf Hinzufügen zu einem Dialog, in dem Sie den gemeinsamen geheimen Schlüssel festlegen können.

Abbildung

Abbildung 14.19 Der DHCP-Server wird hier eingetragen.

Die beiden nächsten Dialogseiten des Assistenten bleiben in dieser Testinstallation »leer« (Abbildung 14.20):

  • Auf der abgebildeten Dialogseite können Sie die Namen von DHCP-Bereichen eintragen, für die diese Richtlinie gültig sein soll. Wenn Sie keine Eingaben vornehmen, gilt die Regel für alle Bereiche der DHCP-Server.

    Anzumerken wäre, dass die eigentliche Konfiguration der DHCP-Server zusätzlich erfolgen muss – das zeige ich Ihnen ein wenig später.

  • Wenn nur die Computer bestimmter Computergruppen DHCP-Adressen erhalten sollen, tragen Sie diese in der nächsten (nicht abgebildeten) Dialogseite ein.

Abbildung

Abbildung 14.20 Soll die Richtlinie für alle DHCP-Bereiche gelten, bleibt diese Dialogseite leer.

Die nächste Dialogseite ist wieder interessanter. Hier geht es um die Erfassung der Wartungsserver (Abbildung 14.21). Dies sind die Server, die auch erreichbar sein sollen, wenn der Computer keine gültige Konfiguration aufweist. Dies können beispielsweise die Server mit aktuellen Virenpattern oder der WSUS-Server sein.

Auf der letzten Eingabeseite des Assistenten wählen Sie eine NAP-Integritätsrichtlinie aus (Abbildung 14.22). Diese beschreibt, welche Kriterien ein Computer erfüllen muss, um nicht als »potenziell krank und gefährdet« angesehen zu werden. Im Wesentlichen wählen Sie hier ein oder mehrere Systemintegritätsprüfungs-Objekte aus. In einer Standardinstallation, die nicht durch Drittherstellerkomponenten erweitert wurde, ist allerdings nur ein solches Objekt vorhanden, nämlich die Windows-Sicherheitsintegritätsverifizierung. In dieser sind solche Kriterien wie aktuelles Virenpattern, »Firewall aktiviert« oder »aktueller Patch-Level« definiert.

Abbildung

Abbildung 14.21 Eintragen von Wartungsservern

Abbildung

Abbildung 14.22 Standardmäßig ist nur eine Integritätsrichtlinie vorhanden. Wählen Sie sie aus.

Was der Assistent alles getan hat

Nach Abschluss des Assistenten sehen wir uns einmal an, was er alles eingerichtet hat.

Verbindungsanforderungsrichtlinien

Zunächst ist eine Verbindungsanforderungsrichtlinie angelegt worden, in der als Typ des Netzwerkzugriffsservers die Option DHCP-Server gesetzt ist (Abbildung 14.23).

Abbildung

Abbildung 14.23 Eine neue Verbindungsanforderungsrichtlinie ist angelegt worden.

In dieser Richtlinie sind keine weiteren Einstellungen vorgenommen worden, weshalb es hier auch nichts weiter zu besprechen gibt.

Netzwerkrichtlinien

Interessanter sind da schon die Änderungen an den Netzwerkrichtlinien. Hier gibt es drei neue Objekte (Abbildung 14.24):

  • kompatible DHCP-Clients
  • nicht kompatible DHCP-Clients
  • nicht NAP-fähige DHCP-Clients

Die Einstellungen auf der Registerkarte Übersicht sind übrigens bei allen drei Richtlinien identisch. Dem Client wird Zugriff gewährt, d. h., ihm wird eine IP-Adresse zugeteilt. Der Sinn dahinter ist, dass ja auch nicht kompatible Clients in irgendeiner Form Netzwerkkonnektivität benötigen, sonst könnten sie ja keine Patterns, Updates oder sonstige Objekte empfangen, die ihnen helfen können, wieder kompatibel zu werden.

Abbildung

Abbildung 14.24 Drei neue Netzwerkrichtlinien sind angelegt worden.

Welche Bedingungen zu erfüllen sind, ist auf der gleichnamigen Registerkarte aufgeführt (Abbildung 14.25):

  • Kompatible Clients müssen die Integritätsrichtlinie NAP DHCP Kompatibel erfüllen, die ebenfalls vom Assistenten angelegt worden ist.
  • Nicht kompatible Clients erfüllen die vom Assistenten angelegte Integritätsrichtlinie NAP DHCP Nicht Kompatibel.
  • Clients, die nicht NAP-fähig sind, erfüllen die Bedingung Computer ist nicht NAP-fähig, was sozusagen eine »eingebaute Bedingung« ist.

Die drei Netzwerkrichtlinien unterscheiden sich in der eingetragenen Bedingung und in einem Punkt auf der Registerkarte Einstellungen (Abbildung 14.26):

  • Kompatiblen Clients wird Vollständiger Netzwerkzugriff gewährt.
  • Nicht kompatiblen und nicht NAP-fähigen Clients wird Eingeschränkter Zugriff gewährt.

Abbildung

Abbildung 14.25 Als Bedingung ist eine Integritätsrichtlinie hinterlegt.

Abbildung

Abbildung 14.26 Ein nicht kompatibler Client erhält zwar eine IP-Adresse, ihm wird aber nur eingeschränkter Zugriff gewährt.

Integritätsrichtlinien

Weiterhin hat der Assistent zwei Integritätsrichtlinien erzeugt. Diese besagen:

  • Ein Client ist NAP DHCP Kompatibel, wenn er alle ausgewählten Systemintegritätsprüfungen besteht (Abbildung 14.27).
  • Ein Client ist NAP DHCP Nicht kompatibel, wenn er mindestens eine der ausgewählten Prüfungen nicht besteht (Abbildung 14.28).

Da es sich um eine nicht erweiterte Standardinstallation handelt, ist nur eine Systemintegritätsprüfung vorhanden. Es könnte aber auch durch Drittherstellerprodukte erweiterte Szenarien geben, in denen man mehrere oder eine andere Systemintegritätsprüfung auswählt.

Abbildung

Abbildung 14.27 Ein Client ist »NAP DHCP Kompatibel«, wenn er alle ausgewählten Systemintegritätsprüfungen besteht.

Abbildung

Abbildung 14.28 Ein Client ist »NAP DHCP Nicht kompatibel«, wenn er mindestens eine der ausgewählten Prüfungen nicht besteht.

Systemintegritätsprüfungen

Der Assistent nimmt zwar Modifizierungen im Abschnitt Systemintegritätsprüfungen vor, trotzdem kann es nicht schaden, bei dieser Gelegenheit einen Blick dort hineinzuwerfen.

In einer Standardinstallation ist nur eine Systemintegritätsprüfung vorhanden, nämlich die Windows-Sicherheitsintegritätsverifizierung – Dritthersteller können hier übrigens eigene Erweiterungen integrieren.

In den Eigenschaften des Elements ist zunächst konfiguriert, wie sich das System verhalten soll, wenn eine der benötigten Komponenten (SHV, SHA) nicht reagiert oder nicht erreicht werden kann. Standardmäßig wird in einem solchen Fall Nicht kompatibel zurückgegeben, d. h., der Client erhält nur beschränkten Zugriff (Abbildung 14.29).

Über die Schaltfläche Konfigurieren gelangen Sie zur »Detailkonfiguration« der gewählten Systemintegritätsprüfung (Abbildung 14.30):

  • Auf der ersten Registerkarte können Sie einstellen, welche Bedingungen ein Windows Vista (oder höher)-Client erfüllen muss, damit er die Systemintegritätsprüfung positiv besteht.
  • Die zweite Registerkarte enthält Einstellungen für XP, wobei dort der Spywareschutz nicht vorhanden ist.

Abbildung

Abbildung 14.29 Standardmäßig wird »Nicht kompatibel« zurückgegeben, wenn bei der Überprüfung ein Fehler auftritt, beispielsweise eine Verbindung zu einem benötigten Dienst nicht aufgebaut werden kann.

Abbildung

Abbildung 14.30 In der Konfiguration der »Windows-Sicherheitsintegritätsprüfung« können Sie festlegen, welche Bedingungen ein Client erfüllen muss.

Wartungsservergruppe

Unterhalb des Knotens Wartungsservergruppen ist die vom Assistenten erstellte Wartungsservergruppe zu finden. Dazu gibt es allerdings nichts weiter zu erklären, weshalb sie hier nicht weiter aufgeführt ist.

Vorbereitung des DHCP-Servers

Auf dem DHCP-Server sind ebenfalls noch einige Einstellungen vorzunehmen – keine Sorge, es handelt sich um nichts Kompliziertes.

Hinweis

Falls Sie dieses Kapitel nicht von vorn nach hinten durcharbeiten, sondern diese Seite mehr oder weniger zufällig aufgeschlagen haben, sei darauf hingewiesen, dass auf dem DHCP-Server der Netzwerkrichtlinienserver installiert und gegebenenfalls als RADIUS-Proxy konfiguriert werden muss.

In den Eigenschaften des Bereichs finden Sie die Registerkarte Netzwerkzugriffsschutz, auf der festgelegt wird, ob dieser Bereich dieser »Behandlung« unterliegt (Abbildung 14.31).

Abbildung

Abbildung 14.31 Der Netzwerkzugriffsschutz wird für den Bereich aktiviert.

Hinweis

In den Eigenschaften des IPv4-Bereichs des Servers gibt es eine gleichnamige Registerkarte, auf der festgelegt werden kann, wie sich der DHCP-Server verhalten soll, wenn der Netzwerkrichtlinienserver nicht erreichbar ist.

Der zweite Schritt bei der Konfiguration des DHCP-Servers besteht darin, dass für die nicht kompatiblen Clients eigene Bereichsoptionen (z. B. DNS-Server) gesetzt werden müssen.

Bei einem Server 2012/R2 ist die Vorgehensweise hierfür etwas anders als bei Server 2008/R2. Wenn Sie wissen, wie es geht, ist es aber nicht allzu schwierig:

  • Sie müssen eine Neue Richtlinie anlegen. Auf Abbildung 14.32 ist der Startpunkt im DHCP-Konfigurationswerkzeug zu sehen.

    Abbildung

    Abbildung 14.32 Hier beginnen Sie mit dem Erstellen der neuen Richtlinie.

  • Das Erstellen der Richtlinie beginnt ganz langsam mit der Abfrage eines Namens (Abbildung 14.33). Wieder möchte ich Sie auf Folgendes hinweisen: Wenn Sie mehr als eine Richtlinie angelegt haben, sind aussagekräftige Namen schön.
  • Abbildung 14.34 zeigt die »Kernkomponente«, nämlich die Bedingung, unter der die Richtlinie angewendet wird. Die Bedingung muss lauten: Benutzerklasse ist gleich Standardmässige Netzwerkzugriffsschutz-Klasse.
  • Auf Abbildung 14.35 ist zu sehen, dass ein separater IP-Adressbereich für die Clients eingetragen werden kann, für die diese Richtlinie gilt. Dieser separate IP-Adressbereich muss aber Teil des IP-Adressbereichs des übergeordneten Bereichs sein.

    Abbildung

    Abbildung 14.33 Die Richtlinie bekommt einen Namen.

    Abbildung

    Abbildung 14.34 Die Bedingung ist die »Standardmäßige Netzwerkzugriffsschutz-Klasse«.

    Abbildung

    Abbildung 14.35 Die Clients, für die die Richtlinie zutrifft, erhalten IP-Adressen aus dem hier definierten Bereich.

  • Für diese Richtlinie werden nun noch Bereichsoptionen eingetragen. Abbildung 14.36 zeigt, wie’s gemacht wird – nicht wirklich überraschend.

    Abbildung

    Abbildung 14.36 Eintragen der Bereichsoptionen der Richtlinie

Falls Sie Windows Server 2008/R2 als DHCP-Server einsetzen, gehen Sie wie folgt vor: (Abbildung 14.37):

  • Wählen Sie im Kontextmenü des Knotens Bereichsoptionen den Menüpunkt Optionen konfigurieren. Wechseln Sie auf die Registerkarte Erweitert.
  • Dort wählen Sie die Benutzerklasse Standardmässige Netzwerkzugriffschutz-Klasse.
  • Tragen Sie jetzt die gewünschten Bereichsoptionen ein.

Das Ergebnis wird dann beispielsweise so wie in Abbildung 14.38 aussehen. In der Ansicht sehen Sie die Spalte Klasse, die angibt, welche Option wohin gehört.

Abbildung

Abbildung 14.37 Bereichsoptionen, die bei nicht kompatiblen Clients vergeben werden sollen, tragen Sie in der »Standardmäßigen Netzwerkzugriffschutz-Klasse« ein. (Das gilt nur für Windows Server 2008/R2.)

Abbildung

Abbildung 14.38 Bereichsoptionen aus verschiedenen Benutzerklassen (gilt nur für Windows Server 2008/R2)

Aus Sicht des Clients

Wenn ein Client versucht, eine DHCP-Adresse zu erhalten, sein Zustand aber nicht den Anforderungen entspricht, wird die Benachrichtigung aus Abbildung 14.39 eingeblendet.

Abbildung

Abbildung 14.39 So sieht es aus, wenn der Client die Anforderungen nicht erfüllt.

Wenn Sie auf diese Meldung klicken, öffnet sich ein Dialog, der Sie darüber informiert, warum der Computer nur eingeschränkten Netzwerkzugriff erhält (Abbildung 14.40).

Abbildung

Abbildung 14.40 Diese Probleme führen dazu, dass der Computer nur eingeschränkten Netzwerkzugriff erhält.

Interessant ist, bei einem Computer mit eingeschränktem Netzwerkzugriff die IP-Konfiguration anzuschauen. Abbildung 14.41 zeigt ein ipconfig /all:

  • Zunächst fällt natürlich der Eintrag Systemquarantänestatus ins Auge. Dieser steht auf Eingeschränkt.
  • Außerdem ist die Subnetzmaske interessant. Bei dieser sind alle Bits gesetzt, also 255.255.255.255. Der Grund hierfür ist, dass der PC sich nicht »normal« im Netz befinden darf, er ist ja schließlich nicht »gesund«. Im DHCP-ACK-Netzwerkpaket werden einige Routinginformationen übermittelt. Das zeige ich Ihnen ein wenig später im Netzwerkmonitor.
  • Die DNS-Einträge, die zuvor in der eingeschränkten DHCP-Klasse vorgenommen worden sind (vergleiche Abbildung 14.38), sind vorhanden.

Abbildung

Abbildung 14.41 Die IP-Konfiguration eines Computers mit eingeschränktem Netzwerkstatus

In Abbildung 14.42 ist schließlich gezeigt, was passiert, wenn man unterschiedliche Systeme im Netz anpingt:

  • Die als Wartungsserver angegebenen Systeme sind erreichbar,
  • während es bei allen anderen Systemen zu Fehlermeldungen kommt.

Zum Abschluss möchte ich Ihnen noch vorführen, wie es aussieht, wenn der Computer die Netzwerkanforderungen erfüllt. In Abbildung 14.43 ist eine beruhigendes »Spruchband« zu sehen. Klickt man darauf, erscheint der bereits aus Abbildung 14.40 bekannte Dialog. Dieses Mal wurden vom Netzwerkrichtlinienserver aber keine Kritikpunkte übermittelt, Sie sehen stattdessen ein Häkchen, das »alles okay« signalisiert (Abbildung 14.44).

Abbildung

Abbildung 14.42 Die als Wartungsserver angegebenen Systeme können »angepingt« werden. Mit allen anderen ist keinerlei Kommunikation möglich.

Abbildung

Abbildung 14.43 Wunderbar: Der Computer erfüllt die Netzwerkanforderungen.

Abbildung

Abbildung 14.44 Anders als in Abbildung 14.40 ist jetzt alles in Ordnung.

Der Vollständigkeit halber werfen wir in Abbildung 14.45 noch einen kurzen Blick auf die Netzwerkkonfiguration.

Abbildung

Abbildung 14.45 Die Subnetzmaske ist jetzt eine »normale« Class-C-Maske, und alle Hosts sind erreichbar.

Zunächst fällt auf, dass die Subnetzmaske eine »normale« Class-C-Maske ist. Außerdem ist das Standard-Gateway gesetzt, was für die eingeschränkte DHCP-Benutzerklasse nicht gesetzt war. Außerdem kann wieder mit jedem Host kommuniziert werden, was in Abbildung 14.40 auch nicht möglich war: Es ist also alles wieder »normal«.

Einfach einzuführen und durchaus wirksam

Wie ich bereits eingangs erwähnt habe, schützt DHCP-NAP nicht vor vorsätzlichem Missbrauch, denn ein PC könnte mit einer statischen IP-Adresse versehen werden und so den gesamten Mechanismus umgehen.

Da ein »normaler« Benutzer dazu aber keine Berechtigungen haben sollte (keine lokalen Admin-Rechte) und im günstigsten Fall die entsprechenden Konfigurationsdialoge ohnehin ausgeblendet sind, kann auch DHCP-NAP nicht so ohne Weiteres umgangen werden.

Festzuhalten bleibt, dass es recht einfach einzuführen und dabei durchaus wirksam ist.

Betrachtung mit dem Netzwerkmonitor

Falls Sie noch ein wenig hinter die Kulissen von DHCP-NAP schauen möchten, habe ich mit dem Netzwerkmonitor die DHCP-Kommunikation zwischen einem Client, der sich als nicht kompatibel herausstellt, und dem Server aufgezeichnet. Im Grunde genommen ist das ein »ganz normaler« DHCP-Vorgang, der aus den bekannten vier Phasen (DISCOVER, OFFER, REQUEST, ACK) besteht.

Hinweis

Eine etwas genauere Betrachtung des DHCP-Protokolls finden Sie in Abschnitt 4.3.1.

In Abbildung 14.46 sehen Sie das vom Client versendete DHCP-DISCOVER-Paket. Im Abschnitt VendorSpecificInformation, der vom Netzwerkmonitor leider nicht aussagekräftiger dargestellt werden kann, findet sich das SSoH (System State of Health), also die Informationen über den »Gesundheitszustand« des Clients. Im Klartext heißt das, dass ein NAP-aktivierter Client bereits zu Beginn des DHCP-Vorgangs seine Statusinformationen an den Server übermittelt. Da der Client zu diesem Zeitpunkt keine IP-Adresse hat, gibt es ja eigentlich auch keine andere Chance, als über diesen Weg die Informationen auszutauschen.

Abbildung

Abbildung 14.46 Das DHCP-DISCOVER-Paket enthält in den »VendorSpecificInformation« das SSoH (System State of Health).

Interessant ist dann noch das DHCP-ACK-Paket, mit dem der Server dem Client die Bestätigung über die Vergabe der Adresse und diverse Konfigurationsdetails liefert. Abbildung 14.47 zeigt einen Blick in dieses Paket:

  • In der zweiten Zeile der Frame Details ist die 255.255.255.255-Subnetzmaske zu erkennen, auf die ich Sie bereits zuvor aufmerksam gemacht habe. Mit so einem Paket befindet sich der Client eigentlich auf einer einsamen Insel (zumindest IP-mäßig), weil er sich sozusagen in einem Ein-Host-Netz befindet, das keinerlei Verbindung zur Außenwelt hat.
  • Dass der Client die Wartungsserver erreichen kann, wird dadurch erreicht, dass diese mit klassenlosen statischen Routen (ClasslessStaticRoute) angegeben sind.

Abbildung

Abbildung 14.47 Im DHCP-ACK-Paket für einen nicht kompatiblen Client sind unter anderem die 255.255.255.255-Subnetzmaske und die klassenlosen statischen Routen zu den Wartungsservern zu erkennen.


Rheinwerk Computing - Zum Seitenanfang

14.1.6 Und die anderen Netzwerkverbindungsmethoden?Zur vorigen Überschrift

DHCP ist nun bekanntlich nicht die einzige Netzwerkverbindungsmethode, die mit NAP »ausgerüstet« werden kann (Abbildung 14.48).

Abbildung

Abbildung 14.48 Der Assistent kann auch für diverse andere Netzwerkverbindungsmethoden die Grundkonfiguration erstellen.

Ich möchte nun aber einfach aus Gründen der zu erwartenden Seitenzahl dieses Buchs nicht jedes Szenario en detail vorführen, zumal die Konfiguration teilweise deutlich komplexer als beim DHCP-NAP ist.

Mein Ziel ist, dass Sie grundsätzlich verstehen, was man mit NAP umsetzen kann, und dass Sie ein erstes Gefühl dafür bekommen, wie die Umsetzung erfolgt. Sie werden nun in der Lage sein, mithilfe der Microsoft-Dokumentation die anderen Netzwerkverbindungsmethoden zur Verwendung mit NAP zu konfigurieren. Die Startseite für die Beschäftigung mit NAP ist http://www.microsoft.com/technet/network/nap/default.mspx.

In Kapitel 19, »Remotedesktopdienste (Terminaldienste)«, ist natürlich auch das Gateway beschrieben, das ebenfalls in NAP integriert ist.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo