Bents Blog

 

Ein IT Blog mit Themen aus dem Windows Server Umfeld.

Update: Sicheres W-LAN mit IEEE 802.1X und RADIUS mit Windows Server 2012

Fast auf den Tag genau vor 2 Jahren veröffentlichte ich meinen Beitrag zu einem sicheren W-LAN-Betrieb unter Nutzung von IEEE 802.1X und RADIUS. Damals erläuterte ich die Einrichtung und Funktionsweise noch mit Hilfe eines IAS (Internet Authentication Server) unter Windows Server 2003.

Inzwischen wurde unser Server migriert: Ein neuer Windows Server 2012 mit dem Network Policy Server (NPS, dt. Netzwerkrichtlinienserver) hat nun die Aufgabe der Authentifizierung unserer W-LAN-Clients übernommen. Da sich an der Technologie des Protected Extensible Authentication Protocol (PEAP) mit EAP-MSCHAPv2 nichts geändert hat, beziehe ich mich deshalb auf meinen vorangegangenen Artikel und möchte hier nur die Neuerungen und Änderungen im Bezug auf den NPS unter Windows Server 2012 skizzieren.

Ich empfehle daher Lesern mit geringen Vorkenntnissen zuerst den älteren Beitrag zu studieren, um im Anschluss hier fortzufahren.

Voraussetzungen

Hardware

Für eine Verbindung über Funk (Wireless-LAN) wird nach wie vor ein Zugangspunkt (Access Point) benötigt. Dieser muss den Sicherheitsmodus WPA2-Enterprise beherrschen. Der Access Point wird über das RADIUS-Protokoll später mit unserem Authentifizierungsserver kommunizieren. Ob dieser neue Authentifizierungsserver im Windows 2012-Gewand rein physisch oder als virtuelle Maschine betrieben werden soll, liegt im Ermessen des Administrators.

Windows Server Softwarekomponenten

Wie bisher wird für die Umsetzung des Themas eine Grundkonfiguration an Windows-Komponenten benötigt:

  • eine Domäne mit mindestens Windows Server 2003, Standard Edition
  • eine eingerichtete Microsoft Stammzertifizierungsstelle (Root Certificate Authority)
  • einen Microsoft DHCP Server
  • einen Microsoft Network Policy Server (NPS), der RADIUS bzw. Netzwerkrichtlinienserver

Die letztere Komponente wurde in unserem Beispiel auf einem neuen Windows Server 2012 als Rolle installiert:

Die Rolleninstallation ist mit der unter Windows Server 2008 R2 vergleichbar und funktioniert dort gleichermaßen.

Einrichtung

Access Point

Bei der Einrichtung des Zugangspunktes für die W-LAN-Clients mit via PEAP-gesicherter Authentifizierung sind die folgenden Einstellungen wichtig:

  • Sicherheitsmodus: hier ist WPA2-Enterprise auszuwählen (auch WPA2-802.1X oder WPA2-1X genannt)
  • RADIUS Server: IP Adresse oder DNS-Name des Netzwerkrichtlinienservers (NPS)
  • RADIUS Server Port: im Standard 1812, bei Änderung auch im NPS einzustellen
  • Verschlüsselung: sollte bei WPA2 automatisch auf AES eingestellt sein
  • Shared Secret: Passwort für die verschlüsselte Kommunikation zwischen Access Point und NPS

Auf die Länge und die verwendeten Zeichen eines als hinreichend sicher geltenden Passworts gehe ich bewusst nicht ein – Administratoren, die sich des beschriebenen Themas annehmen, sollten hier ausreichend sensibilisiert sein.

Zertifikat durch eine interne Zertifizierungsstelle

Nach wie vor benötigt der Netzwerkrichtlinienserver (NPS) bei dem verwendeten Verfahren PEAP mit EAP-MSCHAPv2 für die verschlüsselte Verbindung zwischen Server und W-LAN-Client ein Computerzertifikat (Zweck: Serverauthentifizierung).

Die Prüfung des Zertifikates erfolgt nach wie vor über die Konsole Zertifikate (Lokaler Computer):

Die Verwendung des Zertifikates wird später für die Eigenschaften des geschützten EAP im Abschnitt der Netzwerkrichtlinie erläutert.

Netzwerkrichtlinienserver (NPS) – RADIUS Server

Der Windows Server 2012 auf dem die Rolle des Netzwerkrichtlinienserver (NPS) installiert werden soll, muss zuvor bereits Mitglied einer Domäne sein. Nach der Rolleninstallation kann die Verwaltungskonsole des NPS über den Server-Manger im Menüpunkt Tools aufgerufen werden:

Im Anschluss öffnet sich die Verwaltungskonsole, über die zunächst der neue Netzwerkrichtlinienserver (NPS) im Active Directory registriert werden kann (Rechtsklick auf NPS (lokal)):

Wurde der NPS in einer Gesamtstruktur mit mehreren Domänen installiert und soll auch Benutzer anderer (Sub-)Domänen authentifizieren, so muss der NPS für diese Domänen ebenfalls registriert werden. Dies geschieht auf Kommandozeilenebene auf dem NPS mit Hilfe des Befehls netsh:

