Microsoft Intune WiFi Zertifikat-Bereitstellung über SCEP und PKCS

Die Intune WiFi-Zertifikatsbereitstellung verwendet drei Profile: ein vertrauenswürdiges Stammzertifikat, ein SCEP- oder PKCS-Clientzertifikat und ein auf EAP-TLS festgelegtes 802.1X WiFi-Profil. Bereitstellen Sie diese in genau dieser Reihenfolge und weisen Sie alle derselben Microsoft Entra ID-Gruppe zu. SCEP erstellt den privaten Schlüssel auf dem Gerät, während PKCS ihn zentral erstellt. Für WiFi auf Windows, iOS und Android wählen Sie SCEP.

Was macht die Intune WiFi-Zertifikatsbereitstellung eigentlich?

Intune gibt jedem verwalteten Gerät seine eigene Identitätszertifikat und die WiFi-Einstellungen, um dieses vorzuweisen. Das Gerät tritt dann Ihrem Mitarbeiter-Netzwerk bei, ohne dass jemand ein Passwort eingeben muss.

Der Mechanismus ist IEEE 802.1X, der Standard für portbasierte Netzwerzzugangskontrolle. Unter 802.1X hält der Access Point ein Gerät vom Netzwerk fern, bis ein Authentifizierungsserver es genehmigt. Dieser Server ist ein RADIUS-Server, der Dienst, den Ihre Access Points abfragen, bevor sie ein Gerät zulassen.

Die Authentifizierungsmethode ist EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definiert in RFC 5216. Beide Seiten weisen ihre Identität mit Zertifikaten nach:

• Das Gerät weist ein Clientzertifikat vor.
• Der RADIUS-Server weist ein Serverzertifikat vor.
• Jede Seite prüft, ob das Zertifikat der anderen Seite auf eine Zertifizierungsstelle (CA) zurückgeht, der sie vertraut.

Es wird kein Passwort eingegeben, gespeichert oder Phishing ausgesetzt.

Das wird von Jahr zu Jahr wichtiger. Microsoft dokumentiert, dass Windows Defender Credential Guard Single Sign-On für passwortbasierte 802.1X-Methoden wie PEAP-MSCHAPv2 blockiert. PEAP (Protected EAP) sendet ein Passwort in einem verschlüsselten Tunnel. Credential Guard ist auf neueren Windows 11 Enterprise-Builds standardmäßig aktiviert, und Microsoft empfiehlt stattdessen die zertifikatsbasierte Authentifizierung.

Intune bereitstellt zertifikatsbasiertes WiFi über drei Konfigurationsprofile:

• Profil für vertrauenswürdige Zertifikate. Installiert Ihre Stamm-CA und alle Zwischen-CAs. Das Gerät kann dann seiner eigenen Zertifikatskette und Ihrem RADIUS-Server vertrauen.
• SCEP- oder PKCS-Zertifikatsprofil. Stellt jedem Gerät ein eindeutiges Clientzertifikat aus.
• WiFi-Profil. Legt die SSID (den ausgestrahlten Netzwerknamen), den Sicherheitstyp und die EAP-Methode fest. Es benennt auch das vorzuweisende Zertifikat und den Server, dem vertraut werden soll.

Für Betreiber von Veranstaltungsorten ist dies die Mitarbeiterseite des Netzwerks. Mitarbeiter-Laptops, Handhelds und Tablets in Hotels, Retail und Healthcare benötigen Zugriff auf Systeme, die Gäste, Käufer und Patienten niemals erreichen dürfen. Ihr Guest WiFi behält sein Captive Portal, die Anmeldeseite, die Besucher sehen. Mitarbeitergeräte authentifizieren sich im Hintergrund auf einer separaten SSID und einem VLAN, einem logisch isolierten Netzwerksegment.

SCEP oder PKCS: Welches Zertifikatsprofil sollten Sie verwenden?

