So konfigurieren Sie SCEP für die automatisierte Zertifikatsregistrierung für Enterprise WiFi

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte Zertifikatsregistrierung für Enterprise WiFi konfigurieren. Er deckt die gesamte Architektur von PKI und NDES bis hin zur MDM-Profilbereitstellung und RADIUS-Validierung ab. Er richtet sich an IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien, Konferenzzentren und Organisationen des öffentlichen Sektors, die über Pre-Shared Keys hinausgehen und eine skalierbare, identitätsbasierte 802.1X EAP-TLS-Authentifizierung implementieren müssen. Die hardwareunabhängige Cloud-Overlay-Plattform von Purple lässt sich direkt in diese Architektur integrieren und bietet die Guest- und BYOD-WiFi-Ebene, die parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk läuft.

📖 10 Min. Lesezeit📝 2,282 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

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 stellt man eine zertifikatsbasierte WiFi-Authentifizierung über SCEP in einem großen Netzwerk tatsächlich skalierbar bereit? Ob es sich um einen Universitätscampus, eine Hotelgruppe mit mehreren Standorten oder eine große Liegenschaft des öffentlichen Sektors handelt – die Herausforderungen sind identisch.

Wir werden das gesamte Bild abdecken. 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, kein Tutorial. Ich gehe davon aus, 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.

Lassen Sie uns einsteigen.

Erste Prinzipien. 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 unkompliziert: die Automatisierung des Prozesses, ein digitales Zertifikat auf ein verwaltetes Gerät zu bringen, ohne dass ein Mensch jedes Gerät anfassen muss.

Im Kontext der WiFi-Authentifizierung ist SCEP der Bereitstellungsmechanismus. Das eigentliche Authentifizierungsprotokoll, das Sie anstreben, ist EAP-TLS (Extensible Authentication Protocol mit Transport Layer Security), das innerhalb des 802.1X-Frameworks angesiedelt ist. 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 Anmeldedaten abzufangen.

Und so funktioniert die gesamte Kette: Ein verwaltetes Gerät – das Laptop eines Studenten, das Telefon eines Mitarbeiters, ein Point-of-Sale-Terminal im Hotel – muss dem drahtlosen Unternehmensnetzwerk beitreten. Ihre MDM-Plattform, wie Microsoft Intune oder Jamf, sendet ein SCEP-Payload an dieses Gerät. Das 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 auf dem Gerät generiert, in der Secure Enclave oder im 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, wenn es sich mit Ihrer WiFi SSID verbindet, dieses Zertifikat dem RADIUS-Server. Der RADIUS-Server validiert das Zertifikat anhand Ihrer CA-Vertrauenskette, prüft die Zertifikatssperrliste (CRL), um zu bestätigen, dass das Zertifikat nicht widerrufen 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 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 ist für Anwendungsfälle wie die S/MIME-E-Mail-Verschlüsselung, bei denen eine Schlüsselhinterlegung (Key Escrow) erwünscht ist, völlig in Ordnung. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Der private Schlüssel verbleibt auf dem Gerät, Punkt.

Nun zur Hardware-Ebene. SCEP und EAP-TLS sind herstellerneutrale 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 eines Studenten erhält VLAN 20 nur für den Internetzugang. Ein Gerät einer Lehrkraft erhält VLAN 10 für den Zugriff auf interne Forschungssysteme. Ein Gerät der Gebäudeverwaltung erhält VLAN 30 für den 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 Identitätsanbietern können SCEP-Zertifikatsattribute, insbesondere der Subject Alternative Name (SAN), den Principal Name des Benutzers aus Microsoft Entra ID, Okta oder Google Workspace übertragen. Dadurch wird das Zertifikat an eine bestimmte Identität gebunden. Wenn Sie also 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 einfach nicht bieten können.

Lassen Sie uns nun über die Bereitstellungsreihenfolge sprechen, da hier die meisten Teams scheitern.

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, der wie eine Fehlkonfiguration aussieht, in Wirklichkeit aber nur ein Timing-Problem ist.

Der zweite Fallstrick ist die Gruppen-Zielgruppenadressierung. 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 führt bei Teams ständig zu Fehlern.

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 hierfür ist der Azure AD-Anwendungsproxy, nicht 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 Geräteauthentifizierung die Zertifikatsperrliste (CRL). 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. Machen Sie Ihre CRL-Endpunkte hochverfügbar und testen Sie die Sperrung, bevor Sie live gehen.

Für große Netzwerke 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.

Lassen Sie uns nun einige schnelle Fragen beantworten, die wir häufig von CTOs hören.

Kann SCEP BYOD-Geräte verarbeiten, die nicht MDM-registriert sind? Nicht direkt. SCEP erfordert eine MDM-Registrierung, um die Zertifikats-Payload bereitzustellen. Für nicht verwaltete BYOD-Geräte benötigen Sie einen anderen Ansatz: entweder ein Self-Service-Onboarding-Portal oder eine separate SSID mit einem Captive Portal mit Identitätsprüfung. Purple deckt diese Gast- und BYOD-Ebene sauber 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, aber das zugrunde liegende Protokoll ist identisch.

Funktioniert EAP-TLS mit WPA3? Ja. WPA3-Enterprise schreibt für sensible Umgebungen den 192-Bit-Sicherheitsmodus vor, und EAP-TLS ist vollständig kompatibel. Tatsächlich ist WPA3-Enterprise mit EAP-TLS die von der Wi-Fi Alliance empfohlene Kombination für Regierungs- und Finanznetzwerke.

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 gemeinsam genutzte 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 fest vorgegeben. Die Gruppen-Zielgruppenadressierung muss konsistent sein. Die CRL-Verfügbarkeit ist obligatorisch.

