Bereitstellung von SCEP für sichere BYOD- und WiFi-Authentifizierung an Hochschulen

Willkommen zum Purple Technical Briefing. Ich bin Ihr Gastgeber, und heute befassen wir uns mit einem Thema, das in der IT von Hochschuleinrichtungen ständig aufkommt: der Bereitstellung von SCEP für eine sichere BYOD- und WiFi-Authentifizierung. Wenn Sie PEAP-MSCHAPv2 in Ihrem Campus-Netzwerk einsetzen, ist dieses Briefing direkt für Sie relevant. Und wenn Sie bereits den Wechsel zu einer zertifikatsbasierten Authentifizierung planen, liefern wir Ihnen die Architektur, die Fallstricke und den Implementierungsablauf, um dieses Ziel zu erreichen. Beginnen wir mit dem Problem. Universitäten sind von Natur aus offene Umgebungen. Studierende kommen im September mit zwei, drei, manchmal fünf persönlichen Geräten an. Sie erwarten, sich sofort, sicher und ohne den Helpdesk kontaktieren zu müssen, zu verbinden. Die Realität für die meisten Institutionen ist eine Helpdesk-Warteschlange, die innerhalb von achtundvierzig Stunden nach Semesterbeginn zweitausend Tickets erreicht. Das ist kein Personalproblem. Das ist ein Architekturproblem. Die Ursache ist fast immer dieselbe: passwortbasierte WiFi-Authentifizierung. Wenn Sie WPA2-Enterprise mit PEAP und MSCHAPv2 betreiben, verlangen Sie von den Studierenden, die 802.1X-Einstellungen auf jedem Gerät manuell zu konfigurieren. Eine falsche Einstellung, und sie sind anfällig für einen Man-in-the-Middle-Angriff. Schlimmer noch: Wenn die Universität alle neunzig Tage eine Passwortänderung erzwingt, verliert jedes Gerät auf dem Campus gleichzeitig den WiFi-Zugang. Das ist eine vorhersehbare, vermeidbare Katastrophe. Die Lösung ist die zertifikatsbasierte Authentifizierung mittels EAP-TLS, und der Mechanismus, der sie skalierbar macht, ist SCEP: das Simple Certificate Enrollment Protocol. SCEP wurde 2020 von der IETF in RFC 8894 formalisiert, obwohl es bereits seit Anfang der 2000er Jahre im Einsatz ist. Es automatisiert den Prozess der Anforderung und Installation digitalen X.509-Zertifikate auf Geräten, ohne dass ein manueller IT-Eingriff pro Gerät erforderlich ist. Und so funktioniert es im Großen und Ganzen: Ihre MDM-Plattform, sei es Microsoft Intune oder Jamf, überträgt ein SCEP-Payload auf jedes registrierte Gerät. Dieses Payload enthält zwei Dinge: die SCEP-Gateway-URL und ein gemeinsames Challenge-Passwort. Das Gerät generiert eine Zertifikatssignierungsanforderung (Certificate Signing Request) und sendet sie an das SCEP-Gateway, welches das Challenge-Passwort validiert und die Anforderung an Ihre Zertifizierungsstelle (CA) weiterleitet. Die CA signiert das Zertifikat und sendet es an das Gerät zurück. Von diesem Zeitpunkt an authentifiziert sich das Gerät über EAP-TLS an Ihrem WiFi-Netzwerk: Das Zertifikat beweist dem RADIUS-Server die Identität des Geräts, und das Zertifikat des RADIUS-Servers beweist dem Gerät die Identität des Netzwerks. Gegenseitige Authentifizierung. Keine Passwörter, die über die Luft übertragen werden. Diese gegenseitige Authentifizierung ist entscheidend. Bei PEAP übergibt ein Studierender, der sich mit einem betrügerischen Access Point verbindet, der Ihre SSID ausstrahlt, bereitwillig seine Anmeldedaten. Bei EAP-TLS prüft das Gerät das Zertifikat des RADIUS-Servers, bevor es fortfährt. Wenn es nicht mit der vertrauenswürdigen CA übereinstimmt, schlägt die Verbindung im Hintergrund fehl. Damit haben Sie die gesamte Klasse der Evil-Twin-Angriffe eliminiert. Sprechen wir nun über die Architektur. Eine produktive SCEP-Bereitstellung für eine Universität besteht aus sechs Kernkomponenten. Erstens: Ihr Identitätsanbieter (Identity Provider): Microsoft Entra ID, Okta oder Google Workspace. Zweitens: Ihre MDM-Plattform: Intune für Windows und Android, Jamf für macOS und iOS. Drittens: Ihre Zertifizierungsstelle (Certificate Authority): entweder Microsoft Active Directory Certificate Services lokal (on-premises) oder eine Cloud-PKI. Viertens: Ihr SCEP-Gateway: der HTTP-Endpunkt, der Zertifikatsanfragen empfängt. Fünftens: Ihr RADIUS-Server für die Authentifizierung. Sechstens: Ihre Zugriffsebene (Access Layer): Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist Access Points, die für 802.1X konfiguriert sind. Die Vertrauenskette (Trust Chain) funktioniert wie folgt: Die CA stellt ein Root-Zertifikat aus. Dieses Root-Zertifikat wird über das MDM an jedes Gerät verteilt, wodurch Vertrauen hergestellt wird. Die CA stellt dann über SCEP Client-Zertifikate für die Geräte aus. Wenn sich ein Gerät verbindet, legt es dem RADIUS-Server sein Client-Zertifikat vor, und der RADIUS-Server legt dem Gerät sein Server-Zertifikat vor. Beide Seiten verifizieren dies anhand des vertrauenswürdigen Root-Zertifikats. Der Zugriff wird basierend auf der Gültigkeit des Zertifikats gewährt oder verweigert, nicht über ein Passwort. Lassen Sie mich Sie durch die Implementierungsreihenfolge führen. Dies ist die Reihenfolge, die funktioniert. Schritt eins: Bereinigen Sie Ihren Identitätsspeicher. Stellen Sie sicher, dass Ihr Active Directory oder Ihr Entra ID über klar definierte Gruppen für Studierende, Mitarbeitende und Gäste verfügt. Zertifikatsrichtlinien und VLAN-Zuweisungen werden mit diesen Gruppen verknüpft. Schritt zwei: Stellen Sie Ihre Zertifizierungsstelle (CA) bereit. Wenn Sie Microsoft ADCS verwenden, richten Sie eine zweistufige Hierarchie ein: eine Offline-Root-CA und eine Online-Aussteller-CA (Issuing CA). Die Root-CA sollte nach der Ersteinrichtung physisch vom Netz getrennt (air-gapped) werden. Schritt drei: Konfigurieren Sie Ihr SCEP-Gateway. Dies ist der HTTP-Endpunkt, auf den Ihr MDM die Geräte verweist. Stellen Sie sicher, dass er aus dem Netzwerksegment erreichbar ist, in dem die Geräte die Erstregistrierung durchführen, in der Regel Ihre Onboarding-SSID. Schritt vier: Konfigurieren Sie Ihren RADIUS-Server. Importieren Sie das Zertifikat der ausstellenden CA als vertrauenswürdige CA. Konfigurieren Sie EAP-TLS als Ihre Authentifizierungsmethode. Richten Sie VLAN-Rückgabeattribute ein, damit RADIUS Studierende dynamisch dem richtigen Netzwerksegment zuweisen kann. Schritt fünf: Konfigurieren Sie Ihre MDM-Profile. Erstellen Sie in Intune zuerst ein Profil für vertrauenswürdige Zertifikate (Trusted Certificate), dann ein SCEP-Zertifikatsprofil und anschließend ein WiFi-Profil, das auf das SCEP-Zertifikat verweist. Stellen Sie diese in genau dieser Reihenfolge bereit. Jedes Profil hängt davon ab, dass das vorherige bereits vorhanden ist. Schritt sechs: Konfigurieren Sie Ihre Access Points. Konfigurieren Sie auf Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist Ihre sichere SSID für WPA2-Enterprise oder WPA3-Enterprise. Stellen Sie das RADIUS-Timeout auf mindestens fünf Sekunden ein, um die Latenz bei der Zertifikatsvalidierung in Zeiten mit hohem Onboarding-Aufkommen aufzufangen. Nun zu den Fallstricken. Ich habe erlebt, wie diese Implementierungen immer wieder zum Scheitern brachten. Der erste Fehler ist die Bereitstellung von MDM-Profilen in der falschen Reihenfolge. Wenn das WiFi-Profil vor dem SCEP-Zertifikatsprofil auf dem Gerät eintrifft, verfügt das Gerät über kein Zertifikat, mit dem es sich authentifizieren kann. Die Verbindung schlägt fehl und der Benutzer wendet sich an den Helpdesk. Die zweite Falle ist das Vergessen von BYOD-Geräten. Intune und Jamf verwalten Ihre institutionseigene Flotte. Die privaten Geräte der Studierenden sind jedoch nicht in Ihrem MDM registriert. Für diese benötigen Sie ein Self-Service-Onboarding-Portal. Der Student authentifiziert sich per Single Sign-On mit seinen universitären Zugangsdaten, und das Portal nutzt SCEP zur Bereitstellung des Zertifikats. Die Plattform von Purple integriert diesen Onboarding-Flow direkt in das Captive Portal-Erlebnis, sodass Studierende die Registrierung in weniger als zwei Minuten und ganz ohne Beteiligung der IT abschließen können. Die dritte Falle sind RADIUS-Timeout-Fehler während der Haupt-Onboarding-Zeiten. Führen Sie Lasttests Ihrer RADIUS-Infrastruktur vor dem September durch, nicht erst währenddessen. Implementieren Sie ein Load Balancing über mindestens zwei RADIUS-Knoten hinweg. Die vierte Falle ist der Zertifikatswiderruf. Wenn ein Student die Universität verlässt oder ein Gerät verloren geht oder gestohlen wird, müssen Sie das Zertifikat sofort widerrufen. Stellen Sie sicher, dass Ihre CA eine Zertifikatssperrliste veröffentlicht und dass Ihr RADIUS-Server diese bei jeder Authentifizierung überprüft. Nun zu einer schnellen Fragerunde mit den Fragen, die wir am häufigsten hören. Kann SCEP ohne ein MDM funktionieren? Technisch gesehen ja, aber praktisch nein. Ohne ein MDM, das die SCEP-Payload und das WiFi-Profil pusht, sind Sie wieder bei der manuellen Gerätekonfiguration. Wie lange sollte die Gültigkeit von Zertifikaten sein? Für Geräte von Studierenden sind ein bis zwei Jahre Standard. Lang genug, um das akademische Jahr ohne Erneuerungsaufwand zu überstehen, kurz genug, um das Risiko bei der Kompromittierung eines Zertifikats zu begrenzen. Was ist mit IoT-Geräten, die 802.1X nicht unterstützen? Nutzen Sie MAC Authentication Bypass mit einem Self-Service-Geräteregistrierungsportal. Studierende registrieren die MAC-Adresse ihrer Spielkonsole oder ihres Smart-TVs, und Ihr NAC-System weist diese dem richtigen VLAN zu. Funktioniert das auch mit eduroam? Ja. EAP-TLS wird von der eduroam-Federation voll unterstützt. Von Ihrer Campus-CA ausgestellte Zertifikate können Studierende bei eduroam an jeder teilnehmenden Institution weltweit authentifizieren. Zum Abschluss sind hier die drei Entscheidungen, die eine erfolgreiche SCEP-Bereitstellung definieren. Erstens: Wählen Sie Ihre CA-Architektur vor allem anderen. On-Premises ADCS bietet Ihnen die volle Kontrolle. Cloud-PKI bietet Ihnen operative Einfachheit. Die falsche Wahl kostet Sie hier Monate an Nacharbeit. Zweitens: Automatisieren Sie das BYOD-Onboarding vom ersten Tag an. Gehen Sie nicht davon aus, dass Studierende ihre persönlichen Geräte manuell konfigurieren. Das werden sie nicht tun. Richten Sie das Self-Service-Portal vor Semesterbeginn ein. Drittens: Testen Sie Ihre RADIUS-Kapazität unter Last vor dem September. Ein RADIUS-Ausfall am ersten Tag des Semesters ist absolut vermeidbar. Die Plattform von Purple unterstützt alle drei Aspekte: Cloud-Overlay-PKI-Integration, Self-Service-BYOD-Onboarding über unser Captive Portal und eine RADIUS-Infrastruktur, die an achtzigtausend Live-Standorten mit einer Verfügbarkeit von neunundneunzig Komma neun neun neun Prozent getestet wurde. Vielen Dank, dass Sie am Purple Technical Briefing teilgenommen haben. Weitere Informationen finden Sie auf purple.ai.