Netzwerkzugang mit RADIUS-as-a-Service und SCEPman

Netzwerke absichern

Wie ich jüngst im iX-Artikel über PKI in Zeiten der Cloud beschrieben habe, ist WiFi-Authentifizierung oft die letzte Daseinsberechtigung für eine eigene PKI. Es gibt zwar verschiedene WiFi-Authentifizierungsmethoden, die ohne Zertifikate auskommen, aber keine ist so sicher und komfortabel. Bei Shared Secrets ist nicht kontrollierbar, welche Geräte WiFi-Zugang erhalten. Forms-basierte Authentifizierung, wie sie von mehreren Anbietern beworben und angeboten wird, verursacht Probleme mit Anwendungen, die den Anmeldedialog nur als gestörte Internetverbindung wahrnehmen, oder wenn die Forms-Erkennung mit dem neuesten Browser- oder Betriebssystem-Patch nicht mehr funktioniert. Passwortbasierte Nutzerauthentifizierung lässt sich nicht auf Geräte einschränken und Backups der Passwörter landen bei Google und Apple, während passwortbasierte Computerauthentifizierung ohnehin nur mit AD-Windows-Maschinen funktioniert.

RADIUS-as-a-Service

Glück & Kanja bietet deswegen seit geraumer Zeit unseren RADIUS-as-a-Service an. Dabei nutzen wir aus, dass Microsoft Intune ohnehin Zertifikate an alle Geräte verteilt, die über Intune verwaltet werden. Intune nutzt das Zertifikat intern, um die Geräte zu erkennen und zu authentifizieren. Da das Zertifikat für die Extended Key Usage Client Authentication zugelassen ist, kann man es auch für andere Client-Authentifizierungsvorgänge nutzen – zum Beispiel WiFi-Authentifizierung auf Basis von 802.1x.

Weil die Zertifikate tenant-übergreifend von einer zentralen Intune-CA ausgestellt werden, muss man jedoch bei der Authentifizierung unbedingt prüfen, ob das Zertifikat und damit die Maschine eigentlich zum eigenen Tenant gehört. Leider können gängige RADIUS-Produkte wie der Microsoft NPS und die Cisco ISE die Zertifikatserweiterung nicht auslesen, in der im Zertifikat die Tenant-ID hinterlegt ist. Unser RADIUS-as-a-Service basiert auf dem bewährten FreeRADIUS-Server, wurde aber so erweitert, dass er die entsprechenden Zertifikatserweiterungen erkennt und auswertet.

Die Einrichtung ist damit sehr einfach. Wir richten für jeden Kunden eine RADIUS-Schnittstelle in unserem Dienst ein. Der Kunde fügt seinen Access Points eine SSID hinzu, die auf unseren RADIUS-Dienst verweist (IP, Port & Shared Secret). Schließlich legt man in Intune ein Configuration Profile mit den WiFi-Einstellungen an. Schon können sich die eigenen Rechner, und nur diese, mit dem WiFi verbinden.

Die Intune-Zertifikate werden nie widerrufen, sie erhalten nicht mal eine CDP- oder OCSP-Erweiterung, die technisch vorausgesetzt wird, um sie überhaupt widerrufen zu können. Deswegen kann unser RADIUS-as-a-Service auch prüfen, ob die dem Zertifikat zugeordnete Maschine überhaupt noch im AAD vorhanden ist. Wenn nicht, wird die Authentifizierung abgelehnt. Das hat den zusätzlichen Vorteil, dass die Verwaltung des AADs ausreicht und nicht zusätzlich noch eine Sperrliste verwaltet werden muss, außerdem funktioniert die Zugangssperrung somit sogar in Echtzeit. Das folgende Diagramm zeigt diese Interaktion:

Mit seiner einfachen Struktur findet unser RADIUS-as-a-Service Anklang bei unseren Kunden. Zwei Wermutstropfen muss man dabei aber schlucken.

Zum einen kann man in Intune WiFi-Profile mit zertifikatsbasierter Authentifizierung zunächst nur verteilen, wenn man auch das entsprechende Zertifikat über ein Configuration Profile verteilt. Da das Intune-Zertifikat von selbst schon da ist, fehlt hier die entsprechende Auswahl. Auf Windows ist ein Workaround über ein Konfigurations-XML möglich, bei anderen Plattformen geht es so nicht.

Zum anderen gibt Microsoft keine Garantien zu den Eigenschaften des Zertifikats. Microsoft hat in der Vergangenheit bereits verschiedene Eigenschaften des ausgestellten Zertifikats geändert und wird dies wahrscheinlich auch in Zukunft tun. Möglicherweise verhindert eine zukünftige Änderung die Nutzung als WiFi-Zertifikat. Das betrifft dann natürlich nur ab dieser Änderung neu eingerichtete Clients, denn vorhandene Zertifikate sind für ihre Restlaufzeit von bis zu einem Jahr weiterhin gültig. Dennoch ist dies ein Risiko für die Infrastruktur, weil die IT so zu Änderungen in ihrer WiFi-Strategie gezwungen sein kann.

