Enterprise SCEP-Einrichtungsleitfaden: Zertifikatsbasierte Wi-Fi-Authentifizierung für Hochschulen und große Netzwerke

Enterprise SCEP Setup Guide: Zertifikatsbasierte WiFi-Authentifizierung für Hochschulen 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, aber selten eine klare Antwort erhält: Wie implementiert man eigentlich eine zertifikatsbasierte WiFi-Authentifizierung im großen Stil unter Verwendung von SCEP in einem großen Netzwerk – sei es ein Universitätsgcampus, eine Hotelgruppe mit mehreren Standorten oder ein großer Bereich des öffentlichen Sektors? Wir werden das gesamte Bild betrachten. Was SCEP tatsächlich 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, kein Tutorial. Ich setze voraus, dass Sie wissen, was ein RADIUS-Server ist, und dass Sie sich wahrscheinlich bereits entschieden haben, sich von Pre-Shared Keys zu verabschieden. 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 bereits weit über ein Jahrzehnt zuvor im Unternehmenseinsatz weit verbreitet war. Seine Aufgabe ist unkompliziert: der Prozess, ein digitales Zertifikat auf ein verwaltetes Gerät zu übertragen, 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 sich innerhalb des 802.1X-Frameworks befindet. 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 – das Laptop eines Schülers, das Smartphone eines Mitarbeiters oder ein Kassenterminal im Hotel – muss sich mit dem drahtlosen Unternehmensnetzwerk verbinden. Ihre MDM-Plattform (wie Microsoft Intune oder Jamf) sendet ein SCEP-Payload an dieses Gerät. Dieses Payload 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 niemals. Er wird direkt auf dem Gerät generiert, im Secure Enclave oder TPM gespeichert und niemals über das Netzwerk übertragen. Das Gerät erstellt dann eine Zertifikatsignierungsanforderung (CSR) und sendet sie an das SCEP-Gateway. Das Gateway validiert die Challenge, leitet die CSR an Ihre Zertifizierungsstelle (CA) weiter, und die CA signiert sie und gibt 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 bei erfolgreicher Prüfung eine Freigabe an den Access Point. Das Gerät ist im Netzwerk. Der gesamte Prozess läuft für den Benutzer unsichtbar ab. Betrachten wir nun, wo SCEP im Vergleich zur Alternative PKCS steht. PKCS (Public Key Cryptography Standards) ist die andere Methode zur Zertifikatsbereitstellung, 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 (Key Escrow) erwünscht ist. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Der private Schlüssel verbleibt ausnahmslos auf dem Gerät. Nun zur Hardware-Ebene. SCEP und EAP-TLS sind herstellerunabhängige Standards. Das bedeutet, sie funktionieren über Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet hinweg. In Ihrer RADIUS-Konfiguration – sei es Windows NPS, FreeRADIUS oder ein Cloud-RADIUS-Dienst – definieren Sie die Richtlinie zur Zertifikatsprüfung und, was besonders wichtig ist, konfigurieren die dynamische VLAN-Zuweisung. Über dynamische VLANs segmentieren Sie das Netzwerk nach Identität. Ein Gerät eines Schülers erhält VLAN 20 – nur Internetzugang. Ein Gerät einer Lehrkraft erhält VLAN 10 – Zugriff auf interne Forschungssysteme. Ein Gerät der Gebäudeverwaltung erhält VLAN 30 – Zugriff auf Gebäudemanagementsysteme. All dies wird durch die Zertifikatsattribute und die RADIUS-Richtlinie gesteuert, ganz ohne manuelles Eingreifen pro Gerät. Für die Integration von Identitätsanbietern können SCEP-Zertifikatsattribute – insbesondere der Subject Alternative Name – den Principal Name des Benutzers aus Microsoft Entra ID, Okta oder Google Workspace übertragen. 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-Zugriff automatisch gesperrt. Das ist ein Szenario für den Widerruf, das Pre-Shared Keys schlichtweg nicht bieten können. --- EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND FALLSTRICKE - ca. 2 Minuten Kommen wir nun zur Bereitstellungsreihenfolge, denn hier unterlaufen den meisten Teams Fehler. Die Reihenfolge ist nicht verhandelbar: Zuerst das Trusted-Root-Zertifikat, zweitens das SCEP-Zertifikatsprofil, drittens das WiFi-Profil. Sowohl Intune als auch Jamf erzwingen 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. Das sieht dann nach einer Fehlkonfiguration aus, ist aber in Wahrheit nur ein Timing-Problem. Der zweite Fallstrick ist die Gruppenzielgerichtete Bereitstellung. Alle drei Profile – Trusted Root, SCEP und WiFi – müssen für genau dieselbe Azure AD- oder Jamf-Gruppe bereitgestellt werden. Wenn das SCEP-Profil auf eine Benutzergruppe und das WiFi-Profil auf eine Gerätegruppe abzielt, kann Intune die Abhängigkeit nicht auflösen, und das WiFi-Profil wird als „Nicht anwendbar“ angezeigt. Das sorgt bei Teams immer wieder für Probleme. 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 und nicht über das Öffnen eines Ports 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 Registrierungsdatenfluss anzuwenden. Viertens: CRL-Verfügbarkeit. Ihr RADIUS-Server überprüft bei jeder Authentifizierung eines Geräts die Zertifikatssperrliste (Certificate Revocation List). Wenn Ihr CRL-Verteilungspunkt nicht verfügbar ist – weil ein Server ausgefallen ist oder sich die URL geändert hat –, schlägt die Authentifizierung für jedes Gerät im Netzwerk gleichzeitig fehl. Das bedeutet einen campusweiten Ausfall. Stellen Sie Ihre CRL-Endpunkte hochverfügbar bereit und testen Sie den Widerruf, bevor Sie live gehen. Für große Netzwerke – alles mit mehr als 500 Geräten – sollten Sie ein Cloud-SCEP-Gateway anstelle eines lokalen NDES in Betracht ziehen. Cloud-Gateways eliminieren den NDES Single Point of Failure, skalieren horizontal und lassen sich in der Regel direkt in Cloud-RADIUS-Dienste integrieren, wodurch eine weitere Infrastrukturabhängigkeit entfällt. --- SCHNELLE FRAGERUNDE - ca. 1 Minute Kann SCEP mit BYOD-Geräten umgehen, die nicht im MDM registriert sind? Nicht direkt. SCEP erfordert eine MDM-Registrierung, um die Zertifikatsdaten bereitzustellen. Für unverwaltete BYOD-Geräte benötigen Sie einen anderen Ansatz – entweder ein Self-Service-Onboarding-Portal oder eine separate SSID, die ein Captive Portal mit Identitätsprüfung nutzt. Die Plattform von Purple deckt diesen Bereich für Gäste und BYOD nahtlos ab und läuft parallel zu Ihrem zertifikatsauthentifizierten 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 einen 192-Bit-Sicherheitsmodus für sensible Umgebungen vor, und EAP-TLS ist vollständig kompatibel. Tatsächlich ist WPA3-Enterprise mit EAP-TLS die von der Wi-Fi Alliance für Regierungs- und Finanznetzwerke empfohlene Kombination. --- ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE - ca. 1 Minute Zusammenfassend lässt sich sagen: Die SCEP-Zertifikats-WiFi-Authentifizierung ist die richtige Architektur für jedes Netzwerk mit mehr als 50 verwalteten Geräten. Sie eliminiert gemeinsame Anmeldedaten, bietet Ihnen eine Identität pro Gerät, ermöglicht eine dynamische VLAN-Segmentierung und lässt sich für eine automatisierte Sperrung direkt in Ihren Identitätsanbieter integrieren. Die Bereitstellungsreihenfolge – erst Trusted Root, dann SCEP-Profil, dann WiFi-Profil – ist festgelegt. Die Gruppenzielgruppen müssen konsistent sein. Die CRL-Verfügbarkeit ist nicht optional. Speziell für den Hochschulbereich bietet die Kombination aus SCEP für Mitarbeiter- und Dozentengeräte sowie einer separaten Gäste-WiFi-Ebene für Studierende auf privaten 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 Sperrungsworkflow. Vielen Dank fürs Zuhören. Ich bin vom technischen Team von Purple, und wir sehen uns beim nächsten Briefing. --- ENDE DES SKRIPTS