Speziell für den Hochschulbereich bietet die Kombination aus SCEP für Geräte von Mitarbeitern und Lehrkräften sowie einer separaten Gäste-WiFi-Ebene für Studenten auf privaten Geräten sowohl Sicherheit als auch eine hervorragende Benutzererfahrung ohne Kompromisse.

Wenn Sie tiefer einsteigen möchten, behandelt der Leitfaden von Purple zur Enterprise-WiFi-Authentifizierung 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 für den Widerruf.

Vielen Dank fürs Zuhören. Ich bin vom technischen Team von Purple, und wir sehen uns beim nächsten Briefing.

Wichtigste Erkenntnisse

✓SCEP (RFC 8894) automatisiert die Zertifikatsregistrierung für verwaltete Geräte - der private Schlüssel wird auf dem Gerät generiert und niemals übertragen, was es zur richtigen Wahl für die WiFi-Authentifizierung über PKCS macht.
✓Die Bereitstellungsreihenfolge ist nicht verhandelbar: Zuerst das Trusted Root-Zertifikat, zweitens das SCEP-Zertifikatsprofil, drittens das WiFi-Profil. Eine Verletzung dieser Reihenfolge führt zu Fehlern bei der Profilabhängigkeit.
✓Alle drei MDM-Profile (Trusted Root, SCEP, WiFi) müssen auf genau dieselbe Verzeichnisgruppe ausgerichtet sein. Gruppenübergreifendes Targeting ist die häufigste Ursache für Bereitstellungsfehler.
✓NDES sollte über den Azure AD-Anwendungsproxy veröffentlicht und nicht direkt im Internet freigegeben werden. Für Netzwerke mit mehr als 500 Geräten eliminiert ein Cloud-SCEP-Gateway den Single Point of Failure von NDES.
✓Die Verfügbarkeit des CRL-Verteilungspunkts ist eine netzwerkkritische Abhängigkeit. Wenn der RADIUS-Server die CRL nicht erreichen kann, schlägt er fehl und verweigert gleichzeitig alle Authentifizierungen.
✓EAP-TLS mit SCEP-bereitgestellten Zertifikaten erfüllt die PCI DSS 4.0-Anforderung 8.6 für drahtlose Netzwerke in Karteninhaber-Datenumgebungen und ist für WPA3-Enterprise 192-Bit (Suite B) erforderlich.
✓SCEP deckt nur verwaltete Geräte ab. Unverwaltete BYOD- und Gastgeräte erfordern eine separate SSID mit Captive Portal und Identitätsprüfung - die Plattform von Purple verwaltet diese Ebene parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk.

Management-Zusammenfassung

Für Unternehmen – ob ein Hotel mit 200 Zimmern, eine Einzelhandelskette mit 50 Standorten oder ein großes Konferenzzentrum – ist die Nutzung von Pre-Shared Keys für das Mitarbeiter-WiFi ein Sicherheitsrisiko und ein betrieblicher Engpass. Ein einziges durchgesickertes Passwort gefährdet das gesamte Netzwerk. Die zertifikatsbasierte Authentifizierung über IEEE 802.1X und EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) eliminiert dieses Risiko vollständig. Jedes Gerät weist seine Identität kryptografisch nach, bevor der Access Point den Netzwerkzugriff gewährt.

Die Herausforderung liegt in der Verteilung. Die manuelle Bereitstellung individueller Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten ist nicht praktikabel. SCEP (Simple Certificate Enrollment Protocol), das 2020 von der IETF als RFC 8894 formalisiert wurde, löst dieses Problem. Es automatisiert den Prozess der Anforderung, Ausstellung und Installation digitaler Zertifikate auf verwalteten Geräten über Ihre MDM-Plattform – ganz ohne Benutzerinteraktion.

Dieser Leitfaden deckt die gesamte Architektur ab: Was SCEP tut, wie es sich in Microsoft Intune, Jamf und andere MDM-Plattformen integrieren lässt, die genaue Bereitstellungsreihenfolge, bei der die meisten Teams Fehler machen, und die betrieblichen Fallstricke, die zu Ausfällen führen. Wir behandeln außerdem zwei reale Implementierungsszenarien aus der Hotellerie und dem Einzelhandel und erklären, wie sich die Guest WiFi -Plattform von Purple in Ihr zertifikatsauthentifiziertes Mitarbeiternetzwerk einfügt.

Hören Sie sich das begleitende Podcast-Briefing an:

Technischer Deep-Dive: SCEP, PKI und 802.1X

Was SCEP tatsächlich tut

SCEP ist kein Ersatz für Ihre Public Key Infrastructure (PKI). Es ist die automatisierte Registrierungsschicht, die darauf aufsetzt. Ihre PKI – in der Regel eine zweistufige Hierarchie mit einer Offline-Root-CA und einer Online-Ausstellungs-CA – bleibt der Vertrauensanker. SCEP automatisiert den Schritt, bei dem ein Gerät ein Zertifikat von dieser CA anfordert, wodurch die manuelle CSR-Generierung und Zertifikatsinstallation entfallen.

Im Kontext der WiFi-Authentifizierung ist das Zielprotokoll EAP-TLS. Dies ist die 802.1X-Authentifizierungsmethode, bei der sowohl das Client-Gerät als auch der RADIUS-Server gültige X.509-Zertifikate vorlegen müssen. Keine Seite vertraut der anderen ohne kryptografischen Nachweis. Dieses gegenseitige Authentifizierungsmodell eliminiert den Diebstahl von Anmeldedaten und schützt vor Evil-Twin-Angriffen, bei denen ein Angreifer einen gefälschten Access Point einrichtet, um Benutzernamen und Passwörter abzufangen.

Eine detaillierte Aufschlüsselung des EAP-TLS-Handshakes finden Sie in unserem Leitfaden über WiFi Certificate Authentication: Secure Network Access .

Der SCEP-Registrierungsablauf Schritt für Schritt