Beide Profile hinterlassen ein Clientzertifikat auf dem Gerät. Der Unterschied besteht darin, wo der private Schlüssel erstellt wird.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) lässt das Gerät sein eigenes Schlüsselpaar erzeugen. Das Gerät sendet eine Zertifikatssignierungsanfrage über einen Network Device Enrolment Service (NDES)-Server oder über Microsoft Cloud PKI. Die Zertifizierungsstelle (CA) signiert die Anfrage und gibt das Zertifikat zurück. Der private Schlüssel verlässt das Gerät zu keinem Zeitpunkt. Unter Windows kann das SCEP-Profil diesen Schlüssel im Trusted Platform Module (TPM), dem Hardware-Sicherheitschip, ablegen.

PKCS-Profile nutzen den Certificate Connector für Microsoft Intune, um das Zertifikat von Ihrer CA anzufordern. Das Schlüsselpaar wird außerhalb des Geräts erstellt. Intune übermittelt das Zertifikat und den privaten Schlüssel anschließend in verschlüsselter Form an das Gerät. Sie vermeiden so den Betrieb von NDES, aber der private Schlüssel existierte an einem anderen Ort als dem Gerät selbst.

Ein dritter Typ, importierte PKCS-Zertifikate, liefert Zertifikate aus, die Sie bereits besitzen. Der reguläre Einsatzzweck ist die S/MIME-E-Mail-Verschlüsselung, bei der Schlüssel hinterlegt werden. Für WiFi ist dies das falsche Werkzeug.

	SCEP über NDES und AD CS	SCEP über Microsoft Cloud PKI	PKCS über Connector und AD CS
Wo der private Schlüssel erzeugt wird	Auf dem Gerät	Auf dem Gerät	Außerhalb des Geräts, dann übermittelt
Zertifizierungsstelle	Ihre Unternehmens-CA der Active Directory-Zertifikatdienste (AD CS)	Von Microsoft gehostete CAs oder Ihre eigene Root-CA	Ihre AD CS Unternehmens-CA
On-Premises-Server, die Sie betreiben	CA, NDES-Server, Certificate Connector	Keine	CA, Certificate Connector
Insernetseitige Komponente	NDES-URL, veröffentlicht über den Microsoft Entra-Anwendungsproxy	Keine: Microsoft hostet den SCEP-Endpunkt	Keine: Der Connector verbindet sich nur ausgehend
Zusätzliche Lizenz	Keine über Windows Server hinaus	Cloud PKI-Add-on oder Microsoft Intune Suite	Keine über Windows Server hinaus
Einrichtungsaufwand	Am höchsten: CA, NDES, Connector und Proxy-Veröffentlichung	Am niedrigsten: CAs werden im Intune Admin Center erstellt	Mittel: CA und Connector, kein NDES
Für wen es sich eignet	Umgebungen mit AD CS, die Schlüssel auf dem Gerät halten wollen	Cloud-first-Umgebungen ohne On-Premises-PKI	Umgebungen mit AD CS, die keinen NDES-Endpunkt veröffentlichen können

Wählen Sie für WiFi SCEP, es sei denn, Sie können die entsprechenden Infrastrukturanforderungen nicht erfüllen. Ein Schlüssel, der das Gerät nie verlässt, kann weder von einem Server kopiert noch während der Übertragung abgefangen werden. Wählen Sie Microsoft Cloud PKI, wenn Sie keine On-Premises-PKI besitzen und keine aufbauen möchten. Wählen Sie PKCS, wenn Sie AD CS betreiben, aber keinen NDES-Endpunkt im Internet veröffentlichen können.

Was benötigen Sie, bevor Sie WiFi-Zertifikate mit Intune bereitstellen?

Bestätigen Sie jeden Punkt, bevor Sie ein einziges Profil erstellen. Die meisten fehlgeschlagenen Rollouts lassen sich auf eine Lücke in dieser Liste zurückführen.

