Netzwerkzugang mit RADIUS-as-a-Service und SCEPman

Mit RADIUS-as-a-Service und SCEPman benötigen Sie auch für die WiFi-Authentifizierung keine eigene PKI mehr.

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:

Radius Diagram

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:

Zertifikatsverteilung mit 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.

Image Description

Gruppen in Azure und Office 365

Seit gut anderthalb Jahrzehnten ist das Active Directory der typische Verzeichnisdienst bei Unternehmen. Entsprechend gehören Art und Bedeutung der zahlreichen Gruppentypen – wie Domain Local, Global und Universal – zum Basis-Know-how der AD-Administratoren. Doch im 100%-Cloud-Konzept ist das Azure Active Directory (Azure AD oder AAD) der zentrale Verzeichnisdienst, und das AD hat nur noch eine Legacy-Funktion. Das AAD ist technisch grundverschieden zum AD, entsprechend gibt es dort keine direkten Entsprechungen der Gruppentypen.

Unternehmen müssen sich also neu überlegen, für welche organisatorischen und Rechte-Strukturen sie welche Gruppentypen verwenden. Dieser Artikel gibt als Einstieg zur Entwicklung eines entsprechenden Konzepts einen Überblick der verschiedenen Gruppentypen in Office 365 und Azure und wie sie verschachtelt werden können. Das folgende Diagramm skizziert die Verschachtelungszusammenhänge (bitte nicht erschrecken, im Admin-Alltag muss man das nicht alles auswendig wissen):

Diagramm der Gruppenzusammenhänge

Manche Verschachtelungen sind über die Web-Konsole allerdings nicht möglich. Eine O365-Gruppe kann nur über PowerShell einer Distribution List hinzugefügt werden, nicht über die GUI. Wenn man einer Gruppe über das Azure-Portal ein nicht erlaubtes Gruppenmitglied hinzufügt, beispielsweise eine Security Group einer Mail-enabled Security Group, dann kommt leider auch keine Fehlermeldung, sondern im Gegenteil eine (falsche) Erfolgsmeldung. Alle Gruppen außer Azure AD Security Groups vom Mitgliedstyp Dynamic Device können Nutzer als Mitglied enthalten. Auch bei den PowerShell-CMDlets nicht gleich offensichtlich:

Office 365-Gruppen

Das Herzstück der Nutzerstruktur bei Office 365 sind die Office-365-Gruppen oder kurz O365-Gruppen. Ihre Funktion ist zugleich Sicherheitsgruppe, E-Mailverteiler und gemeinsame Dateiablage. Zahlreiche Office-365-Dienste basieren im Hintergrund auf einer O365-Gruppe, beispielsweise Teams oder Planner.

Eine wichtige Unterscheidung sind öffentliche und geschlossene O365-Gruppen. Öffentlichen Gruppen kann jeder Nutzer des Tenants selbst beitreten und auf Daten der Gruppe auch ohne Beitritt zugreifen. Bei geschlossenen O365-Gruppen ist die Unterscheidung zwischen Eigentümer und Mitglied wichtig: Eigentümer können Mitglieder aufnehmen und entfernen und nur als Mitglied kann man auf Daten der O365-Gruppe zugreifen.

Ein Group-Nesting von O365-Gruppen ist nicht möglich: Eine O365-Gruppe kann nur einzelne Nutzer als Mitglied haben, keine anderen Gruppen irgendeines Typs. Die O365-Gruppe kann selbst auch nicht Mitglied anderer O365- oder Security-Gruppen sein, außer von mail-enabled Security Groups und Verteilerlisten.

Teams

Jedes Team basiert auf einer O365-Gruppe. Ein Team enthält Channels mit eigenem Chat, eigenen Dateien und ähnlichem. Wenn man Mitglied eines Teams ist, also Mitglied der zugrundeliegenden O365-Gruppe, kann man jeden einzelnen Channel

  • nicht favorisieren,
  • favorisieren oder
  • favorisieren und dem Channel folgen.

Den Channel Allgemein/General favorisiert man als Team-Mitglied immer, zusätzlich kann man ihm folgen.

Security Groups

Als nahezu universelles Werkzeug der Berechtigungsverwaltung können Security Groups vom Mitgliedstyp Assigned/Zugewiesen (später mehr zur Alternative Dynamisch) fast alle anderen Objekttypen enthalten, nämlich neben Nutzern und Geräten auch dynamische Gruppen und Mail-enabled Security Groups. Was allerdings fehlt sind vor allem O365-Gruppen, was angesichts der zentralen Stellung der O365-Gruppen ein großes Manko ist.

Azure AD Dynamic Groups

Bei Sicherheitsgruppen vom Mitgliedstyp Dynamic/Dynamisch legt man die Mitglieder nicht manuell oder über ein Skript fest, sondern definiert Attribut-basierte Regeln darüber, wer Mitglied der Gruppe sein soll. Die Regeln werden automatisch von einem Hintergrunddienst evaluiert und die Mitgliedsliste neu geschrieben. Das erste Schreiben der Mitgliederliste kann bei großen Verzeichnissen bis zu 24 Stunden dauern. Eine Azure AD Dynamic Group kann nur entweder Nutzer oder Geräte enthalten, aber weder beides noch andere Gruppen.

Mail-enabled Security Groups

Nur auf den ersten Blick ähnlich zu Security Groups sind Mail-enabled Security Groups. Wie im Diagramm zu sehen, können Mail-enabled Security Groups nämlich keine Security Groups enthalten. Sie werden auch nicht über das Azure-Portal verwaltet, sondern über das Office-365-Portal.

Distribution List

Ein E-Mail-Verteiler hat technisch die gleiche Funktion wie on-premises: E-Mails an den Verteiler erreichen automatisch alle Mitglieder. Allerdings sind O365-Gruppen deutlich vielseitiger, so dass Distribution Lists in der Cloud eine deutlich untergeordnete Rolle spielen.

Exchange Dynamic Distribution Group

Auch dieser Gruppentyp ist über Exchange und Exchange Online direkt aus der on-premises-Welt übernommen worden und entspricht einer Distribution List, bei der die Mitglieder nicht einzeln eingetragen werden, sondern über bestimmte Regeln Attribut-basiert hinzugefügt oder entfernt werden. Da Azure AD Dynamic Groups nicht mail-enabled sein können, gibt es auch in der Cloud gelegentlich Anwendungsfälle für diesen Gruppentyp.

Azure AD Administrative Units

Administrative Units (AUs) entsprechen in ihrer Zielsetzung den Organizational Units (OUs) des alten Active Directory: Die Mitgliedschaft gibt den Mitgliedern nicht Zugriff auf zusätzliche Ressourcen, sondern lokale Administratoren erhalten Rechte zur Verwaltung der Mitglieder. Entsprechend stehen sie nicht in Beziehung zu den anderen Gruppentypen, Nesting ist also beispielsweise nicht möglich. Als Methode zur Strukturierung der Nutzerbasis gehören sie trotzdem in diese Übersicht.

Zusammenfassung

Das Azure AD räumt auf mit den alten Strukturen aus AD-Zeiten, dennoch gibt es schon einen bunten Strauß an neuen Gruppentypen, deren Zusammenhänge nicht auf den ersten Blick zu sehen sind. Einige Gruppentypen werden aber kaum gebraucht und verschwinden vielleicht mittelfristig ganz.

15.08.2018