Die gesamte Registrierungskette funktioniert wie folgt: Ihre MDM-Plattform – Microsoft Intune, Jamf oder ein anderes MDM – sendet eine SCEP-Payload an ein verwaltetes Gerät. Diese Payload enthält zwei Dinge: die SCEP-URL, die auf Ihren NDES-Server (Network Device Enrollment Service) 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 die entscheidende Sicherheitseigenschaft von SCEP: Der private Schlüssel wird auf dem Gerät generiert, im Secure Enclave- oder TPM-Chip 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 das Challenge-Passwort, leitet die CSR an Ihre Zertifizierungsstelle (CA) weiter, und die CA signiert sie und gibt das öffentliche Zertifikat an das Gerät zurück.

Ab diesem Zeitpunkt 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 Ihrer CA-Vertrauenskette, prüft die Zertifikatssperrliste (CRL), um sicherzustellen, dass das Zertifikat nicht gesperrt wurde, und sendet bei erfolgreicher Prüfung eine Access-Accept-Nachricht an den Access Point. Das Gerät ist im Netzwerk. Der gesamte Prozess ist für den Benutzer unsichtbar.

SCEP vs. PKCS: Was ist für WiFi zu verwenden?

MDM-Plattformen wie Intune unterstützen zwei Mechanismen zur Zertifikatsbereitstellung: SCEP und PKCS (Public Key Cryptography Standards). Der architektonische Unterschied ist erheblich.

Bei SCEP wird der private Schlüssel auf dem Gerät generiert und verlässt dieses nie. Bei PKCS generiert die Zertifizierungsstelle sowohl den öffentlichen als auch den privaten Schlüssel zentral, und der Zertifikats-Connector überträgt das Schlüsselpaar über das Netzwerk auf das Gerät. Das bedeutet, dass der private Schlüssel übertragen wird, was eine theoretische Angriffsfläche darstellt.

PKCS eignet sich für Anwendungsfälle, in denen eine Schlüsselhinterlegung (Key Escrow) erforderlich ist, wie z. B. bei der S/MIME-E-Mail-Verschlüsselung. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Der private Schlüssel verbleibt auf dem Gerät.

Eigenschaft	SCEP	PKCS
Generierung des privaten Schlüssels	Auf dem Gerät (TPM/Secure Enclave)	Zentralisiert (CA)
Übertragung des privaten Schlüssels	Niemals	Über das Netzwerk
NDES-Server erforderlich	Ja (oder Cloud-Gateway)	Nein
Empfohlen für WiFi	Ja	Nein
Empfohlen für S/MIME	Nein	Ja

Hardware-Kompatibilität

SCEP und EAP-TLS sind herstellerneutrale Standards. Sie funktionieren über Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet hinweg. In Ihrer RADIUS-Konfiguration – ob Windows NPS, FreeRADIUS oder ein Cloud-RADIUS-Dienst – definieren Sie die Richtlinien zur Zertifikatsvalidierung und die dynamische VLAN-Zuweisung.

Über die dynamische VLAN-Zuweisung segmentieren Sie das Netzwerk basierend auf der Geräteidentität. Ein Mitarbeitergerät erhält VLAN 10 mit Zugriff auf interne Systeme. Ein Gerät eines externen Dienstleisters erhält VLAN 20 mit reinem Internetzugang. Ein Point-of-Sale-Terminal erhält VLAN 30 mit exklusivem Zugriff auf Zahlungsabwicklungssysteme. All dies wird durch Zertifikatsattribute und RADIUS-Richtlinien gesteuert, ohne dass ein manueller Eingriff pro Gerät erforderlich ist.

Weitere Informationen darüber, wie sich WiFi Analytics in die identitätsbasierte Netzwerksegmentierung integrieren lässt, finden Sie in unserer Übersicht zur Analyseplattform.

Implementierungsleitfaden: Die Bereitstellungsreihenfolge

Die erfolgreiche Konfiguration von SCEP für Enterprise WiFi erfordert die strikte Einhaltung einer bestimmten Bereitstellungsreihenfolge. MDM-Plattformen erzwingen Profilabhängigkeiten: Ein WiFi-Profil, das auf ein SCEP-Zertifikat verweist, kann erst angewendet werden, wenn dieses Zertifikat auf dem Gerät vorhanden ist. Die Missachtung dieser Reihenfolge ist die häufigste Ursache für Fehler bei der Bereitstellung.

Die Reihenfolge lautet: Trusted Root zuerst, SCEP-Profil an zweiter Stelle, WiFi-Profil an dritter Stelle. Diese Reihenfolge ist nicht verhandelbar.

Schritt 1: Bereitstellung des Trusted Root-Zertifikatprofils

Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle (CA) vertrauen. Exportieren Sie Ihr Root-CA-Zertifikat – und alle Intermediate-CA-Zertifikate – als .cer-Dateien. Erstellen Sie in Ihrem MDM-Admin-Center ein Profil für vertrauenswürdige Zertifikate (Trusted Certificate), laden Sie die .cer-Datei hoch und stellen Sie sie für Ihre Zielgerätegruppe bereit.

Wenn Sie eine zweistufige PKI-Hierarchie nutzen (empfohlen), müssen Sie sowohl das Root-CA- als auch das ausstellende CA-Zertifikat als separate Profile für vertrauenswürdige Zertifikate oder, je nach MDM-Plattform, als Kette in einem einzigen Profil bereitstellen.

Schritt 2: Konfiguration des SCEP-Zertifikatprofils

Sobald das Vertrauen hergestellt ist, konfigurieren Sie das SCEP-Profil, um den Geräten mitzuteilen, wie sie ihr Client-Zertifikat anfordern können.