SCEPman

Diese Nachteile löst unser neues Produkt SCEPman. SCEP ist das Simple Certificate Enrollment Protocol und wurde ursprünglich von CISCO erfunden, um Netzwerkgeräte wie Switches und Router ohne Nutzerinteraktion mit Zertifikaten zu versorgen. Der ursprüngliche Anwendungsfall rückte irgendwann in den Hintergrund, heutzutage dient das Protokoll primär im MDM-Umfeld dazu, Mobilgeräte mit Zertifikaten zu versorgen und ist dabei der de-facto-Standard. Das Protokoll basiert auf HTTP und ist damit auch besonders Cloud-geeignet.

Microsoft bietet mit dem Network Device Enrollment Service (NDES) einen eigenen SCEP-Server, der im Hintergrund aber eine vollwertige Microsoft CA benötigt. NDES erfordert einen weiteren Server und braucht zur technischen Einrichtung nach meiner Erfahrung etwa so viel Aufwand wie der Aufbau einer Root- und Sub-CA der eigentlichen PKI. Dafür kann man über Intune an alle Plattformen ein Configuration Profile vom Typ “SCEP” verteilen. Alle von Intune unterstützen Betriebssysteme haben einen SCEP-Client eingebaut, der von einem SCEP-Server Zertifikate beziehen kann. Den SCEP-Dienst sollte man dabei ins Internet publizieren, zum Beispiel über einen AAD Application Proxy.

SCEPman dagegen ist eine Certification Authority (CA) direkt in der Cloud, die Zertifikate nur über SCEP verteilt. Als App Service muss man für den Betrieb nicht mal eine VM verwalten. Beim CA-Zertifikat haben wir das Rad nicht neu erfunden, sondern nutzen Microsoft Azure Key Vault – die Allround-Lösung von Microsoft zur Sicherung hochsensibler Informationen. SCEPman richtet ein Key Vault samt CA-Zertifikat bei der Installation ein, so dass man sich für den erfolgreichen Start und Betrieb von SCEPman um nichts kümmern muss. Mit Azure Key Vault als Standard-Produkt hat man dennoch alle Möglichkeiten: Man kann den CA-Schlüssel durch ein Hardware Security Module (HSM) absichern, ein neues selbstsigniertes Root-Zertifikat hinterlegen (BYOK) oder durch ein Sub-CA-Zertifikat einer vorhandenen PKI ersetzen.

Bei der Einrichtung wird man auch bei SCEPman ein SCEP-Profile in Intune anlegen. Die Clients erzeugen dann lokal ein Schlüsselpaar und einen Zertifikatsantrag, den sie SCEPman schicken. SCEPman leitet den Zertifikatsantrag zur Prüfung an Intune weiter, das bestätigen muss, dass der Antrag wirklich von Intune ausgelöst wurde. SCEPman erstellt dann aus dem Antrag ein Zertifikat und signiert es mit dem in Azure Key Vault hinterlegten CA-Schlüssel und -Zertifikat. Dieses Zertifikat sendet SCEPman zurück an den Client, der es zur Authentifizierung nutzen kann. Das folgende Diagramm zeigt die Zertifikatsverteilung über SCEPman:

Somit ist SCEPman kostengünstig, hochverfügbar, sicher und einfach im Betrieb. Er funktioniert mit allen Intune-unterstützten Plattformen, also Windows, iOS, Android und macOS. Auf Dienstseite werden die ausgestellten Zertifikate von allen gängigen Wireless-LAN-Controllern (WLC) unterstützt und natürlich auch von unserem RADIUS-as-a-Service.

Wer seinen vorhandenen WLC weiterverwendet, möchte sicher trotzdem gerne bestimmte Geräte aus dem eigenen WiFi aussperren, zum Beispiel weil man sie verloren hat oder weil sie ausgemustert wurden. SCEPman bietet diese Funktion über einen Online Certificate Status Protocol Responder (OCSP Responder). Bei OCSP kann ein System, hier der WLC, den Wideruf eines Zertifikats prüfen, indem er bei einer im Zertifikat von der CA eingetragenen URL nachfragt, ob das Zertifikat noch gültig ist. Der SCEPman prüft dazu, ob es die Maschine noch im AAD gibt, für die das Zertifikat ausgestellt wurde – wenn ja, ist das Zertifikat gültig, wenn nein, ist das Zertifikat widerrufen. Löscht man eine Maschine aus dem AAD, ist damit ab sofort keine Anmeldung am WiFi mehr möglich.