• Lizenzierung. Jede Person benötigt eine Intune-Lizenz. Intune ist in Microsoft 365 E3, E5 und Business Premium sowie in Enterprise Mobility + Security E3 und E5 enthalten.
• Registrierte Geräte. Windows-Geräte sind in Microsoft Entra ID eingebunden, häufig über Windows Autopilot. iOS- und iPadOS-Geräte werden über die automatische Geräteregistrierung von Apple Business Manager registriert. Android-Geräte nutzen Android Enterprise. Microsoft hat die Geräteadministrator-Verwaltung für Geräte mit Google Mobile Services eingestellt; planen Sie daher mit Android Enterprise.
• Eine Zertifizierungsstelle (CA). Dies bedeutet eine AD CS Enterprise-CA, Microsoft Cloud PKI oder eine von Intune unterstützte Drittanbieter-CA.
• Eine Zertifikatvorlage. Veröffentlichen Sie auf AD CS eine Vorlage mit der erweiterten Schlüsselverwendung Client-Authentifizierung.
• Konnektor-Infrastruktur. SCEP auf AD CS benötigt einen NDES-Server und den Certificate Connector for Microsoft Intune. PKCS benötigt nur den Konnektor.
• Ein RADIUS-Server, der EAP-TLS unterstützt. Sein Serverzertifikat muss auf eine Stamm-CA zurückgehen, die Sie bereitstellen werden. Notieren Sie den genauen Namen auf diesem Zertifikat, da das WiFi-Profil ihn benötigt.
• Erreichbare Sperrung. Ihr RADIUS-Server muss die Zertifikatsperrliste (CRL) oder einen OCSP-Responder (Online Certificate Status Protocol) erreichen können. Ist dies nicht der Fall, schlägt die Authentifizierung fehl.
• Enterprise SSIDs. Ihre Access Points müssen eine WPA2-Enterprise oder WPA3-Enterprise SSID ausstrahlen, die auf Ihren RADIUS-Server verweist. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet unterstützen alle 802.1X.
• Entra ID-Gruppen. Erstellen Sie eine Pilotgruppe und eine Produktionsgruppe. Entscheiden Sie jetzt, ob diese Personen oder Geräte enthalten.
• Ein Bootstrap-Netzwerk. Ein Gerät benötigt Internetzugang, um sein Zertifikat abzurufen, bevor es der 802.1X SSID beitreten kann. Bieten Sie kabelgebundenen Zugang, mobile Daten oder eine isolierte Onboarding-SSID an. Zug- Betreiber, die Tablets an das Zugpersonal ausgeben, sollten diese im Depot bereitstellen, bevor die Tablets auf Reisen gehen.

Wie richten Sie SCEP- oder PKCS-WiFi-Zertifikate in Intune ein?

Die Intune-Dokumentation von Microsoft enthält die schrittweisen Anleitungen für jede Plattform. Die folgende Sequenz und die darin getroffenen Entscheidungen sind entscheidend für den Erfolg. Erstellen Sie einen Satz von Profilen pro Plattform: Windows, iOS/iPadOS und Android Enterprise.

Schritt 1: Bereitstellen des vertrauenswürdigen Stammzertifikat-Profils

Exportieren Sie Ihr Stamm-CA-Zertifikat als .cer-Datei. Erstellen Sie ein Profil für vertrauenswürdige Zertifikate, das dieses enthält. Jedes Profil für vertrauenswürdige Zertifikate enthält ein Zertifikat; erstellen Sie daher separate Profile für die Stamm-CA und für jede Zwischen-CA.

Unter Windows senden Sie das Stammzertifikat an den Computeraussteller-Speicher und Zwischenzertifikate an den Zwischenspeicher. Wenn eine andere CA Ihr RADIUS-Serverzertifikat signiert hat, stellen Sie auch dieses Stammzertifikat bereit. Ohne dieses können Geräte den Server nicht validieren.

Schritt 2: Bereitstellen des SCEP- oder PKCS-Zertifikatprofils

Beginnen Sie mit dem Zertifikatstyp, da dieser alles Weitere bestimmt.

• Gerätezertifikate eignen sich für gemeinsam genutzte Handhelds, Kioske und Laptops, die sich bereits am Windows-Anmeldebildschirm verbinden müssen. Verwenden Sie einen Betreffnamen, der aus der Gerätekennung zusammengesetzt ist, z. B. CN={{AAD_Device_ID}}.
• Personenbezogene Zertifikate eignen sich für Smartphones und Laptops, die einzelnen Mitarbeitenden zugewiesen sind. Verwenden Sie CN={{UserPrincipalName}} im Betreff. Fügen Sie denselben Wert als alternativen Anmeldernamen (Subject Alternative Name) hinzu, da viele RADIUS-Server die Identität dort auslesen.

Legen Sie anschließend die restlichen Felder fest:

• Schlüsselverwendung (Key usage): Digitale Signatur und Schlüsselverschlüsselung (Key Encipherment).
• Erweiterte Schlüsselverwendung (Extended key usage): Client-Authentifizierung, OID 1.3.6.1.5.5.7.3.2.
• Schlüssellänge: mindestens 2048 Bit.
• Gültigkeit: nicht länger, als Ihre CA-Vorlage zulässt.
• Schwellenwert für Erneuerung: Der Standardwert von Microsoft beträgt 20 % verbleibende Zertifikatslebensdauer.
• Stammzertifikat: Wählen Sie das vertrauenswürdige Zertifikatsprofil aus Schritt 1.
• Schlüsselspeicher unter Windows: Wählen Sie die TPM-Option für hardwaregestützte Schlüssel.

Geben Sie für SCEP die externe NDES-URL oder Ihre Cloud-PKI-SCEP-URI ein. Geben Sie für PKCS stattdessen den CA-Namen und den Vorlagen-Namen ein.

Wenn Sie Microsoft NPS (Network Policy Server) mit hybriden Identitäten verwenden, lesen Sie den Artikel KB5014754 von Microsoft zur starken Zertifikatzuordnung. Microsoft dokumentiert genau für diesen Fall eine Subject-Alternative-Name-URI, die den lokalen Sicherheitsbezeichner (SID) enthält.

Schritt 3: Bereitstellen des 802.1X WiFi-Profils

Erstellen Sie ein Enterprise-WiFi-Profil mit folgenden Einstellungen:

• Geben Sie die SSID genau so ein, wie Ihre Access Points sie ausstrahlen.
• Stellen Sie den Sicherheitstyp auf WPA2-Enterprise oder WPA3-Enterprise ein, sofern Ihre Access Points und die Plattform dies unterstützen.
• Stellen Sie den EAP-Typ auf EAP-TLS ein.
• Geben Sie Zertifikatsservernamen ein, die mit dem Namen auf Ihrem RADIUS-Serverzertifikat übereinstimmen. Dies verhindert, dass Geräte ihre Identität an einen gefälschten Access Point übergeben.
• Wählen Sie das Profil aus Schritt 1 als Stammzertifikat für die Servervalidierung aus.
• Wählen Sie das Profil aus Schritt 2 als Client-Authentifizierungszertifikat aus.

Welche Unterschiede gibt es unter Windows, iOS und Android?

• Windows verbindet sich vor der Benutzeranmeldung mit einem Gerätezertifikat. Ein personenbezogenes Zertifikat stellt die Verbindung erst nach der Anmeldung her, was die erste Anmeldung auf gemeinsam genutzten Laptops unterbricht.
• iOS und iPadOS vertrauen dem RADIUS-Server durch Abgleich der von Ihnen eingegebenen Zertifikatsservernamen. Eine Abweichung führt zu einem Vertrauensfehler und nicht zu einem stillschweigenden Fallback.
• Android Enterprise erfordert einen RADIUS-Server-Domänennamen und ein Stammzertifikat zur Validierung. Neuere Android-Versionen haben die Option zum Überspringen der Servervalidierung entfernt.

Was passiert, wenn ein neues Gerät registriert wird?

Dies ist der Ablauf der Zertifikatsbereitstellung auf einem neu registrierten Gerät:

1. Das Gerät wird registriert und landet in seiner zugewiesenen Entra ID-Gruppe.
2. Intune übermittelt die vertrauenswürdigen Stamm- und Zwischenprofil-Zertifikate.
3. Das Gerät fordert sein Client-Zertifikat an. Unter SCEP generiert es ein Schlüsselpaar und sendet eine Signierungsanfrage mit einer einmaligen Challenge. Der Connector überprüft diese Challenge mit Intune, bevor die CA etwas ausstellt. Unter PKCS fordert der Connector das Zertifikat an und Intune stellt es zu.
4. Das Gerät meldet das installierte Zertifikat an Intune.
5. Das WiFi-Profil, das von beiden Zertifikatsprofilen abhängt, wird angewendet.
6. Das Gerät präsentiert sein Zertifikat der SSID. RADIUS überprüft die Zertifikatskette, prüft auf Widerrufe und akzeptiert das Gerät. Anschließend kann über RADIUS-Attribute ein VLAN zugewiesen werden.
7. Intune erneuert das Zertifikat, wenn der Erneuerungsschwellenwert erreicht ist. Intune widerruft es, wenn Sie das Gerät außer Betrieb nehmen oder löschen, vorausgesetzt, der Connector verfügt über Widerrufsrechte auf der CA.