Erstellen Sie ein neues Konfigurationsprofil und wählen Sie den Profiltyp SCEP-Zertifikat aus. Konfigurieren Sie das Format des Subject Name. Für die benutzergesteuerte Authentifizierung ist CN={{UserPrincipalName}} der Standard. Für die Geräteauthentifizierung (gemeinsam genutzte Geräte, IoT, POS-Terminals) verwenden Sie CN={{AAD_Device_ID}}. Stellen Sie die Schlüsselverwendung (Key usage) auf Digitale Signatur und Schlüsselverschlüsselung (Key encipherment) ein. Setzen Sie die erweiterte Schlüsselverwendung (Extended Key Usage) auf Client-Authentifizierung (OID: 1.3.6.1.5.5.7.3.2). Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten Trusted Root-Zertifikatprofil. Geben Sie die externe URL Ihres NDES-Servers an. Für Microsoft Intune im Speziellen muss der NDES-Server über den Azure AD-Anwendungsproxy veröffentlicht werden, damit sich Remote-Geräte registrieren können, bevor sie vor Ort eintreffen. Setzen Sie den NDES-Server nicht direkt dem Internet aus.

Schritt 3: Bereitstellen des 802.1X WiFi-Profils

Der letzte Schritt besteht darin, die WiFi-Konfiguration bereitzustellen, die die Zertifikate mit der Netzwerk-SSID verknüpft. Erstellen Sie ein Wi-Fi-Konfigurationsprofil. Geben Sie den Netzwerknamen (SSID) genau so ein, wie er von Ihren Access Points übertragen wird. Wählen Sie WPA2-Enterprise oder WPA3-Enterprise als Sicherheitstyp. Stellen Sie den EAP-Typ auf EAP-TLS ein. Wählen Sie in den Authentifizierungseinstellungen das in Schritt 2 erstellte SCEP-Zertifikatsprofil als Client-Authentifizierungszertifikat aus. Geben Sie das vertrauenswürdige Stammzertifikat für die Servervalidierung an – dies stellt sicher, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server und nicht mit einem betrügerischen Access Point verbindet.

Integration des Identity Providers

SCEP-Zertifikatsattribute – insbesondere der Subject Alternative Name (SAN) – können den Principal Name des Benutzers aus Microsoft Entra ID, Okta oder Google Workspace übertragen. Dadurch wird das Zertifikat an eine bestimmte Identität gebunden. 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. Dieser automatisierte Widerruf ist der Sicherheitsvorteil, den Pre-Shared Keys nicht bieten können.

Weitere Informationen zu EAP Method WiFi: A Guide to Secure Network Access , einschließlich PEAP-MSCHAPv2-Migrationspfaden, finden Sie in unserem speziellen Leitfaden.

Best Practices und Branchenstandards

Platzierung des NDES-Servers

Der NDES-Server muss aus dem Internet erreichbar sein, damit sich Geräte registrieren können, bevor sie vor Ort eintreffen. Veröffentlichen Sie die NDES-URL über den Azure AD-Anwendungsproxy. Dies bietet einen sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und ermöglicht es Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungsflow anzuwenden. Setzen Sie den NDES-Server niemals direkt dem Internet aus.

Für Netzwerke mit mehr als 500 verwalteten 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.

CRL-Verfügbarkeit

Ihr RADIUS-Server überprüft bei jeder Authentifizierung eines Geräts die Zertifikatssperrliste (Certificate Revocation List, CRL). Wenn Ihr CRL-Verteilungspunkt (CDP) 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. Konfigurieren Sie Ihren NPS- oder RADIUS-Server so, dass eine strenge CRL-Prüfung erzwungen wird, und sorgen Sie für eine hohe Verfügbarkeit Ihrer CRL-Endpunkte. Testen Sie den Widerruf vor der Liveschaltung.

Die PCI-DSS-4.0-Anforderung 8.6 schreibt eine Multi-Faktor-Authentifizierung auf der Netzwerkschicht für Karteninhaber-Datenumgebungen vor. EAP-TLS mit SCEP-bereitgestellten Zertifikaten erfüllt diese Anforderung für drahtlose Netzwerke in Umgebungen der Branchen Retail und Hospitality .

WPA3-Kompatibilität

EAP-TLS ist vollständig kompatibel mit WPA3-Enterprise. WPA3-Enterprise mit der 192-Bit-Sicherheitssuite (Suite B) schreibt EAP-TLS vor und ist die von der Wi-Fi Alliance empfohlene Kombination für Regierungs-, Finanz- und Gesundheitsnetzwerke. Wenn Sie in Umgebungen wie dem Gesundheitswesen oder dem Transportwesen mit strengen Compliance-Anforderungen bereitstellen, ist WPA3-Enterprise mit EAP-TLS die richtige Zielarchitektur.

BYOD und Gast-WiFi

SCEP erfordert eine MDM-Registrierung, um die Zertifikats-Payload zu übertragen. Unverwaltete BYOD-Geräte oder Gäste werden damit nicht abgedeckt. Für diese Anwendungsfälle benötigen Sie eine separate SSID mit einem Captive Portal und Identitätsprüfung. Die Plattform von Purple deckt diese Ebene nahtlos ab und läuft parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk. Unsere Guest WiFi -Plattform unterstützt bewusste Opt-ins, die Erfassung von First-Party-Daten und die Integration mit Microsoft Entra ID, Okta und Google Workspace zur Identitätsprüfung.

Fehlerbehebung und Risikominderung

WiFi-Profil kann nicht angewendet werden

Symptom: Das Gerät empfängt die Trusted Root- und SCEP-Zertifikate, aber das WiFi-Profil wird im MDM als „Fehler“ oder „Nicht anwendbar“ angezeigt.

Ursache: Diskrepanz bei der Gruppenzielausrichtung. Wenn das SCEP-Profil auf eine Benutzergruppe und das WiFi-Profil auf eine Gerätegruppe ausgerichtet ist, kann das MDM die Abhängigkeit nicht auflösen.

Lösung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die Trusted Root-, SCEP- und WiFi-Profile alle auf dieselbe Verzeichnisgruppe ausgerichtet sind.