netsh ras add registeredserver Subdomäne-FQDN NPS-Servername

In den Eigenschaften des NPS (Rechtsklick auf NPS (lokal)) lassen sich die Ports für die Authentifizierung und Kontoführung einstellen. Dies ist im Standard der RADIUS Port 1812 für die Authentifizierung und 1813 für die Kontoführung:

Ändert man die RADIUS Ports des Netzwerkrichtlinienservers, müssen diese von Hand auch in der Firewall des Servers als Ausnahmen definiert werden.

Sollen neben Fehlern auch abgelehnte und erfolgreiche Authentifizierungen im Ereignisprotokoll des NPS gespeichert werden, kann das auf der Registerkarte Allgemein eingestellt werden.

Im Vergleich zum IAS unter Windows Server 2003 werden die abgelehnten oder erfolgreichen Authentifizierungsversuche der Clients nicht mehr im System-Ereignisprotokoll sondern im Sicherheits-Protokoll gespeichert.

Im ersten Schritt der Konfiguration des NPS wird der Access Point (oder ggf. mehrere) als neuer RADIUS Client hinzugefügt:

Damit ist bereits die Kommunikation zwischen Access Point und NPS über RADIUS (AES-verschlüsselt über Shared Secret) sichergestellt. Im Anschluss kann nun die neue Verbindungsanforderungsrichtlinie erstellt werden. Dabei sind die Bedingungen für die Definition der Anforderungen verantwortlich:

Über die Bedingungen wird eingeschränkt, ob, auf Grund der vom RADIUS Client übergebenen Eigenschaften der Client-Anfrage, der Benutzer auch authentifiziert wird. Es lassen sich hier noch – abhängig von den Anforderungen im eigenen Unternehmen – sehr viele weitere Bedingungen setzen. Außerdem kann und sollte der Authentifizierungsanbieter eingestellt werden (Lokaler Computer):

Dadurch wird der NPS angewiesen, die Benutzer lokal (in der Domäne) zu authentifizieren. Alternativ könnten Anfragen auch an dritte Systeme oder wiederum andere RADIUS Server weitergeleitet werden.

Im Anschluss kann nun eine neue Netzwerkrichtlinie für den NPS erstellt werden:

Die Option Benutzerkonto-Eigenschaften ignorieren gibt an, ob der NPS Rücksicht auf die Einwähl-Einstellungen des Benutzers im Active Directory nehmen soll oder nicht. In der Registerkarte Bedingungen lassen sich nun Einschränkungen für die Autorisierung einer Verbindungsanforderung treffen:

Im obigen Beispiel wurden die Tages- und Uhrzeiteinschränkungen sowie die Mitgliedschaft einer Domänengruppe des für die Authentifizierung verwendeten Benutzerkontos konfiguriert. Unter der Registerkarte Einschränkungen wird nun als EAP Variante Geschütztes EAP (PEAP) eingestellt:

In den Eigenschaften des PEAP wird das von der internen Zertifizierungsstelle ausgestellte Zertifikat für die Serverauthentifizierung ausgewählt und als EAP-Typ das Gesicherte Kennwort (EAP-MSCHAPv2) eingestellt.

Zu guter Letzt müssen noch einige Einstellungen für den authentifizierenden Client getroffen werden. Dies betrifft zum Einen die Verschlüsselung:

Außerdem muss noch definiert werden, wie der Client eine gültige IP Adresse im Netzwerk erhält (in meinem Beispiel über einen DHCP Server im gleichen Netzwerk):

Als Besonderheit des NPS beherrscht dieser seit Windows Server 2008 R2 die Funktion Network Access Protection (NAP). Diese Funktion dient dazu, einen erfolgreich authentifizierten Client vor dem Zugriff auf das Produktiv-Netzwerk, temporär mit einem Quarantäne-Netzwerk zu verbinden. Dort werden Eigenschaften wie Windows Updates oder installierte Virenscanner und gültige Signaturen geprüft und im Anschluss der Zugriff auf das Produktiv-Netz gewährt. Da es sich bei unseren W-LAN-Clients nicht ausschließlich um Windows-Clients handelt, verwenden wir die NAP-Funktion nicht und gewähren somit nach erfolgreicher Authentifizierung dem Client Vollzugriff:

Damit ist die Grundkonfiguration des Netzwerkrichtlinienserver (NPS) unter Windows Server 2012 abgeschlossen. Die konfigurierten Clients sollten somit in der Lage sein, sich bereits erfolgreich zu Authentifizieren und so eine Verbindung mit dem W-LAN herzustellen.

Konfiguration der Clientgeräte

Auch an dieser Stelle hat sich an der Konfiguration der W-LAN-Clients nichts geändert – unter Windows 7 besitzt die Beschreibung meines älteren Artikels Gültigkeit. Auch die Liste der erfolgreich getesteten Geräte hat sich kaum geändert:

  • Smartphones (Android 2.2 bis 4.2.1)
  • Apple iPhone
  • Apple iPad
  • Windows XP (ab Service Pack 2)
  • Windows 7
  • Windows 7 Phone