Wie überprüfen Sie, ob Intune WiFi-Zertifikate funktionieren?

Testen Sie mit einer Pilotgruppe von 10 bis 20 Geräten pro Plattform, bevor Sie die Zuweisungen ausweiten. Überprüfen Sie vier Stellen.

1. Intune-Profilstatus. Jedes der drei Profile sollte für jedes Pilotgerät den Status "Erfolgreich" melden. Der Status "Ausstehend", "Fehler" oder "Nicht zutreffend" bei einem der Profile blockiert das WiFi-Profil.
2. Das Gerät selbst. Öffnen Sie unter Windows den persönlichen Zertifikatsspeicher und bestätigen Sie den Zweck der Clientauthentifizierung sowie Ihre ausstellende CA. Bestätigen Sie unter iOS und Android, dass das Zertifikat und das WiFi-Profil in den Verwaltungsprofil- und Arbeitsprofil-Anmeldeinformationen angezeigt werden.
3. RADIUS-Protokolle. Suchen Sie nach erfolgreichen EAP-TLS-Authentifizierungen mit dem erwarteten Antragstellernamen. Auf NPS zeichnet die Ereignis-ID 6272 den gewährten Zugriff und 6273 den verweigerten Zugriff auf, jeweils mit einem Ursachencode.
4. Connector- und NDES-Protokolle. Der Certificate Connector schreibt in das Windows-Ereignisprotokoll. NDES-Anfragen erscheinen in den IIS-Protokollen.

Testen Sie den Widerruf anschließend gezielt. Nehmen Sie ein Pilotgerät in Intune außer Betrieb und bestätigen Sie, dass das Zertifikat auf der CA als widerrufen angezeigt wird. Veröffentlichen Sie die CRL und bestätigen Sie, dass RADIUS die nächste Authentifizierung verweigert.

Welche Probleme treten bei Intune WiFi-Profilen auf und wie beheben Sie diese?

Das WiFi-Profil zeigt "Fehler" oder "Nicht zutreffend"

Die Zertifikate sind angekommen, aber das WiFi-Profil ist fehlgeschlagen. Die häufigste Ursache ist eine gemischte Gruppenzuweisung. Beispielsweise ist das SCEP-Profil einer Personengruppe zugewiesen, während das WiFi-Profil auf eine Gerätegruppe abzielt. Intune kann die Abhängigkeit nicht auflösen. Die Lösung besteht darin, alle drei Profile derselben Gruppe oder zumindest demselben Gruppentyp zuzuweisen.

Das SCEP-Zertifikat kommt nie an

Die NDES IIS-Protokolle zeigen HTTP 403- oder 500-Antworten. Überprüfen Sie, ob das Connector-Dienstkonto über Lese- und Registrierungsberechtigungen für die Zertifikatvorlage verfügt. Überprüfen Sie, ob Ihre Firewall, Ihr Reverse Proxy oder Ihr Anwendungsproxy keine SCEP-Abfragezeichenfolgen wie operation=GetCACaps entfernt. Bestätigen Sie anschließend, dass die externe NDES-URL von außerhalb Ihres Netzwerks aufgelöst werden kann.

Das Gerät verfügt über ein Zertifikat, aber RADIUS lehnt es ab

Arbeiten Sie vier Ursachen der Reihe nach durch:

1. Die Zertifikatservernamen im WiFi-Profil stimmen nicht mit dem RADIUS-Serverzertifikat überein.
2. Der RADIUS-Server vertraut der CA nicht, die das Clientzertifikat ausgestellt hat.
3. Der RADIUS-Server kann keine aktuelle CRL herunterladen.
4. Die Durchsetzung der starken Zuordnung von NPS gemäß KB5014754 lehnt Zertifikate ohne starke Zuordnung ab.

Der NPS-Ursachencode weist auf die richtige Ursache hin.

Widerrufsprüfungen verursachen einen Ausfall