NDES 403 Forbidden-Fehler

Symptom: Geräte können das SCEP-Zertifikat nicht abrufen. Die NDES-IIS-Protokolle zeigen HTTP 403-Fehler.

Ursache: Dem Dienstkonto des MDM-Zertifikatskonnektors fehlen die Berechtigungen „Lesen“ und „Registrieren“ für die Zertifikatsvorlage, oder die URL-Filterung der Firewall blockiert SCEP-Abfragezeichenfolgen-Parameter.

Lösung: Überprüfen Sie, ob das Konnektor-Konto über die Berechtigungen „Lesen“ und „Registrieren“ für die CA-Vorlage verfügt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.

Massenauthentifizierungsfehler nach CRL-Ablauf

Symptom: Alle Geräte im Netzwerk können sich gleichzeitig nicht authentifizieren.

Ursache: Die CRL ist abgelaufen oder die CDP-URL ist nicht erreichbar. Der RADIUS-Server kann die Gültigkeit der Zertifikate nicht bestätigen und bricht die Verbindung ab (Fail-Closed).

Lösung: Konfigurieren Sie die CRL-Überwachung und -Alarmierung. Veröffentlichen Sie CRLs mit einer Gültigkeitsdauer, die deutlich über dem Veröffentlichungsintervall liegt. Testen Sie die CDP-Erreichbarkeit vom RADIUS-Server aus vor dem Go-Live.

Zertifikatsablauf verursacht unbemerkte Fehler

Symptom: Einzelne Geräte können sich sporadisch und ohne klares Muster nicht verbinden.

Ursache: Client-Zertifikate sind abgelaufen und das MDM hat sie nicht erfolgreich erneuert.

Lösung: Konfigurieren Sie die Zertifikatsverlängerung so, dass sie bei 80 % der Zertifikatslebensdauer ausgelöst wird. Überwachen Sie die MDM-Registrierungsstatusberichte auf Geräte mit Zertifikatsfehlern. Legen Sie Zertifikatsgültigkeitsdauern fest, die für Ihren Geräteaktualisierungszyklus geeignet sind – in der Regel ein bis zwei Jahre für verwaltete Endpunkte.

ROI und geschäftliche Auswirkungen

Der Übergang zur SCEP-basierten 802.1X-Zertifikatsauthentifizierung liefert messbare Erträge in den Bereichen Sicherheit, Betrieb und Compliance.

Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi verursacht ein erhebliches Volumen an Support-Tickets – durch abgelaufene Passwörter, Sperren und Tippfehler. Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar. Unternehmen verzeichnen nach der Migration in der Regel eine Reduzierung des WiFi-bezogenen Helpdesk-Volumens um 70–80 %.

Sicherheitsniveau: EAP-TLS eliminiert das Abgreifen von Anmeldedaten (Credential Harvesting) und Man-in-the-Middle-Angriffe. Dies unterstützt direkt die Einhaltung von PCI DSS 4.0 für Netzwerke im Einzelhandel und im Gastgewerbe sowie die Anforderungen von GDPR Artikel 32 für angemessene technische Sicherheitsmaßnahmen.

Automatisierter Widerruf: Wenn ein Mitarbeiter das Unternehmen verlässt, führt die Deaktivierung seines Kontos in Microsoft Entra ID zum automatischen Zertifikatswiderruf und zur MDM-Abmeldung. Der WiFi-Zugriff wird ohne manuelles Eingreifen des Netzwerkteams gesperrt.

Netzwerksegmentierung: Die dynamische VLAN-Zuweisung über RADIUS-Zertifikatsattribute bietet Ihnen eine kryptografisch erzwungene Netzwerksegmentierung. Geräte landen basierend auf den Zertifikatseigenschaften im richtigen Netzwerksegment, nicht durch SSID-Auswahl oder MAC-Adressfilterung – beides lässt sich leicht umgehen.

Purple ist an über 80.000 Live-Standorten mit einer Betriebszeit von 99,999 % im Einsatz. Unsere Plattform ist nach ISO 27001, GDPR, CCPA und Cyber Essentials zertifiziert. Unser hardwareunabhängiges Cloud-Overlay lässt sich in Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet integrieren – so arbeiten Ihr zertifikatsauthentifiziertes Mitarbeiternetzwerk und unsere Gast-WiFi-Ebene auf derselben Infrastruktur.

Weitere Informationen darüber, wie Behavioral Analytics: Insights for WiFi Networks Ihre sichere Netzwerkbereitstellung ergänzen kann, finden Sie in unserem Analytics-Leitfaden.

Referenzen

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Schlüsseldefinitionen

SCEP (Simple Certificate Enrollment Protocol)

Ein in RFC 8894 formalisiertes Protokoll, das es verwalteten Geräten ermöglicht, automatisch X.509-Digitalzertifikate von einer Zertifizierungsstelle über HTTP anzufordern und zu empfangen, wobei ein gemeinsames Challenge-Passwort für die Erstauthentifizierung verwendet wird. Der private Schlüssel wird auf dem Gerät generiert und niemals übertragen.

Der Standardmechanismus, der von MDM-Plattformen wie Microsoft Intune und Jamf verwendet wird, um WiFi-Authentifizierungszertifikate in großem Umfang auf verwalteten Endpunkten bereitzustellen.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Die sicherste 802.1X-Authentifizierungsmethode, bei der sowohl das Client-Gerät als auch der RADIUS-Server gültige X.509-Zertifikate vorlegen müssen. Gegenseitige Authentifizierung bedeutet, dass keine Seite der anderen ohne kryptografischen Nachweis vertraut.

Das Ziel-Authentifizierungsprotokoll für Enterprise-WiFi. Vorgeschrieben oder dringend empfohlen von PCI DSS 4.0, WPA3-Enterprise 192-Bit (Suite B) und HIPAA für drahtlose Netzwerke, die sensible Daten verarbeiten.