Die Einstellung ist – gerade bei den mobilen Endgeräten – wie bspw. Smartphones denkbar einfach und schnell erledigt. Das zeigt exemplarisch die Einrichtung des neuen W-LAN an einem Android-Gerät aktueller Version. Bei der Suche nach Verbindungen wird hier der Sicherungstyp bereits als 802.1x angezeigt:

Beim Öffnen der Einstellungen für diese Verbindung muss zunächst die EAP-Methode gewählt werden (in unserem Fall PEAP):

Nun muss nur noch als Phase 2-Authentifizierung MSCHAPv2 ausgewählt werden:

Im Anschluss ist lediglich der Anmeldename in der Form DOMÄNE\Anmeldename oder Anmeldename@FQDN und das zugehörige Passwort zu hinterlegen. Die anonyme Identität kann frei bleiben:

Mit einem Druck auf Verbinden wir danach eine Verbindung mit dem W-LAN hergestellt. Einen eventuellen Misserfolg bzw. die erfolgreiche Authentifizierung findet man im Sicherheit-Ereignisprotokoll des Netzwerkrichtlinienservers.

Protokollierung der Verbindungen

Wie bereits erwähnt, dokumentiert der Netzwerkrichtlinienserver alle abgelehnten und erfolgreichen Verbindungsversuche (sofern aktiviert)  im Ereignisprotokoll Sicherheit. Bei einer erfolgreichen Verbindung finden sich pro Benutzer 2 Meldungen mit den Event-IDs 6272 und 6278 der Aufgabenkategorie Netzwerkrichtlinienserver:

Zusätzlich bietet der NPS aber – auch wie bisher der ISA unter Windows Server 2003 – die Möglichkeit der detaillierten Protokollierung der Kontoführung. Dabei lassen sich sowohl Textdateien (XML) als auch eine SQL Server Datenbank für die Protokollierung nutzen:

Für die Beschreibung der XML-Daten und die benötigten Datenbankfelder bei SQL Server-Nutzung empfehle ich folgenden Microsoft Technet Artikel.

Weitere Informationen zum NPS und 802.1X findet man bei Microsoft Technet.

Fazit

Wenn auch nicht mehr völlig neu, so soll die Aktualisierung des behandelten Themas in Bezug auf die genutzten aktuellen Windows Produkte eine Hilfestellung für Dritte als auch als Gedankenstütze für mich dienen. Ich hoffe, der Beitrag zeigt dennoch, mit welchem relativ geringen Aufwand die Umsetzung einer mit PEAP 802.1x gesicherten W-LAN-Authentifizierung unter Windows Server 2012 möglich ist. Wie bei allen meinen Beiträgen gilt: Bei Tipps, Vorschlägen sowie Fragen oder Kritiken hinterlasst bitte einen Kommentar.

Einen Blog am Leben zu erhalten kostet Zeit und Geld. Da ich auf meiner Seite weder Werbung einbinde, noch andersweitige Zuwendungen erhalte, freue ich mich über jede kleine Spende. Einfach und unkompliziert geht das über PayPalMe. Du unterstützt damit diesen Blog. Vielen Dank.

2 Kommentare für “Update: Sicheres W-LAN mit IEEE 802.1X und RADIUS mit Windows Server 2012”

  • Waldi

    Servus Bent,

    vielen Dank für deinen Artikel. Er hat mir bei der Umsetzung von Radius – WLan – Fortigate-
    Accesspoint in einer DMZ sehr geholfen. Ich möchte nicht unveschämmt sein und wollte Dich höflich fragen ob Du evtl. deinen Artikel, um den Client I-Phone, I-Pad in Bezug auf den Teil
    mit den Zertifikaten erweitern kannst?Ich habe hier meine Probleme. Das Root-Cert bekomme
    ich auf das Gerät. Aber wie bekomme ich das Client-Cert aus der Domaine. Ein Computer-Konto muss ich anlegen, dass ist mir klar … Aaber wie geht es weiter ???
    Wäre für einen Tip sehr dankbar.

    Vielen Dank !

    Waldi

  • Desby

    Hi Bent Schrader,

    tolle Anleitung :) – ich beschäftige mich derzeit selber mit dem Thema und stehe derzeit vor einem Rätsel, vielleicht kannst du mir da weiterhelfen…

    Umgebung:
    – NPS Server für RADIUS
    – Active Directory Zertifikatdienste
    – PEAP + MSCHAPv2

    Ich benötige für meine LAN Clients auf den Clients das Server und das Stammzertifikat. Weißt du, warum ich auf den WLAN Laptops und den Smartphones kein Zertifikat anbinden muss?

    Wäre echt super, wenn du mir helfen würdest,

    Lieben Gruß,
    Desby

Einen Kommentar hinterlassen:

Antispam Bee hat Bent's Blog vor 410.433 Spam-Kommentaren bewahrt.