Wenn der CRL-Verteilungspunkt offline geht oder die CRL abläuft, lehnen strikte RADIUS-Server jedes Zertifikat ab. Veröffentlichen Sie CRLs an einem hochverfügbaren HTTP-Standort, den Ihr RADIUS-Server erreichen kann. Überwachen Sie den Zeitpunkt der nächsten Aktualisierung der CRL.

Geräte verbinden sich weiterhin mit dem alten Netzwerk

Ein altes Pre-Shared-Key- oder PEAP-Profil, das sich noch auf dem Gerät befindet, hat Vorrang. Entfernen Sie das alte Profil über Intune, sobald das neue eine erfolgreiche Verbindung meldet, und schalten Sie die alte SSID anschließend ad acta.

Wie funktioniert Intune-zertifikatsbasiertes WiFi in einer echten Umgebung?

Die zwei folgenden Szenarien sind Praxisbeispiele, die auf dem von Microsoft dokumentierten Verhalten aufbauen. Sie beschreiben Umgebungstypen, keine spezifischen Namentlich genannten Implementierungen.

Eine Hotelgruppe mit 12 Hotels ersetzt ein gemeinsam genutztes Personalpasswort

Situation. Eine Gruppe von 12 Hotels mit jeweils rund 200 Zimmern betreibt eine Personal-SSID über einen Pre-Shared Key. Der Schlüssel wird von 840 Geräten genutzt: Rezeptions-PCs, iPhones des Housekeepings und Android-Handhelds in der Gastronomie. Das Netzwerk ist mit der Karteninhaber-Datenumgebung verbunden. PCI DSS v4.0 Anforderung 2.3.2 verlangt daher, dass der Schlüssel geändert wird, sobald ein Mitarbeiter mit Kenntnis des Schlüssels das Unternehmen verlässt. Aufgrund der Fluktuation im Servicebereich führt jede Änderung dazu, dass Geräte blockiert sind, bis jemand den Schlüssel erneut eingibt.

Was getan wurde. Das Team implementiert SCEP über NDES, veröffentlicht über den Microsoft Entra ID Anwendungs-Proxy. Rezeptions-PCs erhalten Gerätezertifikate, sodass sie sich bereits am Anmeldebildschirm verbinden. Smartphones erhalten personenbezogene Zertifikate. Ein Pilotprojekt mit 20 Geräten läuft zwei Wochen lang in einem Hotel. Danach wechselt jede Woche ein weiteres Hotel, wobei die alte SSID parallel weiterläuft.

Messbares Ergebnis. Nach 12 Wochen authentifizieren sich alle 840 Geräte mit EAP-TLS, und die SSID mit dem Pre-Shared Key wird abgeschaltet. Die Anzahl der zu rotierenden gemeinsamen Schlüssel sinkt von einem über 12 Standorte auf null. Der Zugriff eines ausscheidenden Mitarbeiters endet nun, wenn dessen Gerät ausgemustert und die CRL neu veröffentlicht wird - nicht erst bei der nächsten Schlüsselrotation.

Eine Einzelhandelskette mit 150 Filialen und gemeinsam genutzten Handhelds

Situation. Jede Filiale nutzt vier gemeinsam verwendete Android-Handhelds und zwei Windows-Backoffice-Laptops, insgesamt 900 Geräte. Die Handhelds werden bei jedem Schichtwechsel zwischen den Mitarbeitern übergeben, weshalb personenbezogene Zertifikate keinen Sinn ergeben. Der Cloud-RADIUS-Dienst der Kette kann nicht auf eine CRL zugreifen, die nur im internen Netzwerk veröffentlicht ist.

Was getan wurde. Die Kette registriert die Handhelds als dedizierte Android Enterprise-Geräte und stellt Gerätezertifikate über SCEP aus. Ein WiFi-Profil pro Plattform versorgt jede Filiale, da die SSID überall identisch ist. Die CRL wird auf einen über das Internet erreichbaren HTTP-Verteilungspunkt verschoben.

Messbares Ergebnis. Kein gemeinsam genutztes Handheld enthält mehr ein WiFi-Passwort. Das Filialpersonal fragt nach Änderungen nicht mehr nach dem Schlüssel. Ein verlorenes Handheld wird durch Ausmusterung in Intune gesperrt, und sein Zertifikat schlägt bei der nächsten Authentifizierung nach der CRL-Aktualisierung fehl.

