Volker schrieb mich im Rahmen meiner rent-an-admin-Seite an, da er Probleme damit hatte, ein WLAN mit 802.1x-Authentifizerung zum Laufen zu bringen.

Ich muss gestehen, das war bislang nicht mein Lieblingsthema, hatte ich doch vor Jahren mit Windows Server 2003 diesbezüglich mal anständig ins Klo gegriffen. Soviel Ehrlichkeit muss sein.

Aber es hilft ja nichts, da muss man durch. Also mit Windows Server 2008 R2 einen neuen Versuch gestartet.

So einfach und überschaubar so manche Anleitung im Netz zu diesem Thema ist, so trivial ist das Thema leider nicht. Es gibt ein paar Stolpersteine und auch ein paar Merkwürdigkeiten.

Ich bin nicht der Erste, der exakt die gleichen Konfigurationsschritte mehrfach durchführte und plötzlich lief es.

Auch zeigte sich, das nicht jedes Gerät einwandfrei arbeitet. Bei Volker handelte es sich um einen Netgear WG602 mit DD-WRT Firmware und auf meiner Seite kamen sowohl ein Netgear DGN2000B als auch ein LevelOne WBR-3600 zum Einsatz.

Soviel zur Einleitung. Anbei meine gesammelten Erfahrungen und Informationen zum Thema.

Voraussetzungen

• Einen Domänencontroller (min. Windows Server 2003) mit Domänenfunktionsebene “Windows Server 2003″.
• DNS- und DHCP-Server.
• Eine (Unternehmens-)Zertifizierungsstelle (eigenständig soll wohl auch gehen, aber dann ist mehr Handarbeit angesagt).
• Einen IAS-Server (Windows Server 2003) oder NPS (Network Policy Server, Windows Server 2008/R2).
• Einen 802.1x-kompatiblen Wireless LAN Access Point/Router.

Ob nun die Standard oder Enterprise-Version des Windows-Servers für die CA oder NPS zum Einsatz kommen soll oder muss, hängt von den eigenen Anforderungen ab. Welche Einschränkungen es beim NPS zwischen den Versionen gibt, findet man z.B. hier. Die Unterschiede der Zertifizierungsstelle bei den einzelnen Windows-Versionen sind hier aufgelistet.

Eines Vorweg, bei der Standard-Edition sind “nur” maximal 50 RADIUS-Clients, d.h. in diesem Beispiel Wireless LAN Access Points möglich. Eine Nutzer-Beschränkung gibt es soweit ich weiss nicht.

Für meine Testumgebung habe ich zunächst alles (AD, DNS, DHCP, CA, NPS) auf einen Windows Server 2008 R2 Enterprise installiert. Später kam noch ein Memberserver für einen weiteren NPS dazu.

Zur Sicherheit das alle hier aufgezeigten Konfigurationsschritte funktionieren, habe ich zusätzlich eine komplette Neuinstallation mit Windows Server 2008 R2 Standard durchgeführt.

Prinzipiell funktioniert diese Vorgehensweise. Microsoft empfiehlt im TechNet aus Performancegründen die Installation des NPS auf einem Domänencontroller.

Selbstverständlich kann man auch alle Rollen sauber trennen und auf einzelnen Servern installieren.

Die Installation der einzelnen Rollen ist zunächst kein Problem. Tricky wird es dann erst bei der Konfiguration bzw. den Überraschungen die dabei auftauchen.

Konfiguration der Active Directory Zertifikatdienste

Nach erfolgter Installation der Active Directory-Zertifikatdienste, existiert zunächst nur das CA-Zertifikat. Für die Authentifizierung via 802.1x im Wireless LAN soll PEAP zum Einsatz kommen. Das bedeutet, der NPS muss der Zertifizierungsstelle vertrauen und benötigt ein eigenes Zertifikat und der Client (Windows 7 Professional) muss ebenfalls der CA vertrauen.

Zunächst muss die Zertifizierungsstelle vorbereitet werden. An dieser Stelle gibt es mehrere Möglichkeiten. Welche Möglichkeit gewählt wird, hängt unter anderem davon ab, ob der NPS auf einem DC oder auf einem Memberserver installiert ist und ob die Zertifikate automatisch verteilt werden oder manuell.

Folgender Schritt ist relevant für die automatische Zertifikatverteilung:

Bevor die Zertifikatvorlage “zugeteilt” wird, muss die Berechtigung “Automatisch Registrieren” gesetzt werden.

• Den “Server-Manager” öffnen.
• Zu “Rollen – Active Directory-Zertifikatdienste – Unternehmens-PKI – Zertifikatvorlagen” wechseln.
• Nun die “RAS- und IAS-Server”-Vorlage doppelt anklicken und auf der Registerkarte “Sicherheit” für “RAS- und IAS-Server” die Berechtigung “Automatisch registrieren” setzen.

oder

• Alternativ kann man die “RAS- und IAS-Server”-Vorlage mit der rechten Maustaste anklicken und “Doppelte Vorlage” auswählen. Auf diese Weise kann man eine Kopie der Vorlage der Anforderung entsprechend konfigurieren. Dies entspricht dem offiziellen Weg der im TechNet dokumentiert ist.

Damit die automatische Zertifikatverteilung klappt, muss der NPS in der Gruppe “RAS- und IAS-Server” sein.