NDES (Network Device Enrollment Service)

Eine Microsoft Windows Server-Rolle, die als Registrierungsstelle (RA) zwischen SCEP-fähigen Geräten und einer Zertifizierungsstelle fungiert. Sie validiert Challenge-Passwörter und leitet CSRs im Namen von Geräten ohne Domänen-Anmeldeinformationen an die Zertifizierungsstelle weiter.

Erforderliche Infrastruktur für die SCEP-Bereitstellung mit Microsoft Intune. Sollte über den Azure AD-Anwendungsproxy veröffentlicht werden, anstatt direkt im Internet exponiert zu sein.

PKI (Public Key Infrastructure)

Die Hierarchie von Zertifizierungsstellen, Richtlinien und Verfahren zur Ausstellung, Verwaltung und zum Widerruf digitaler Zertifikate. Eine zweistufige PKI besteht aus einer Offline-Root-Zertifizierungsstelle (dem übergeordneten Vertrauensanker) und einer Online-Ausstellungs-Zertifizierungsstelle (die die tägliche Zertifikatsausstellung übernimmt).

Die zwingende Voraussetzung für die Bereitstellung von EAP-TLS und SCEP. Die Root-Zertifizierungsstelle sollte offline (air-gapped) betrieben werden; ihr privater Schlüssel ist das Fundament Ihrer gesamten Zertifikats-Vertrauenskette.

CSR (Certificate Signing Request)

Eine von einem Gerät generierte Nachricht, die dessen öffentlichen Schlüssel und Identitätsinformationen enthält und an eine Zertifizierungsstelle gesendet wird, um ein signiertes digitales Zertifikat anzufordern. Bei SCEP wird der CSR auf dem Gerät generiert und vor der Übertragung in einen PKCS-Umschlag verpackt.

Wird während des SCEP-Registrierungsablaufs automatisch vom Gerät generiert. Der zur Signierung des CSR verwendete private Schlüssel verlässt das Gerät niemals.

CRL (Certificate Revocation List)

Eine von der Zertifizierungsstelle veröffentlichte Liste mit den Seriennummern von Zertifikaten, die vor ihrem Ablaufdatum widerrufen wurden. RADIUS-Server prüfen die CRL bei jedem Authentifizierungsversuch, um sicherzustellen, dass widerrufene Zertifikate nicht auf das Netzwerk zugreifen können.

Die Verfügbarkeit des CRL-Verteilungspunkts (CDP) ist kritisch. Wenn der RADIUS-Server die CRL nicht erreichen kann, blockiert er sicherheitshalber und verweigert jegliche Authentifizierung – was zu einem netzwerkweiten Ausfall führt.

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll, das eine zentrale Authentifizierung, Autorisierung und Benutzerverwaltung (AAA) für den Netzwerkzugriff bereitstellt. Bei 802.1X-WiFi validiert der RADIUS-Server Client-Zertifikate, prüft die CRL und sendet eine Access-Accept- oder Access-Reject-Nachricht an den Access Point.

Der Authentifizierungsserver im 802.1X-Modell aus Supplicant, Authenticator und Server. Typische Implementierungen sind Windows NPS, FreeRADIUS und Cloud-RADIUS-Dienste.

Dynamic VLAN assignment

Eine RADIUS-Funktion, die ein authentifiziertes Gerät basierend auf Zertifikatsattributen oder der Zugehörigkeit zu einer Verzeichnisgruppe einem bestimmten VLAN zuweist, anstatt sich auf die SSID-Auswahl oder MAC-Adressfilterung zu verlassen. Setzt die Netzwerksegmentierung anhand der Geräteidentität durch.

Ermöglicht es einer einzigen SSID, mehrere Gerätetypen mit unterschiedlichen Netzwerkzugriffsebenen zu bedienen. Ein Mitarbeitergerät erhält VLAN 10 (interner Zugriff); ein Auftragnehmergerät erhält VLAN 20 (nur Internet); ein POS-Terminal erhält VLAN 30 (nur Zahlungssysteme).

MDM (Mobile Device Management)

Software, die von IT-Teams verwendet wird, um Smartphones, Tablets und Laptops zu registrieren, zu konfigurieren, zu sichern und zu verwalten. MDM-Plattformen wie Microsoft Intune und Jamf nutzen SCEP-Profile, um Anweisungen zur Zertifikatsregistrierung ohne Benutzerinteraktion an verwaltete Geräte zu senden.

Die Voraussetzung für die SCEP-basierte Zertifikatsbereitstellung. Geräte müssen im MDM registriert sein, bevor sie SCEP- und WiFi-Profile empfangen können. Unverwaltete BYOD-Geräte erfordern einen separaten Onboarding-Ansatz.

Ausgearbeitete Beispiele

Ein Premier Inn-Hotel mit 200 Zimmern muss sein Mitarbeiter-WiFi für Point-of-Sale-Tablets und Smartphones des Housekeepings absichern. Derzeit wird ein Pre-Shared Key verwendet, der an externe Dienstleister durchgesickert ist. Die Geräte werden über Microsoft Intune verwaltet, wobei eine Mischung aus iOS- und Android-Geräten zum Einsatz kommt. Das Hotel nutzt HPE Aruba Access Points.