Was kostet die Bereitstellung von Intune WiFi-Zertifikaten und was ist der Nutzen?

Die Kosten

• Lizenzen. Die meisten Unternehmen besitzen Intune bereits über Microsoft 365 oder Enterprise Mobility + Security, sodass keine neuen Kosten pro Benutzer entstehen.
• Server. AD CS, NDES und NPS sind Windows Server-Rollen, für die außer Windows Server keine separate Lizenz erforderlich ist.
• Cloud-PKI. Microsoft Cloud PKI ist ein kostenpflichtiges Add-on, das auch in der Microsoft Intune Suite enthalten ist. Wägen Sie die Kosten gegen den Aufbau und die Wartung einer lokalen CA und NDES ab.
• Aufwand. Der Arbeitsaufwand liegt im PKI-Design, der NDES-Veröffentlichung und dem Pilotprojekt. Die drei Profile nehmen Stunden in Anspruch, keine Wochen.

Was Sie zurückbekommen

• Keine geteilten WiFi-Schlüssel. Dies macht die Schlüsselrotation überflüssig, die die PCI-DSS-Anforderung 2.3.2 für drahtlose Netzwerke vorschreibt, die mit der Karteninhaber-Datenumgebung verbunden sind.
• Widerrufbarer Zugriff bei Ausstritt von Mitarbeitern. Durch das Stillegen eines Geräts in Intune kann dessen Zertifikat widerrufen werden, sodass der WiFi-Zugriff Ihrem Joiners-, Movers- und Leavers-Prozess (JML) folgt.
• Kompatibilität mit Credential Guard. EAP-TLS funktioniert weiterhin, wenn Windows die passwortbasierte 802.1X-Single-Sign-On-Anmeldung blockiert.
• Keine Anmeldedaten, die gephisht werden können. Ein an ein TPM gebundenes Zertifikat kann nicht auf einer gefälschten Anmeldeseite eingegeben werden.
• Kein Ablauf von Passworten. Zertifikate werden automatisch vor ihrem Ablauf erneuert, wodurch Passwort-Zurücksetzungen als Ursache für WiFi-Tickets entfallen.

Planen Sie den GDPR-Umgang von Anfang an. Zertifikatsbetreffs, die den Anmeldenamen eines Mitarbeiters enthalten, sind personenbezogene Daten in Ihren RADIUS-Protokollen. Legen Sie eine Aufbewahrungsfrist fest und beschränken Sie den Zugriff auf diese Protokolle.

Purple betreibt Staff WiFi und Guest WiFi nebeneinander an über 80.000 Live-Standorten (Purple-Daten). Die Plattform ist hardwareunabhängig über Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks und Fortinet hinweg. Purple ist nach ISO 27001 zertifiziert. Unsere Identity-Based Networks funktionieren mit Microsoft Entra ID, Okta und Google Workspace, sodass der Zugriff der Mitarbeiter derselben Identitätsquelle folgt wie Ihre Intune-Umgebung. Auf der Besucherseite berichtet WiFi Analytics über Gastverbindungen getrennt vom Mitarbeiter-Datenverkehr.

Häufig gestellte Fragen

Benötigen Sie zusätzliche Lizenzen, um WiFi-Zertifikate über Intune bereitzustellen?

Nein, nicht für SCEP über NDES oder für PKCS. Intune ist in Microsoft 365 E3, E5 und Business Premium sowie in Enterprise Mobility + Security E3 und E5 enthalten. Active Directory-Zertifikatdienste und NDES sind Windows Server-Rollen, sodass Sie nur Ihre bestehende Windows Server-Lizenzierung benötigen. Die Ausnahme ist Microsoft Cloud PKI, ein kostenpflichtiges Add-on, das auch in der Microsoft Intune Suite enthalten ist. Planen Sie ein Budget dafür nur ein, wenn Sie den Betrieb einer lokalen CA vermeiden möchten.

Funktioniert zertifikatbasiertes WiFi von Intune mit Ihren vorhandenen Access Points?