Auszustellende Zertifikatvorlage hinzufügen

• Mit der rechten Maustaste auf “Server-Manager – Rollen – Active Directory Zertifikatdienste – NAME DER CA – Zertifikatvorlagen” klicken und “Neu – Auszustellende Zertifikatvorlage” auswählen.
• Nun die Vorlage “RAS- und IAS-Server” oder im Falle einer “Doppelten Vorlage” die entsprechende Vorlage auswählen und hinzufügen.

Manuelle Zertifikatanforderung

Nutzt man keine automatische Zertifikatverteilung, muss das Zertifikat für den NPS manuell über das “Zertifikate – Lokaler Computer”-Snap-In in einer MMC angefordert werden.

Vorsicht Falle “Certificate Autoenrollment”: Nutzt man die automatische Zertifikatverteilung, dann werden manuell erstellte Zertifikate aus dem Zertifikatspeicher entfernt, sofern die GPO-Einstellung

“Computer- bzw. Benutzerkonfiguration – Richtlinien – Windows-Einstellungen – Richtlinien für öffentliche Schlüssel - Zertifikatdienstclient – Automatische Registrierung” – “Zertifikate, die Zertifikatvorlagen verwenden, aktualisieren”

aktiviert ist. Das Entfernen geschieht immer dann, wenn keine passende Vorlage vorhanden ist.

Vorsicht Falle “Domänencontrollerauthentifizierung”: Verwendet man statt des “RAS- und IAS-Server”-Zertifikats bzw. die entsprechende Vorlage, dann greift das Computerzertifikat. Bei einem Memberserver ist das kein Problem. Bei einem Domänencontroller kann das Zertifikat aber nicht im NPS verwendet werden. Es wird noch nicht einmal angezeigt. Abhilfe schafft das ändern der Zertifikatvorlage “Domänencontrollerauthentifizierung”.

Da man die Original-Vorlage nicht direkt ändern kann, muss man Diese zunächst aus der Zertifizierungsstelle löschen.

Nun wählt man die Original-Vorlage aus, klickt Sie mit der rechten Maustaste an und wählt “Doppelte Vorlage”.

Nun stellt man die erweiterten Eigenschaften ein (“Windows Server 2003 Enterprise” oder “Windows Server 2008 Enterprise”), vergibt einen Namen für die Vorlage und konfiguriert auf der Registerkarte “Antragstellername” das “Format des Antragstellernamens”. Im Original steht dort “Keine”. Damit das auf Basis dieser Vorlage ausgestellte Zertifikat im NPS verwendet werden kann, muss an dieser Stelle “Allgemeiner Name” konfiguriert werden. Dies entspricht im übrigen der Einstellung der “RAS- und IAS-Server”-Vorlage.

Damit die Zertifizierungsstelle die neue Vorlage verwendet, muss man mit der rechten Maustaste “Zertifikatvorlagen” anklicken. Anschließend auf “Neu” und “Auszustellende Zertifikatvorlage” anklicken.

Nun wählt man die entsprechende Vorlage aus.

Ab jetzt klappt es auch mit dem Domänencontrollerzertifikat.

Netzwerkrichtlinienserver (NPS) konfigurieren

Der NPS muss im Active Directory registriert sein (Rechte Maustaste auf “NPS (Lokal)” und “Server in Active Directory registrieren” anklicken).

Dank eines Assistenten ist die Konfiguration schnell und einfach erledigt. Um die Konfiguration durchzuführen wie folgt vorgehen:

• “Server-Manager – Rollen – Netzwerkrichtlinen- und Zugriffsdienste – NPS (Lokal)” anklicken.
• Bei “Standardkonfiguration” “RADIUS-Server für drahtlose oder verkabelte 802.1X-Verbindungen” auswählen und auf “802.1X konfigurieren” anklicken.

Im ersten Schritt konfiguriert man, das man “Sichere Drahtloseverbindungen” einrichten möchte und vergibt einen Namen für die Richtlinien.

Nun muss der RADIUS-Client, damit ist der Access Point gemeint, hinzugefügt werden.

Wichtig ist der gemeinsame geheime Schlüssel. Dieser kann manuell oder automatisch generiert werden. Dieser Schlüssel muss auch in der Konfiguration des Access Points eingetragen werden.

Achtung: Je nach Access Point kann es Probleme mit der Länge des Schlüssels geben.

An dieser Stelle wird die Authentifizierung konfiguriert. In diesem Fall wird “Microsoft: Geschütztes EAP (PEAP)” mit “Gesichtertes Kennwort (EAP-MSCHAP v2)” verwendet. Die Konfiguration für EAP-TLS und PEAP-TLS wird weiter unten gezeigt.

Klickt man auf den Button “Konfigurieren…” sollte man das zuvor erstellte Zertifikat sehen.

Im nächsten Schritt gibt man die Computer- und Benutzergruppen an, die Zugriffsberechtigt sein sollen.

Ggf. kann man im nächsten Dialog noch weitere Parameter für RADIUS konfigurieren. Nach einer Zusammenfassung ist der Assistent abgeschlossen.