Implementieren Sie eine interne zweistufige Microsoft AD CS PKI. Konfigurieren Sie NDES auf einem dedizierten Windows Server und veröffentlichen Sie diesen über den Azure AD-Anwendungsproxy.
Erstellen Sie in Intune ein Profil für vertrauenswürdige Stammzertifikate, das die Stamm-CA- und ausstellenden CA-Zertifikate enthält. Weisen Sie dieses einer Azure AD-Gruppe „Mitarbeitergeräte des Hotels“ zu.
Erstellen Sie ein SCEP-Zertifikatsprofil in Intune, das auf die externe NDES-URL verweist. Legen Sie das Format des Antragstellernamens (Subject Name) auf CN={{AAD_Device_ID}} fest, da es sich um gemeinsam genutzte Geräte handelt. Stellen Sie die Schlüsselverwendung auf „Digitale Signatur“ und „Schlüsselverschlüsselung“ sowie die erweiterte Schlüsselverwendung auf „Clientauthentifizierung“ ein. Weisen Sie dieses der Gruppe „Mitarbeitergeräte des Hotels“ zu.
Erstellen Sie ein Wi-Fi-Profil für die Mitarbeiter-SSID und konfigurieren Sie WPA2-Enterprise und EAP-TLS. Wählen Sie das SCEP-Profil für die Clientauthentifizierung und die Stamm-CA für die Servervalidierung aus. Weisen Sie dieses der Gruppe „Mitarbeitergeräte des Hotels“ zu.
Konfigurieren Sie die HPE Aruba RADIUS-Einstellungen so, dass sie auf Windows NPS verweisen. Konfigurieren Sie auf dem NPS eine Netzwerkrichtlinie, die EAP-TLS erfordert und den Mitarbeitergeräten das VLAN 10 zuweist.
Sobald die Geräte die Profile erhalten und sich erfolgreich verbinden, ändern Sie den PSK auf der alten SSID und planen Sie deren Abschaltung.

Kommentar des Prüfers: Dieser Ansatz erkennt richtig, dass gemeinsam genutzte Geräte (POS, Housekeeping) eine gerätebasierte Authentifizierung (CN={{AAD_Device_ID}}) anstelle einer benutzerbasierten Authentifizierung erfordern, da mehrere Mitarbeiter dasselbe Gerät nutzen. Er folgt der vorgeschriebenen Reihenfolge für die Profilbereitstellung und stellt sicher, dass alle drei Profile auf dieselbe Azure AD-Gruppe ausgerichtet sind. Die Veröffentlichung von NDES über den Anwendungsproxy anstelle einer direkten Freigabe im Internet ist der korrekte Sicherheitsansatz für eine Hotelumgebung.

Eine Einzelhandelskette mit 50 Standorten möchte 802.1X für Firmen-Laptops an allen Standorten einführen. Sie nutzt Cisco Meraki Access Points und Microsoft Intune. Das Unternehmen möchte keine lokalen NDES-Server oder AD CS-Infrastrukturen an den einzelnen Standorten oder im eigenen Rechenzentrum bereitstellen und warten.

Implementieren Sie eine cloudbasierte PKI und einen SCEP-Gateway-Dienst, der über das SCEP-Protokoll in Intune integriert ist. Die Cloud-CA stellt Zertifikate aus; das Cloud-SCEP-Gateway übernimmt die CSR-Validierung.
Konfigurieren Sie den vom PKI-Anbieter bereitgestellten Cloud-RADIUS-Dienst im Cisco Meraki Dashboard unter „Wireless > Access Control“ für die Unternehmens-SSID. Stellen Sie die Sicherheit auf WPA2-Enterprise ein und verweisen Sie mit RADIUS auf den Cloud-Dienst.
Erstellen Sie in Intune ein Profil für vertrauenswürdige Stammzertifikate, das das Stammzertifikat der Cloud-CA enthält. Weisen Sie dieses der Gerätegruppe „Firmen-Laptops“ zu.
Erstellen Sie ein SCEP-Zertifikatsprofil, das auf die URL des Cloud-SCEP-Gateways verweist. Legen Sie den Antragstellernamen auf CN={{UserPrincipalName}} für die benutzerbasierte Authentifizierung fest. Weisen Sie dieses der Gruppe „Firmen-Laptops“ zu.
Erstellen Sie ein Wi-Fi-Profil für die Unternehmens-SSID mit EAP-TLS und verweisen Sie auf das SCEP-Profil und den Cloud-CA-Stamm. Weisen Sie dieses der Gruppe „Firmen-Laptops“ zu.
Wenn sich Laptops in Intune registrieren, fordern sie automatisch Zertifikate von der Cloud-CA über das Cloud-SCEP-Gateway an. An keinem der 50 Standorte ist eine lokale Infrastruktur erforderlich.

Kommentar des Prüfers: Dies ist die optimale moderne Architektur für verteilte Einzelhandelsumgebungen. Durch die Nutzung von Cloud-PKI und Cloud-RADIUS entfällt für das Unternehmen die Notwendigkeit, an jedem Standort eine komplexe lokale Infrastruktur (NDES, AD CS, NPS) zu warten. Das Cloud-SCEP-Gateway skaliert horizontal und ist von Natur aus hochverfügbar, wodurch der Single Point of Failure, den ein lokales NDES darstellt, eliminiert wird. Die Cloud-verwaltete Architektur von Cisco Meraki passt hervorragend zu diesem Ansatz.

Übungsfragen

Q1. Ihre Organisation migriert von PEAP-MSCHAPv2 zu EAP-TLS. Sie haben die Profile für die vertrauenswürdige Stammzertifizierungsstelle (Trusted Root) und SCEP erfolgreich für Ihre Azure AD-Gruppe "Corporate Users" in Intune bereitgestellt. Sie stellen das WiFi-Profil für "All Corporate Devices" bereit. Benutzer melden, dass sie keine Verbindung herstellen können und das WiFi-Profil als "Nicht anwendbar" angezeigt wird.

Hinweis: Überprüfen Sie die Profilabhängigkeiten und die Regeln für die Gruppenzuweisung. Intune löst Profilabhängigkeiten basierend auf der zugewiesenen Gruppe auf.

Musterlösung anzeigen