Ja, vorausgesetzt, Ihre Access Points können eine WPA2-Enterprise- oder WPA3-Enterprise-SSID ausstrahlen. EAP-TLS läuft zwischen dem Gerät und dem RADIUS-Server, und der Access Point leitet dies nur unter IEEE 802.1X weiter. Purple ist hardwareunabhängig und läuft auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks und Fortinet. Sie behalten die Hardware, die Sie bereits besitzen, und ändern nur die SSID-Sicherheitseinstellungen.

Können Sie ohne Ausfallzeiten von PEAP oder einem geteilten Passwort zu EAP-TLS wechseln?

Ja. Betreiben Sie die neue 802.1X SSID parallel zur alten, oder konfigurieren Sie Ihren RADIUS-Server so, dass er während der Übergangsphase sowohl PEAP als auch EAP-TLS akzeptiert. Weisen Sie die drei Intune-Profile zuerst einer Pilotgruppe zu. Bestätigen Sie erfolgreiche EAP-TLS-Authentifizierungen in Ihren RADIUS-Protokollen und weiten Sie die Zuweisung anschließend schrittweise aus. Entfernen Sie das veraltete WiFi-Profil erst, wenn das neue als erfolgreich gemeldet wird, und legen Sie erst dann die alte SSID still.

Sollten Sie SCEP oder PKCS für das Mitarbeiter-WiFi wählen?

Wählen Sie SCEP. Bei SCEP generiert das Gerät seinen eigenen privaten Schlüssel, der das Gerät nie verlässt, und Windows kann diesen Schlüssel im TPM speichern. PKCS erstellt den Schlüssel außerhalb des Geräts und liefert ihn aus. Das macht den NDES-Server überflüssig, erweitert jedoch die Orte, an denen der Schlüssel existiert hat. Wählen Sie PKCS nur, wenn Sie Active Directory-Zertifikatdienste ausführen und NDES nicht veröffentlichen können, oder nutzen Sie Microsoft Cloud-PKI für SCEP ohne NDES.

Benötigen Sie weiterhin einen NDES-Server?

Nur für SCEP mit einer lokalen Active Directory-Zertifikatdienste-Zertifizierungsstelle (CA). Microsoft Cloud-PKI bietet einen gehosteten SCEP-Endpunkt, sodass Sie keinen NDES-Server, Connector oder eine lokale CA betreiben müssen. PKCS-Profile vermeiden NDES ebenfalls, da der Certificate Connector für Microsoft Intune Zertifikate von Ihrer CA über ausgehende Verbindungen anfordert. Von Intune unterstützte Zertifizierungsstellen von Drittanbietern können SCEP-Zertifikate ebenfalls ohne NDES ausstellen.

Wie schnell endet der WiFi-Zugriff, wenn jemand das Unternehmen verlässt?

So schnell, wie es Ihre Sperr-Pipeline zulässt. Wenn Sie ein Gerät in Intune stilllegen oder löschen, kann der Certificate Connector dessen Zertifikat auf Ihrer CA sperren. Der Zugriff endet, sobald Ihr RADIUS-Server diese Sperrung über eine aktualisierte CRL oder eine OCSP-Prüfung erkennt. Verkürzen Sie das CRL-Veröffentlichungsintervall oder nutzen Sie OCSP, wenn eine Entfernung innerhalb derselben Stunde wichtig ist. Das alleinige Deaktivieren des Kontos stoppt ein gültiges Zertifikat möglicherweise nicht, es sei denn, RADIUS prüft auch das Verzeichnis.

Hilft zertifikatsbasiertes WiFi bei PCI-DSS und GDPR?

Ja. Die PCI-DSS v4.0-Anforderung 2.3.2 verlangt, dass WLAN-Schlüssel in Netzwerken, die mit der Karteninhaber-Datenumgebung verbunden sind, geändert werden, sobald jemand das Unternehmen verlässt, der sie kennt. Zertifikate pro Gerät bedeuten, dass kein gemeinsamer Schlüssel existiert, der erneuert werden müsste. Betrachten Sie für die GDPR Zertifikatsbetreffs, die den Anmeldenamen eines Mitarbeiters enthalten, als personenbezogene Daten. Legen Sie eine Aufbewahrungsfrist für RADIUS-Protokolle fest, beschränken Sie den Zugriff darauf und dokumentieren Sie die Verarbeitung.