Kurioses: Gelegentlich kommt es vor, das der Assistent den RADIUS-Client doppelt mit identischer Konfiguration anlegt oder es sogar nur ein Anzeigefehler ist. Ferner ist es bei mir mehrfach aufgetreten, das beim Hinzufügen der Benutzergruppen zuerst eine Fehlermeldung erschien mit der Meldung, das keine Domäne zur Verfügung stände. Wenn man diese Meldung bestätigt, wird die Benutzergruppe dennoch hinzugefügt. Es scheint als laufe der Assistent manchmal gegen die Wand.

NPS-Konfiguration für EAP-TLS und PEAP-TLS

Beide Varianten setzen Computer- und Benutzerzertifikate voraus. Empfohlen ist die Nutzung der automatischen Zertifikatverteilung (Certificate Autoenrollment).

Im Grunde muss man beim NPS nur die Netzwerkrichtlinie ändern und die Client-Konfiguration anpassen.

EAP-TLS

PEAP-TLS

Welche Authentifizerungsmethode verwendet wird hängt vom jeweils geforderten Sicherheitslevel als auch der Geräte und Clients ab.

Access Point konfigurieren

Die Konfiguration ist je nach Hersteller und Gerät unterschiedlich.

Es müssen mindestens folgende Einstellungen vorgenommen werden:

• SSID.
• WPA2-Enterprise oder WPA-802.1X.
• RADIUS-Server-IP/Name (hier muss die IP-Adresse oder der Name des NPS angegeben werden).
• Ggf. muss auch der RADIUS-Server-Port (Standard 1812) konfiguriert werden.
• Gemeinsamer geheimer Schlüssel (Muss mit dem Schlüssel auf dem NPS übereinstimmen. Wird auch shared key oder shared secret genannt).

WLAN-Client konfigurieren

Je nach verwendeter Authentifizierung, muss entsprechend der WLAN-Client konfiguriert werden.

Man kann die WLAN-Konfiguration mittels Gruppenrichtlinien oder Skript verteilen. In diesem Fall wird sie aber manuell vorgenommen.

Am Beispiel von Windows 7 kann man im “Netzwerk- und Freigabecenter” die “Drahtlosnetzwerke verwalten”.

Dort kann man manuell ein neues Profil hinzufügen.

Nachdem man die grundlegende Konfiguration vom Netzwerknamen (SSID) und Verschlüsselung (WPA…) vorgenommen hat, kann man weitere Einstellungen vornehmen.

Für die Authentifizierung ist dann die Registerkarte “Sicherheit” interessant, denn dort werden alle notwendigen Angaben vorgenommen.

Unter Umständen muss ein Zertifikat importiert werden. Wie bereits erwähnt, hängt das aber von der Art der Authentifizierung als auch von der Konfiguration ab.

Troubleshooting

Wie anfangs erwähnt, funktionieren nicht alle Geräte einwandfrei. Von meinen beiden Testgeräten arbeitete zwar der Netgear DGN2000B einwandfrei, aber dafür kann das Gerät nur WPA-Enterprise. Volker’s Netgear WG602 mit DD-WRT und mein LevelOne WBR-3600 können zwar beide WPA2-Enterprise, aber im Fall des LevelOne nur in der Theorie. Soll heißen: Mal funktionierte WAP2-Enterprise, mal nicht.

Gemein haben alle drei Geräte, das Sie mit WPA2-PSK einwandfrei laufen. Zugegeben, es handelt sich nur um Consumer-Geräte. Ärgerlich ist es dennoch.

Volker ist sogar noch über ein ganz anderes Problem gestossen. Ich konnte das ebenfalls mit dem LevelOne nachvollziehen.

Das Problem

Versucht man zuerst direkt das WLAN zu verbinden, scheitert dies an der Konfiguration. Legt man dann das WLAN-Profil an, funktioniert die Verbindung dennoch nicht.

Auf dem Client (Windows 7) finden sich im Ereignisprotokoll unter

"Anwendungs- und Dienstprotokolle - Microsoft - Windows - WLAN-AutoConfig - Betriebsbereit"

folgende Fehlermeldungen:

Protokollname: Microsoft-Windows-WLAN-AutoConfig/Operational
Quelle: Microsoft-Windows-WLAN-AutoConfig
Datum: 10.01.2012 17:19:33
Ereignis-ID: 12013
Aufgabenkategorie:OneX-Authentifizierung
Ebene: Fehler
Schlüsselwörter:(512)
Benutzer: SYSTEM
Computer: lenny
Beschreibung:
Fehler bei der Drahtlos-802.1X-Authentifizerung.

Netzwerkadapter: 1x1 11b/g/n Wireless LAN PCI Express Half Mini Card Adapter
Schnittstellen-GUID: {fbd379b6-4d1c-45fb-b3a8-727c46e17cd0}
Lokale MAC-Adresse: 38:59:F9:E5:AB:12
Netzwerk-SSID: wlan_ng
BSS-Typ: Infrastructure
Peer-MAC-Adresse: 00:26:F2:44:DF:E0
Identität: NULL
Benutzer: andy
Domäne: lenny
Ursache: Empfang eines expliziten Eap-Fehlers
Fehler: 0x80420014
EAP-Grund: 0x0
EAP-Fehlerursachen-Zeichenfolge: Falscher Parameter.

EAP-Fehler: 0x80420014

Fehler bei der Drahtlossicherheit.