Das Problem ist eine Diskrepanz bei der Gruppenzuweisung. Das WiFi-Profil hängt vom SCEP-Profil ab, das einer Benutzergruppe ("Corporate Users") zugewiesen wurde. Das WiFi-Profil wurde einer Gerätegruppe ("All Corporate Devices") zugewiesen. Intune kann die Abhängigkeit nicht über verschiedene Gruppentypen hinweg auflösen. Die Lösung besteht darin, alle drei Profilzuweisungen – Trusted Root, SCEP und WiFi – so zu ändern, dass sie auf dieselbe Gruppe verweisen. Entscheiden Sie basierend auf Ihrem Authentifizierungsmodell (benutzerbasiert vs. gerätebasiert), ob Sie eine Benutzergruppe oder eine Gerätegruppe verwenden möchten, und wenden Sie dies konsistent auf alle drei Profile an.

Q2. Eine Sicherheitsüberprüfung ergibt, dass sich das geschäftliche Smartphone eines Mitarbeiters nach dessen Ausscheiden und der Deaktivierung seines Microsoft Entra ID-Kontos noch bis zu einer Woche lang mit dem Mitarbeiter-WiFi-Netzwerk verbinden kann.

Hinweis: Überlegen Sie, wie der RADIUS-Server feststellt, ob ein Zertifikat nach der Deaktivierung des Kontos noch gültig ist. Welcher Mechanismus wird zur Übermittlung des Sperrstatus verwendet?

Musterlösung anzeigen

Der RADIUS-Server führt keine strikte Prüfung der Zertifikatssperrliste (CRL) durch, oder die CRL wird zu selten veröffentlicht. Wenn ein Mitarbeiter ausscheidet, sollte das MDM das Gerät abmelden und die CA das Zertifikat sperren. Wenn der RADIUS-Server jedoch nicht bei jedem Authentifizierungsversuch die CRL prüft – oder wenn die CRL nur wöchentlich veröffentlicht wird –, wird das gesperrte Zertifikat weiterhin akzeptiert. Die Lösung umfasst drei Schritte: Konfigurieren Sie den RADIUS-Server so, dass bei jeder Authentifizierung eine strikte CRL-Prüfung erzwungen wird; konfigurieren Sie die CA so, dass sie die CRL in kürzeren Abständen (täglich oder häufiger) veröffentlicht; und stellen Sie sicher, dass das MDM so konfiguriert ist, dass es die Zertifikatssperrung auslöst, sobald ein Gerät abgemeldet wird.

Q3. Sie müssen einen sicheren WiFi-Zugang für bildschirmlose IoT-Geräte (smarte Thermostate, Digital-Signage-Player) bereitstellen, die keinen MDM-Agenten ausführen und kein Captive Portal anzeigen können. Können Sie SCEP für diese Geräte verwenden, und wenn nicht, was ist die empfohlene Alternative?

Hinweis: Berücksichtigen Sie die Voraussetzungen für die SCEP-Registrierung und welche Alternativen für Geräte existieren, die nicht im MDM registriert werden können oder keinen Browser anzeigen können.

Musterlösung anzeigen

SCEP kann für diese Geräte nicht verwendet werden. SCEP erfordert einen MDM-Agenten, um die Registrierungs-URL und das Challenge-Passwort zu empfangen, das Schlüsselpaar zu generieren und das resultierende Zertifikat zu installieren. Bildschirmlose IoT-Geräte, die keinen MDM-Agenten ausführen können, können nicht am SCEP-Registrierungsprozess teilnehmen. Die empfohlenen Alternativen sind: (1) MAC Authentication Bypass (MAB) in Kombination mit einer strikten VLAN-Segmentierung – der RADIUS-Server lässt das Gerät basierend auf seiner MAC-Adresse zu und verschiebt es in ein isoliertes IoT-VLAN ohne Zugriff auf Unternehmenssysteme; (2) falls das Gerät dies unterstützt, kann EST (Enrollment over Secure Transport, RFC 7030) Zertifikate für Geräte bereitstellen, die HTTPS, aber kein MDM unterstützen; (3) bei Geräten mit einer Verwaltungsoberfläche unterstützen einige Hersteller die SCEP-Registrierung direkt über die Geräte-Firmware, ohne dass ein MDM-Agent erforderlich ist. In jedem Fall sollten IoT-Geräte unabhängig von der verwendeten Authentifizierungsmethode in einem dedizierten VLAN isoliert werden.

Weiterlesen in dieser Reihe

The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

Dieser technische Leitfaden bietet einen definitiven Architektur-Entwurf und eine schrittweise Implementierungsstrategie für die Bereitstellung von WiFi-Zertifikaten in Unternehmen mittels SCEP. Er behandelt die entscheidenden Unterschiede zwischen SCEP und PKCS, die für den Erfolg erforderliche genaue Bereitstellungsreihenfolge sowie praxiserprobte Strategien zur Risikominderung für IT-Verantwortliche.

So implementieren Sie SCEP für die automatisierte WiFi-Zertifikatsregistrierung

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte WiFi-Zertifikatsregistrierung in Unternehmensstandorten implementieren. Er deckt den gesamten architektonischen Entwurf ab – vom PKI-Design und der MDM-Integration bis hin zur obligatorischen dreistufigen Bereitstellungssequenz – und zeigt IT-Managern und Netzwerkarchitekten, wie sie gemeinsame Anmeldeinformationen eliminieren, das Lebenszyklusmanagement von Zertifikaten automatisieren und PCI DSS- und GDPR-Anforderungen in großem Maßstab erfüllen.

Cisco SUDI verstehen: Hardware-basierte Geräteidentität in der Netzwerk-Zugriffskontrolle

Dieser Leitfaden beschreibt die technische Architektur von Cisco SUDI und erklärt, wie eine hardwareverankerte Identität die Netzwerk-Zugriffskontrolle sichert. Er bietet IT-Verantwortlichen konkrete Implementierungsschritte zur Bereitstellung der 802.1X EAP-TLS-Authentifizierung und zur Automatisierung des Zero Touch Provisioning an Unternehmensstandorten.