Enterprise SCEP Setup-Leitfaden: Zertifikatsbasierte WiFi Authentifizierung für Hochschulen und große Netzwerke

Enterprise SCEP Setup Guide: Zertifikatsbasierte WiFi-Authentifizierung für den Hochschulbereich und große Netzwerke Ein Purple Technical Briefing - Podcast-Skript (ca. 10 Minuten) --- EINFÜHRUNG UND KONTEXT - ca. 1 Minute Willkommen zur Purple Technical Briefing-Reihe. Ich spreche heute über ein Thema, das in vielen IT-Postfächern landet, auf das es aber selten eine klare Antwort gibt: Wie stellt man eine zertifikatsbasierte WiFi-Authentifizierung mit SCEP in großem Maßstab in einem großen Netzwerk bereit - sei es auf einem Universitätsgelände, in einer Hotelgruppe mit mehreren Standorten oder in einer großen Behördenstruktur? Wir werden das gesamte Bild betrachten: Was SCEP eigentlich tut, wie es in eine 802.1X-Architektur passt, die Bereitstellungsreihenfolge, die die meisten Teams falsch machen, zwei reale Implementierungsszenarien und die Fallstricke, die Sie ein ganzes Wochenende kosten werden, wenn Sie sie nicht einplanen. Dies ist ein Berater-Briefing, keine Anleitung. Ich gehe davon aus, dass Sie wissen, was ein RADIUS-Server ist, und dass Sie sich wahrscheinlich bereits entschieden haben, von Pre-Shared Keys wegzugehen. Was Sie jetzt brauchen, ist der Implementierungsplan. Legen wir los. --- TECHNISCHER DEEP-DIVE - ca. 5 Minuten Zuerst die Grundlagen. SCEP steht für Simple Certificate Enrollment Protocol. Es wurde 2020 von der IETF als RFC 8894 formalisiert, obwohl es zuvor bereits weit über ein Jahrzehnt in Unternehmen im Einsatz war. Seine Aufgabe ist einfach: den Prozess der Bereitstellung eines digitalen Zertifikats auf einem verwalteten Gerät zu automatisieren, ohne dass ein Mensch jedes Gerät anfassen muss. Im Kontext der WiFi-Authentifizierung ist SCEP der Übertragungsmechanismus. Das eigentliche Authentifizierungsprotokoll, das Sie anstreben, ist EAP-TLS - Extensible Authentication Protocol mit Transport Layer Security - das innerhalb des 802.1X-Frameworks läuft. EAP-TLS gilt weithin als die sicherste Authentifizierungsmethode für drahtlose Unternehmensnetzwerke, da sowohl das Client-Gerät als auch der RADIUS-Server gültige Zertifikate vorlegen müssen. Keine Seite vertraut der anderen ohne kryptografischen Nachweis. Diese gegenseitige Authentifizierung schützt Sie vor Evil-Twin-Angriffen, bei denen ein Angreifer einen gefälschten Access Point einrichtet, um Zugangsdaten abzugreifen. So funktioniert die gesamte Kette. Ein verwaltetes Gerät - ein Laptop für Studierende, ein Telefon für Mitarbeitende, ein Terminal am Point-of-Sale im Hotel - muss sich mit dem drahtlosen Unternehmensnetzwerk verbinden. Ihre MDM-Plattform, z. B. Microsoft Intune oder Jamf, sendet eine SCEP-Nutzlast an dieses Gerät. Die Nutzlast enthält zwei Dinge: die SCEP-URL, die auf Ihren NDES-Server oder Ihr Cloud-SCEP-Gateway verweist, und ein Challenge-Passwort oder ein Shared Secret. Das Gerät generiert lokal sein eigenes öffentliches und privates Schlüsselpaar. Dies ist entscheidend. Der private Schlüssel verlässt das Gerät nie. Er wird auf dem Gerät generiert, in der Secure Enclave oder dem TPM gespeichert und niemals über das Netzwerk übertragen. Das Gerät erstellt dann eine Zertifikatsignierungsanforderung - einen CSR - und sendet sie an das SCEP-Gateway. Das Gateway validiert die Challenge, leitet den CSR an Ihre Certificate Authority (CA) weiter, und die CA signiert ihn und sendet das öffentliche Zertifikat an das Gerät zurück. Von diesem Zeitpunkt an präsentiert das Gerät dieses Zertifikat dem RADIUS-Server, wenn es sich mit Ihrer WiFi SSID verbindet. Der RADIUS-Server validiert das Zertifikat anhand der Vertrauenskette Ihrer CA, prüft die Zertifikatssperrliste (CRL), um sicherzustellen, dass das Zertifikat nicht gesperrt wurde, und sendet, wenn alles in Ordnung ist, eine Bestätigung an den Access Point. Das Gerät ist im Netzwerk. Der gesamte Prozess ist für den Benutzer unsichtbar. Lassen Sie uns nun darüber sprechen, wo SCEP im Vergleich zur Alternative, nämlich PKCS, steht. PKCS - Public Key Cryptography Standards - ist die andere Methode zur Bereitstellung von Zertifikaten, die von Plattformen wie Intune unterstützt wird. Bei PKCS generiert die CA sowohl den öffentlichen als auch den privaten Schlüssel zentral, und der Zertifikats-Connector überträgt das Schlüsselpaar auf das Gerät. Das bedeutet, dass der private Schlüssel über das Netzwerk übertragen wird, was eine theoretische Angriffsfläche darstellt. PKCS eignet sich gut für Anwendungsfälle wie die S/MIME-E-Mail-Verschlüsselung, bei denen eine Schlüsselhinterlegung tatsächlich erwünscht ist. Für die WiFi Authentifizierung ist SCEP die richtige Wahl. Der private Schlüssel bleibt auf dem Gerät, Punkt. Nun zur Hardware-Ebene. SCEP und EAP-TLS sind herstellerunabhängige Standards, was bedeutet, dass sie mit Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet funktionieren. In Ihrer RADIUS-Konfiguration - sei es Windows NPS, FreeRADIUS oder ein Cloud-RADIUS-Dienst - definieren Sie die Richtlinie zur Zertifikatsvalidierung und, was besonders wichtig ist, konfigurieren die dynamische VLAN-Zuweisung. Über dynamische VLANs segmentieren Sie das Netzwerk nach Identität. Ein Gerät von Studierenden erhält VLAN 20 - nur Internetzugang. Ein Gerät von Lehrkräften erhält VLAN 10 - Zugriff auf interne Forschungssysteme. Ein Gerät der Haustechnik erhält VLAN 30 - Zugriff auf Gebäudemanagementsysteme. All dies wird durch die Zertifikatsattribute und die RADIUS-Richtlinie gesteuert, ohne dass ein manueller Eingriff pro Gerät erforderlich ist. Für die Integration von Identity Providern können SCEP-Zertifikatsattribute - insbesondere der Subject Alternative Name - den Benutzerprinzipalnamen aus Microsoft Entra ID, Okta oder Google Workspace enthalten. Dadurch wird das Zertifikat an eine bestimmte Identität gebunden. Das bedeutet: Wenn Sie ein Konto in Entra ID deaktivieren und das MDM das Gerät abmeldet, wird das Zertifikat widerrufen und der WiFi-Zugang automatisch gesperrt. Das ist ein Szenario für den Widerruf, das Pre-Shared Keys schlichtweg nicht bieten können. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND FALLSTRICKE - ca. 2 Minuten Lassen Sie uns über die Bereitstellungsreihenfolge sprechen, denn hier stolpern die meisten Teams. Die Reihenfolge ist nicht verhandelbar: Trusted Root-Zertifikat zuerst, SCEP-Zertifikatsprofil an zweiter Stelle, WiFi-Profil an dritter Stelle. Intune und Jamf erzwingen beide Profilabhängigkeiten. Wenn Ihr WiFi-Profil auf ein SCEP-Zertifikat verweist, das noch nicht auf dem Gerät bereitgestellt wurde, schlägt das WiFi-Profil mit einem kryptischen Fehler fehl, der wie eine Fehlkonfiguration aussieht, aber eigentlich nur ein Timing-Problem ist. Der zweite Fallstrick ist die Gruppenzuweisung. Alle drei Profile - Trusted Root, SCEP und WiFi - müssen der exakt gleichen Azure AD- oder Jamf-Gruppe zugewiesen werden. Wenn das SCEP-Profil auf eine Benutzergruppe und das WiFi-Profil auf eine Gerätegruppe verweist, kann Intune die Abhängigkeit nicht auflösen und das WiFi-Profil wird als "Nicht anwendbar" angezeigt. Das überrascht Teams immer wieder. Drittens: Erreichbarkeit des NDES-Servers. Ihr NDES-Server muss aus dem Internet erreichbar sein, damit sich Geräte registrieren können, bevor sie vor Ort eintreffen. Der richtige Weg dorthin führt über den Azure AD-Anwendungsproxy, nicht über das Öffnen eines Lochs in Ihrer Firewall. Der Anwendungsproxy bietet Ihnen sicheren Remote-Zugriff ohne eingehende Ports und ermöglicht es Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungs-Flow anzuwenden. Viertens: CRL-Verfügbarkeit. Ihr RADIUS-Server überprüft bei jeder Authentifizierung eines Geräts die Zertifikatssperrliste (CRL). Wenn Ihr CRL-Verteilungspunkt nicht verfügbar ist - weil ein Server offline ist oder sich die URL geändert hat - schlägt die Authentifizierung für jedes Gerät im Netzwerk gleichzeitig fehl. Das führt zu einem campusweiten Ausfall. Machen Sie Ihre CRL-Endpunkte hochverfügbar und testen Sie den Widerruf, bevor Sie live gehen. Für große Netzwerke - alles über 500 Geräte - sollten Sie ein Cloud-SCEP-Gateway anstelle von On-Premises-NDES in Betracht ziehen. Cloud-Gateways eliminieren den Single Point of Failure von NDES, skalieren horizontal und lassen sich in der Regel direkt in Cloud-RADIUS-Dienste integrieren, wodurch eine weitere Infrastrukturabhängigkeit entfällt. --- SCHNELLE FRAGEN UND ANTWORTEN - ca. 1 Minute Kann SCEP BYOD-Geräte verarbeiten, die nicht im MDM registriert sind? Nicht direkt. SCEP erfordert eine MDM-Registrierung, um die Zertifikatsdaten bereitzustellen. Für unmanaged BYOD benötigen Sie einen anderen Ansatz - entweder ein Self-Service-Onboarding-Portal oder eine separate SSID mit einem Captive Portal und Identitätsprüfung. Die Plattform von Purple verarbeitet diese Gast- und BYOD-Ebene nahtlos und läuft parallel zu Ihrem zertifikatsbasierten Mitarbeiternetzwerk. Wie sieht es mit iOS und Android aus? Beide Plattformen unterstützen SCEP nativ. iOS unterstützt SCEP seit iOS 4. Android Enterprise unterstützt SCEP über Intune und andere MDMs. Die Konfiguration unterscheidet sich je nach Plattform geringfügig, das zugrunde liegende Protokoll ist jedoch identisch. Funktioniert EAP-TLS mit WPA3? Ja. WPA3-Enterprise schreibt den 192-Bit-Sicherheitsmodus für sensible Umgebungen vor, und EAP-TLS ist vollständig kompatibel. Tatsächlich ist WPA3-Enterprise mit EAP-TLS die Kombination, die von der Wi-Fi Alliance für Regierungs- und Finanznetzwerke empfohlen wird. - ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE - ca. 1 Minute Zusammenfassend lässt sich sagen: Die WiFi Authentifizierung mit SCEP-Zertifikaten ist die richtige Architektur für jedes Netzwerk mit mehr als 50 verwalteten Geräten. Sie eliminiert gemeinsam genutzte Anmeldedaten, bietet Ihnen eine gerätespezifische Identität, ermöglicht eine dynamische VLAN Segmentierung und lässt sich direkt in Ihren Identity Provider für eine automatisierte Sperrung integrieren. Die Bereitstellungsreihenfolge - Trusted Root, dann SCEP-Profil, dann WiFi-Profil - ist festgelegt. Das Gruppen-Targeting muss konsistent sein. Die CRL-Verfügbarkeit ist obligatorisch. Speziell für den Hochschulbereich bietet die Kombination aus SCEP für Mitarbeiter- und Fakultätsgeräte sowie einer separaten Guest-WiFi-Ebene für Studierende auf persönlichen Geräten sowohl Sicherheit als auch eine hervorragende Benutzererfahrung ohne Kompromisse. Wenn Sie tiefer einsteigen möchten, beschreibt der Leitfaden von Purple über Enterprise-WiFi-Authentifizierung ohne Active Directory oder On-Premises-Server den Cloud-nativen Pfad. Und wenn Sie darüber nachdenken, was passiert, wenn ein Mitarbeiter das Unternehmen verlässt, führt Sie unser Leitfaden zum Entzug des WiFi-Zugangs durch den gesamten Workflow zur Sperrung. Vielen Dank fürs Zuhören. Ich bin vom technischen Team von Purple, und wir sehen uns beim nächsten Briefing. - ENDE DES SKRIPTE