Netzwerkadapter: 1x1 11b/g/n Wireless LAN PCI Express Half Mini Card Adapter
Schnittstellen-GUID: {fbd379b6-4d1c-45fb-b3a8-727c46e17cd0}
Lokale MAC-Adresse: 38:59:F9:E5:AB:12
Netzwerk-SSID: wlan_ng
BSS-Typ: Infrastructure
Peer-MAC-Adresse: 00:26:F2:44:DF:E0
Ursache: Empfang eines expliziten Eap-Fehlers
Fehler: 0x80420014

Der Dienst für die automatische WLAN-Konfiguration konnte keine Verbindung mit einem Drahtlosnetzwerk herstellen.

Netzwerkadapter: 1x1 11b/g/n Wireless LAN PCI Express Half Mini Card Adapter
Schnittstellen-GUID: {fbd379b6-4d1c-45fb-b3a8-727c46e17cd0}
Verbindungsmodus: Verbindung mit einem sicherem Netzwerk ohne Profil
Profilname: wlan_ng
SSID: wlan_ng
BSS-Typ: Infrastructure
Fehlerursache:Das angegebene Netzwerk ist nicht verfügbar.

Auf dem NPS wiederum gibt es gar keine Fehlermeldungen. Das brachte mich dazu, den Netzwerkverkehr mit Microsoft’s Netzwerk Monitor vom Access Point zum NPS mitzuschneiden. Dabei zeigt sich folgendes Bild:

Zum Vergleich eine erfolgreiche Verbindung:

Man kann erkennen, das im Fehlerfall keine Antwort mehr vom Access Point kommt. Nach PEAP-Start sollte eigentlich der TLS-Handshake erfolgen. Dieser bleibt aber aus.

Wir konnten in unseren Tests eingrenzen, das es an den Access Points bzw. Routern liegen muss.

Ein Neustart der Clients (drei verschiedene Notebooks) als auch des NPS-Servers brachte keine Lösung. Auch das “lange” Warten (wg. Timeouts, Cache, etc.) nach einem fehlgeschlagenen Verbindungsversuch brachte nichts.

Erst wenn man den Access Point vom Strom nimmt und wieder verbindet, funktioniert es.

Da es nicht die Lösung sein kann, “ständig” den Access Point neu zu starten, blieb nur der Umstieg auf ein anderes Gerät. Erfolgreich konnte Volker den EDIMAX EW-7416APn v2 testen.

Hilfreiche und interessante Links

Bents Blog – W-LAN mit IEEE 802.1X und RADIUS in einer Windows Server-Umgebung sicher umsetzen

Aaron Walrath – Install Windows 2008 R2 NPS for RADIUS Authentication for Cisco Router Logins

LANCOM Support Knowledgebase – Radius Anbindung an einen Windows IAS Server

Mats Techblog – Securing Wireless Networks with Windows Server 2008 and NPS

Microsoft TechNet – NPS Server Certificate: Configure the Template and Autoenrollment

Intel - Simple Configuration of Microsoft NPS as Radius for Navigating 802.1X Networks with Intel AMT (Wired & Wireless AMT)

ADdict - Error Selecting A Certificate When Configuring NPS

Rachfahl Technikblog - Ändern einer Zertifikats-Vorlage einer Windows Server 2008 R2 PKI

msXfaq - 802.1x – Zugang zum Netzwerk steuern

TechNet Blog - Die 802.1x Authentifizierung scheitert, wenn das Maschinenpasswort geändert wurde

Etwas off-topic, da es zwar mit Windows, aber nicht mit Active Directory und NPS zu tun hat:

Heise – WLAN sichern mit RADIUS (Linux, FreeRADIUS und Windows)

Heise – Windows Home Server sichert WLAN (WHS 2003 und IAS)

In Anlehnung an meinen Artikel Windows: Wireless LAN, 802.1x und NPS folgt nun gewissermassen der zweite Teil, wie man 802.1x im drahtgebundenen, d.h. verkabelten Netzwerk zum Einsatz bringt.

Die Voraussetzungen sind bis auf die Hardware, statt eines Access Points wird ein oder mehrere 802.1x-kompatible Switche benötigt, identisch.

In meinem Fall kommt der kürzlich hier vorgestellte Netgear ProSafe GS108T zum Einsatz.

Auch in diesem Fall zeigte sich, das nicht jedes Gerät so mitspielt, wie man es erwarten würde.

Achtung: Bevor man anfängt, eine solche Konfiguration auszurollen, sollte man genau getestet und vorbereitet haben. Andernfalls kann man sich dadurch ganz schnell sein Netzwerk zu einer Gruppe stand-alone Rechner machen!

Die folgende Beispiel-Konfiguration basiert auf Windows Server 2008 R2.

Active Directory Zertifikatsdienste installieren und konfigurieren

Für den Fall, das man noch keine Unternehmens-Zertifizierungsstelle/-PKI hat, muss man zuerst die Rolle “Active Directory Zertifikatdienste” installieren:

Server-Manager – Rollen – Rolle hinzufügen – Active Directory-Zertifikatdienste

Sobald der Assistent nach dem Typ der Zertifizierungsstelle fragt, Diese auf “Unternehmen” einstellen. Alle weiteren Einstellungen können auf den Vorgaben belassen werden.

Nun muss die passende Zertifikat-Vorlage vorbereitet und hinzugefügt werden:

Server-Manager – Rollen – Active Directory-Zertifikatdienste – Unternehmens-PKI – Zertifikatvorlagen

• Mit der rechten Maustaste auf “RAS- und IAS-Server” klicken und “Doppelte Vorlage” auswählen.
• Einen Namen für die Vorlage vergeben, z.B. “RAS- und IAS-Server NPS”.
• Optional: Möchte man die automatische Zertifikatverteilung verwenden, auf die Registerkarte “Sicherheit” wechseln und der Gruppe “RAS- und IAS-Server” die Berechtigung “Automatisch registrieren” geben.
• Mit der rechten Maustaste auf “Server-Manager – Rollen – Active Directory-Zertifikatdienste – NAME DER PKI – Zertifikatvorlagen” und “Neu – Auszustellende Zertifikatvorlage” auswählen und die zuvor erstellte Zertifikatvorlage hinzufügen.

Der NPS benötigt ein Zertifikat, um sich den Clients gegenüber “ausweisen” zu können.

Dieses Zertifikat kann manuell über das Zertifikate-Snap-In in einer MMC oder via Automatische Zertifikatverteilung über die Gruppenrichtlinien angefordert werden.

Als generelle Voraussetzung für das erfolgreiche Anfordern eines Zertifikats gilt, das der NPS Mitglied in der Gruppe der “RAS- und IAS-Server” ist.

Je nach gewünschter Authentifizierung des Clients, müssen ebenfalls Zertifikate auf den Client-Computern angefordert werden. Dies ist für PEAP-TLS und EAP-TLS der Fall.

NPS installieren und konfigurieren

Der NPS wird ebenfalls als Rolle installiert:

Server-Manager – Rollen – Rolle hinzufügen – Netzwerkrichtlinien- und Zugriffsdienste

Bei der Abfrage, welche Komponenten installiert werden sollen, nur den “Netzwerkrichtlinienserver” auswählen.

Sobald der NPS installiert ist, muss dieser im Active Directory registriert werden. Dazu mit der rechten Maustaste auf “Server-Manager – Rollen – Rolle hinzufügen – Netzwerkrichtlinien- und Zugriffsdienste – NPS (Lokal)” klicken und “Server im Active Directory registrieren” anklicken.

Nun muss der NPS konfiguriert werden. Dazu zu

Server-Manager – Rollen – Netzwerkrichtlinien- und Zugriffsdienste – NPS (lokal)

wechseln.

• Unter “Standardkonfiguration” “RADIUS-Server für drahtlose und verkabelte 802.1X-Verbindung” auswählen und “802.1X konfigurieren” anklicken.
• “Sichere verkabelte (Ethernet-) Verbindungen” auswählen und einen Namen für die Richtlinien vergeben.
• Einen oder mehrere RADIUS-Clients, d.h. die Switches, hinzufügen.
• Die Authentifizierungsmethode auswählen. Für alle drei Methoden gilt, das nach der Auswahl auf “Konfigurieren” geklickt werden muss und das NPS-Zertifikat ausgewählt wird.
• Die Benutzer- und Computergruppen hinzufügen, die Berechtigt sein sollen, auf das Netzwerk zuzugreifen.
• Auf dem nächsten Dialog können Geräte-spezifische Konfigurationen vorgenommen werden. In meinem Fall ist das nicht notwendig.
• Nach Abschluss des Assistenten ist der NPS einsatzbereit.

Switch konfigurieren

Im 802.1X-kompatiblen Switch muss mindestens folgendes konfiguriert werden:

• RADIUS-Server: IP-Adresse oder Computername des NPS
• RADIUS-Port 1812 (Standard)
• RADIUS-Secret: Geheimer, gemeinsamer Schlüssel

Wie anfangs erwähnt, spielt auch hier nicht jedes Gerät so mit, wie man es erwartet.

Mit dem Netgear ProSafe GS108T kam ich trotz richtiger Konfiguration nicht weiter. Der Fehler äussert sich dadurch, das keine erfolgreiche Authentifizierung zustande kommt. Auf dem NPS finden sich folgende Fehler:

Es macht dabei keinen Unterschied, ob der “Message Authenticator” auf dem NPS und dem Netgear Switch aktiviert ist oder nicht.

Schaut man sich die Kommunikation mit dem Microsoft Network Monitor an, zeigt sich folgendes Bild:

Man sieht, das zumindest versucht wird, eine EAP-Authentifizierung zu etablieren. Jenseits von “Identity” passiert jedoch nichts.

Auf dem Screenshot zu sehen ist ferner der fehlgeschlagene Versuch der “admin”-Anmeldung des Netgear Switch gegenüber dem NPS.

Als Nachteil des Netgear-Geräts hat sich erwiesen, das bei der Anmeldung am Web-Interface kein Benutzername abgefragt wird. An dieser Stelle geht man, d.h. das Gerät bzw. Netgear, einfach von “admin” aus.

Im Gegensatz zum Cisco Switch unterscheidet der Netgear nicht zwischen lokalem und remote RADIUS bzw. man kann es dort schlichtweg nicht so konfigurieren, gegen welche Instanz die Anmeldung am Web-Interface authentifiziert werden soll.

Es wird lediglich eine Reihenfolge abgearbeitet. Dies äussert sich in diesem Beispiel so, das zuerst der remote RADIUS versucht wird und dann Lokal.

Ironischerweise funktioniert die RADIUS-Anmeldung für den Netgear-“admin” auch nicht, wenn man im AD einen “admin”-Benutzer anlegt.

Dennoch poste ich hier die Konfiguration für den Netgear Switch. Der Support ist über dieses Problem informiert und ich hoffe auf eine Lösung.

Update 03-02-2012

Heute kam die Antwort von Netgear. Die Smart Switche von Netgear können kein 802.1X mit Zertifikaten. Von daher ist die nachfolgende Konfigurationsanleitung für den Netgear Switch hinfällig.

Zwischenzeitlich hatte ich auch mal mit MD5 getestet. Dieses wird aber von Microsoft offiziell nicht mehr unterstützt und ist im NPS erst über einen Registry-Hack verfügbar. Auf dem Client benötigt man darüber hinaus eine andere Software. Das hat bei mir allerdings nicht funktioniert.

Der Cisco Switch hingegen läuft hier ohne Probleme. Anleitung dazu findet sich unter der Netgear-Anleitung.

Konfiguration am Netgear ProSafe GS108T:

• Am Web-Interface anmelden.
• Zur Registerkarte “Security” wechseln.
• Im Abschnitt “Management Security” unter “RADIUS – Server Configuration” einen neuen RADIUS-Server-Eintrag hinzufügen.

• Zu “Authentication List” wechseln.
• “defaultList” von “Local – None – None” auf “RADIUS – Local – None” ändern.
• In den Bereich “Port Authentication” wechseln.
• Unter “Advanced – 802.1X Configuration” “Port Authentication” den Port, an dem der NPS angeschlossen ist auf “Authorized” konfigurieren. Andernfalls schliesst man sich selbst aus dem Netzwerk aus.
• Unter “Advanced – 802.1X Configuration” “Port Based Authentication State” aktivieren.

Da ich eine funktionierende Konfiguration testen wollte, besorgte ich mir ein anderes Gerät. Einen Cisco SG 200-08. Mit diesem Gerät funktioniert die 802.1X-Authentifizierung. Anbei die Konfiguration dieses Geräts:

• Am Switch via Browser anmelden.
• Auf “Security – RADIUS” klicken.
• Auf “Add…” klicken und die Angaben für den RADIUS-Server, also dem NPS, eintragen. Per Standard ist “Message Authenticator” aktiviert. Dies muss bei der Konfiguration des RADIUS-Client im NPS beachtet werden. D.h. im NPS ebenfalls aktivieren.

• Auf “Security – 802.1X – Properties” klicken.
• “Port Based Authentication State” aktivieren und “Authentication Method” auf “Radius” konfigurieren.

• Auf “Security – 802.1X – Port Authentication” klicken.

Nun jeden Port, für den die 802.1X Authentifizierung gelten soll auf “Administrative Port Control: Auto” konfigurieren. Hierzu den jeweiligen Port auswählen und auf “Edit…” klicken.

In diesem Beispeil habe ich den Port, an dem der NPS hängt, auf “Administrative Port Control: Force Authorized” konfiguriert.

Hier mal ein Screenshot des Microsoft Network Monitors mit einer erfolgreichen Authentifizierung:

Client-Konfiguration

Auf dem Client (Windows 7) muss der Dienst “Automatische Konfiguration (verkabelt)” gestartet sein. Per Standard ist dieser Dienst auf “Manuell” eingestellt. Netzwerkweit kann man den Starttyp “Automatisch” mit Hilfe der Gruppenrichtlinien konfigurieren.

Ich habe mit zwei Clients getestet. Es zeigte sich, das zwar unter Umständen das Starten des Dienstes und das de- und wieder aktivieren der Netzwerkkarte bzw. kurz das Netzwerkkabel abziehen und wieder anstecken funktionieren kann, der sichere Weg allerdings ein Neustart ist.

Ferner muss der Client der Zertifizierungsstelle vertrauen und ggf. ein eigenes Zertifikat besitzen. Die genaue Konfiguration kommt auf die NPS-seitig verwendete Authentifizierungsmethode drauf an.

Leicht off-topic, aber dennoch interessant ist dieser Beitrag auf administrator.de:

Netzwerk Zugangskontrolle mit 802.1x und FreeRadius am LAN Switch

Heute habe ich wegen meines Problems mit dem Netgear Smart Switch GS108T v2 und 802.1X Authentifizierung eine Antwort vom Support erhalten.

“Dear Andreas,

unfortunately I have to say, that GS108Tv2 and others in Smart Switch range do not support certificate based 802.1x (PEAP).

You would need a fully managed switch for this.”

Auf deutsch:

Die Netgear Smart Switche können kein 802.1X mit Zertifikaten. Essig.

Also entweder habe ich das irgendwo übersehen oder im Handbuch und im Datenblatt steht das meines Wissens nach nicht. Auf der Homepage ist davon auch nicht die Rede.

Bereits in der c’t 17/2013 kam der ZyXEL Switch GS1910-24 gut weg. Mir persönlich gefiel neben dem günstigen Preis und der Ausstattung die geringe Leistungsaufnahme. Da bei uns ohnehin eine Erweiterung bzw. ein Austausch anstand und zudem Holger anfragte, das er Probleme mit diesem Switch in Verbindung mit 802.1X hat, folgte kurzerhand die Bestellung und ein Test.

Die (Test-)Umgebung

Um dem Problem von Holger nachzugehen, wurde die Umgebung von ihm in unserer Test-Umgebung nachgestellt. Dabei handelt es sich um ein Netzwerk auf der Basis von Microsoft Windows Server 2008 R2 Standard. Für die Test-Umgebung wurde ein Domänencontroller und ein Mitgliedsserver, der den RADIUS-Server darstellt, installiert.

Während der Fehlersuche bei Holger kam unter anderem der Verdacht auf, das möglicherweise die Zertifikatvorlage auf dem Mitgliedsserver nicht funktioniert. Hintergrund dieser Vermutung ist ein Hinweis im Abschnitt “802.1X Zertifikate” unter

http://www.msxfaq.de/verschiedenes/8021x.htm

In meinem Test konnte ich das allerdings nicht nachvollziehen. Mit anderen Worten: Es funktioniert(e).

802.1X funktioniert (vorerst) nicht

Als Grundlage für die Konfiguration von 802.1X diente dieser Beitrag, allerdings stellte sich schnell heraus, das irgendetwas faul ist. Zur Sicherheit wurde 802.1X im WLAN mit Hilfe eines Intellinet Wireless 300N 4-Port Routers (alternativ kann man auch den Intellinet Wireless 300N Access Point, diesen gibt’s auch mit PoE) getestet, dort funktioniert wiederum alles wie es soll.

Im Gegensatz zu dem damaligen Problem in Zusammenhang mit Netgear kam man allerdings etwas weiter. Wie man beim Mitschnitt im Network Monitor sehen kann kontaktiert der Switch den NPS, aber nach einem “Client Hello” kommt nichts mehr und das Ganze endet in einem Timeout. Im Ereignisprotokoll ist die Anforderung zu sehen, wird aber mit ID 6274 “interner Fehler” verworfen.

Was sagt der Support dazu?

Der ZyXEL-Support war überraschend schnell und relativ informativ. Schon kurz nach der Kontaktaufnahme am 25.10.2013 kam als Feedback, das man das Anliegen an die Entwicklung gemeldet hat. Am 28.10.2013 wurde man darüber informiert, das man das Problem nachstellen konnte und nach einer Lösung sucht. Wiederum am 04.11.2013 kam die Nachricht, das man das Problem mit der nächsten Firmware-Version (geplant für Anfang/Mitte Dezember 2013) beheben wird. Also erstmal ein paar Tage warten, bis man die neue Firmware hat und dann geht’s (an dieser Stelle) weiter.

To be continued…

Beim vergangenen IT-Stammtisch (Grüße an dieser Stelle) kam die Frage auf, wie bei Ubiquiti UniFi eine Anbindung an das Active Directory erfolgen kann, um WLAN-Nutzer auf einem Schul-Campus mittels Benutzername und Kennwort zu authentisieren.

Wenn z.B. sowohl die gesamte Schülerschaft als auch der Lehrkörper und die Verwaltung bereits als Benutzer im Active Directory angelegt sind und diverse Ressourcen im LAN nutzen, ist der Gedanke naheliegend, das die vorhandenen Zugangsdaten für die WLAN-Anmeldung genutzt werden könnten.

Eine direkte Anbindung an das Active Directory bietet der Ubiquiti UniFi Controller nicht, dafür allerdings die Nutzung eines RADIUS-Servers. Letztgenannter kann auf einem Windows Server 2019 als Rolle in Form des NPAS (Network Policy and Access Services, f.k.a. NPS, Network Policy Server, dt. Netzwerkrichtlinien- und Zugriffsdienste) eingerichtet werden.

Zur Info: Abgesehen von der hier erwähnten Anmeldung via Benutzername und Kennwort besteht die Möglichkeit Zertifikate zu nutzen, siehe dazu die Links am Ende dieses Beitrags.

Windows Server 2019 vorbereiten

• Den „Server-Manager“ starten und für den gewünschten Server via „Rollen und Features hinzufügen“ die Rolle „Netzwerkrichtlinien- und Zugriffsdienste“ installieren.
• Ggf. den Server neustarten und anschließend den Server-Manager neustarten.
• Im „Server-Manager“ zu „NPAS“ wechseln, den entsprechender Server mit der rechten Maustaste anklicken oder alternativ auf „Tools“ und „Netzwerkrichtlinienserver“ klicken.
• Bei „Erste Schritte“ „RADIUS-Server für drahtlose oder verkabelte 802.1X-Verbindungen“ auswählen und auf „802.1X konfigurieren“ klicken.
• Bei „802.1X-Verbindungstyp auswählen“ den Punkt bei „Sichere Drahtlosverbindungen“ setzen.
• Einen neuen RADIUS-Client hinzufügen:
  Einen Anzeigenamen vergeben und als IP oder DNS-Eintrag den Access Point (nicht den Controller!) eintragen. Daraus ergibt sich, das alle Access Points als RADIUS-Clients eingetragen werden müssen! An dieser Stelle ist das maximale Limit der jeweiligen Windows Server-Ausgabe zu beachten!
  Einen geheimen Schlüssel eintragen bzw. generieren.
• Bei „Authentifizierungsmethode auswählen“ nun „Microsoft: Geschütztes EAP (PEAP)“ auswählen.
• Die Benutzergruppen die sich anmelden dürfen auswählen.

Bemerkung am Rande: Mitunter kommt es vor das in der MMC „Netzwerkrichtlinienserver“ unter „RADIUS-Clients“ die Clients doppelt dargestellt werden, es handelt sich lediglich um einen Anzeigefehler der in der Regel nach einem Neustart der MMC behoben ist.

Ubiquiti UniFi Controller konfigurieren

• Am Ubiquiti UniFi Controller anmelden.
• Zu „Einstellungen – Profile“ wechseln.
• Ein neues Profil mit folgenden Einstellungen anlegen:
  Einen Namen, z.B. „AD-NPAS“, vergeben.
  Bei „RADIUS-Authentifizierungsserver“ die IP-Adresse und den Port des NPS sowie den zuvor genutzten geheimen Schlüssel eintragen.
• Zu „Einstellungen – Drahtlos-Netzwerke“ wechseln.
• Ein neues WLAN-Netz mit folgenden Einstellungen anlegen:
  Einen Namen (SSID), z.B. „campus“, vergeben.
  Bei „Sicherheit“ „WPA2 Enterprise“ auswählen.
  Bei „RADIUS-Profil“ das zuvor angelegte Profil auswählen.

Endgerät(e) (z.B. Smartphone, Tablet) konfigurieren

Am Beispiel von Android 9 sieht die notwendige Konfiguration wie folgt aus:

Wenn man mehr Sicherheit haben oder je nach Client eine Zertifikatswarnung vermeiden möchte, muss der CA vertraut werden. Dies erfordert dann entweder öffentliche Zertifikate oder bei Domänen-Mitgliedern die automatische Zertifikatsverteilung oder manuell den Import des CA-Zertifikats.

Troubleshooting

Manche Fehler baut man unabsichtlich oder es kommt zu andeen unerwarteten Dingen: Im Testlab befindet sich der Windows Server hinter einer Hardware-Firewall, während der UniFi Controller und der Access Point sich in einem anderem Netz befinden. Bei ersten Verbindungsversuchen wunderte ich mich, das zwar laut SmartSniff und Wireshark die RADIUS-Anfrage bis zum NPAS durchkamen, aber es danach nicht weiterging, sprich die Clients sich nicht am WLAN anmelden konnten.

Ursache dafür war bzw. ist die Windows-Firewall: Obwohl es eine Richtlinie mit dem Namen „Netzwerkrichtlinienserver (RADIUS-Authentifizierung – UDP – eingehend)“ gibt und diese sowohl aktiviert als auch für den Port 1812/udp durchlässig (keine Einschränkung hinsichtlich Netzwerkkategorie oder auf bestimmte Subnetze) ist, kommt die Anfrage nicht beim NPAS an. Interessanterweise steht auch nichts im eigens aktiviertem Firewall-Log. Als Workaround kann man eine Port-Regel erstellen die 1812/udp zulässt.

Als weiterers kann hilfreich sein im NPAS die Kontoführung zu aktivieren und das Ganze in eine Protokolldatei schreiben zu lassen. Zusätzlich speziell den Haken bei „Verbindungsanforderungen bei Protokollierungsfehlern verwerfen“ entfernen um weitere Erkenntnisse zu erlangen.

Abschlussbemerkung und Danksagung

Zum Abschluss noch ein Dankeschön nach Köln zu einem Kollegen der die nötige Richtung vorgegeben hat.

Quelle:

Ubiquiti – Blog – Managing RADIUS Authentication with UniFi

Windows: Drahtgebundenes LAN, 802.1X und NPS

Windows: Wireless LAN, 802.1x und NPS

Gyp the Cat dot Com – How to Configure Windows 2012 NPS for Radius Authentication with Ubiquiti Unifi

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/

Um unerwünschte Geräte im Netzwerk von vornherein auszusperren bietet sich eine Authenifizierung auf Basis von 802.1X an. Mit einem zusätzlichen Eintrag in der Registry kann dies auch für Hyper-V Hosts und virtuelle Maschinen genutzt werden.

Unter Windows Server 2019 und Windows 10 Pro (ab 1809) kann bei installierter Hyper-V-Rolle mit Hilfe des folgenden Befehls die Unterstützung für 802.1X für die virtuellen Netzwerk-Switche aktiviert werden:

Reg add "HKEY_LOCAL_MACHINE\SYSTEM\CURRENTControlSet\Services\vmsmp\parameters" /v 8021xEnabled /t REG_DWORD /d 1 /f

Anschließend muss der Computer einmal neu gestartet werden.

Hinweis: Damit die Registerkarte „Authentifizierung“ in den Eigenschaften der Netzwerkkarte(n) angezeigt wird, muss der Dienst „Automatische Konfiguration (verkabelt)“ (Dienstname: „dot3svc“) gestartet sein.

Sofern entsprechend konfiguriert kann der Host bereits 802.1X nutzen. Das Gleiche gilt für virtuelle Maschinen, sofern der entsprechende virtuelle Switch über einen physkalischen Adapter an einen realen Switch verbunden ist.

Virtuelle Switche (vSwitch) in Form einer virtuellen Maschine mit entsprechender EOPoL-Unterstützung habe ich leider noch nicht gesehen. Tipps hierzu sind willkommen.

Quellen:

Working Hard In IT – 802.1x Support with the Hyper-V switch is here!

Microsoft TechNet Forums – Authentication Tab does not appear even „Wired Autoconfig“ has started

Andy

Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.

www.andysblog.de/