How to Use Microsoft Intune to Push WiFi Certificates to Devices

WIE SIE MICROSOFT INTUNE NUTZEN, UM WIFI-ZERTIFIKATE AUF GERÄTE ZU PUSHEN Ein Purple Enterprise WiFi Intelligence Briefing [EINFÜHRUNG & KONTEXT — ca. 1 Minute] Willkommen zurück. Ich spreche heute im Namen von Purple, der Enterprise WiFi Intelligence-Plattform. Diese Episode ist ein gezieltes Briefing über eine der praktischsten — und ehrlich gesagt am meisten unterschätzten — Funktionen im Microsoft Intune-Toolkit: die automatisierte Zertifikatsbereitstellung für die 802.1X-WiFi-Authentifizierung. Wenn Sie das WiFi in einer Hotelkette, einer Einzelhandelskette, einem Stadion oder einer öffentlichen Einrichtung verwalten, kennen Sie das Problem, das ich gleich beschreiben werde. Sie haben Hunderte oder Tausende von verwalteten Geräten. Sie möchten, dass diese sich automatisch und sicher mit Ihrem Unternehmens-WiFi verbinden, ohne dass Benutzer Passwörter eingeben müssen und ohne dass die IT jedes einzelne Gerät anfassen muss. Und Sie möchten, dass diese Verbindung kryptografisch stark ist — nicht nur ein gemeinsam genutztes Passwort, das bereits an die halbe Organisation gemailt wurde. Genau dieses Problem löst die Intune-Zertifikatsbereitstellung. In den nächsten neun Minuten werde ich Ihnen erklären, wie es funktioniert, wie man es bereitstellt und welche Fallstricke die meisten Teams beim ersten Versuch übersehen. [TECHNISCHER DEEP-DIVE — ca. 5 Minuten] Beginnen wir mit der Architektur. Die Grundlage hierfür ist IEEE 802.1X — der portbasierte Netzwerkzugriffskontrollstandard, der seit über zwei Jahrzehnten das Rückgrat der WiFi-Sicherheit in Unternehmen bildet. Wenn sich ein Gerät mit Ihrem WiFi verbindet, verlangt 802.1X eine Authentifizierung, bevor es Netzwerkzugriff erhält. Der Authentifizierungsprozess findet zwischen drei Parteien statt: dem Gerät — dem sogenannten Supplicant —, Ihrem WiFi-Access-Point, der als Authentifikator fungiert, und Ihrem RADIUS-Server, dem Authentifizierungsserver, der die endgültige Entscheidung trifft. 802.1X unterstützt verschiedene Authentifizierungsmethoden. Die sicherste ist EAP-TLS — Extensible Authentication Protocol mit Transport Layer Security. EAP-TLS nutzt eine gegenseitige Zertifikatsauthentifizierung: Das Gerät legt ein Zertifikat vor, um seine Identität nachzuweisen, und der RADIUS-Server legt ein Zertifikat vor, um seine Identität nachzuweisen. Keine Passwörter. Keine Anmeldedaten, die per Phishing gestohlen werden können. Das ist unser Ziel. Die Herausforderung bestand schon immer darin, diese Zertifikate in großem Maßstab auf die Geräte zu bringen. Genau hier kommt Microsoft Intune ins Spiel. Intune unterstützt zwei Mechanismen zur Zertifikatsbereitstellung: SCEP — Simple Certificate Enrollment Protocol — und PKCS, was für Public Key Cryptography Standards steht. Den Unterschied zu verstehen, ist wichtig. Bei SCEP wird der private Schlüssel auf dem Gerät selbst generiert. Das Gerät erstellt eine Zertifikatsignierungsanforderung (Certificate Signing Request), sendet sie über einen Zwischenserver namens NDES — Network Device Enrollment Service — an Ihre Zertifizierungsstelle (CA), und die CA stellt das Zertifikat aus. Der private Schlüssel verlässt das Gerät nie. Dies ist der sicherere Ansatz und wird für BYOD-Umgebungen und Hochsicherheitsbereitstellungen empfohlen. Bei PKCS generiert die Certificate Authority das Schlüsselpaar, und der Intune Certificate Connector stellt den privaten Schlüssel und das Zertifikat für das Gerät bereit. Die Einrichtung ist einfacher – es ist kein NDES-Server erforderlich –, aber der private Schlüssel wird über den Connector übertragen, was für Ihre Sicherheitslage eine Rolle spielt. Für die meisten Enterprise-Bereitstellungen empfehle ich SCEP für BYOD- und gemischte Geräteumgebungen und PKCS, wenn Sie über eine homogene Flotte unternehmenseigener Windows-Geräte verfügen und die Komplexität der Infrastruktur minimieren möchten. Sprechen wir nun über die Bereitstellungsreihenfolge – denn die Reihenfolge ist wichtig, und Fehler hierbei sind die häufigste Ursache für fehlgeschlagene Rollouts. Schritt eins: Konfigurieren Sie Ihre Certificate Authority. Sie benötigen eine Zertifikatvorlage auf Ihrer Active Directory Certificate Services-Instanz – oder wenn Sie vollständig Cloud-native sind, ist Microsofts Intune Cloud PKI jetzt allgemein verfügbar und macht die On-Premises-CA-Anforderung überflüssig. Die Vorlage benötigt die korrekten Schlüsselverwendungserweiterungen: Client-Authentifizierung ist obligatorisch. Stellen Sie die minimale Schlüsselgröße auf 2048 Bit ein, oder auf 4096, wenn die Sicherheitsrichtlinie Ihres Unternehmens dies erfordert. Schritt zwei: Stellen Sie das vertrauenswürdige Root-Zertifikat bereit. Bevor ein Gerät das Zertifikat des RADIUS-Servers validieren kann, muss es der CA vertrauen, die es ausgestellt hat. Sie erstellen ein Konfigurationsprofil für vertrauenswürdige Zertifikate in Intune, laden das Root-CA-Zertifikat hoch und weisen es Ihren Gerätegruppen zu. Dies muss vor jedem WiFi-Profil oder Client-Zertifikatprofil auf den Geräten landen. Wenn Sie die Reihenfolge falsch wählen, lehnen die Geräte den RADIUS-Server ab, und Sie verbringen den Nachmittag damit, auf die Event-ID 20271 im Windows-Ereignisprotokoll zu starren. Schritt drei: Stellen Sie das Client-Zertifikatprofil bereit. Dies ist entweder Ihr SCEP-Profil – das auf Ihre NDES-Server-URL verweist – oder Ihr PKCS-Profil, das auf Ihre Certificate Authority verweist. Der Subject Alternative Name sollte den User Principal Name für Benutzerzertifikate oder die AAD-Geräte-ID für Gerätezertifikate enthalten. Diese Unterscheidung ist wichtig: Benutzerzertifikate authentifizieren den angemeldeten Benutzer, Gerätezertifikate authentifizieren das Gerät selbst, was bedeutet, dass sich das Gerät mit dem WiFi verbinden kann, bevor sich ein Benutzer anmeldet – nützlich für Domain-Join-Szenarien und Kiosk-Bereitstellungen. Schritt vier: Erstellen Sie das WiFi-Konfigurationsprofil. In Intune finden Sie dies unter Geräte, Konfigurationsprofile, Vorlagen, Wi-Fi. Stellen Sie den WiFi-Typ auf Enterprise ein, geben Sie Ihre SSID ein, stellen Sie den EAP-Typ auf EAP-TLS ein, konfigurieren Sie die Server-Vertrauenseinstellungen – hier verweisen Sie auf den Namen des RADIUS-Serverzertifikats – und verweisen Sie für die Client-Authentifizierung auf das in Schritt drei erstellte Zertifikatprofil. Schritt fünf: Weisen Sie alles den richtigen Gruppen zu und validieren Sie es. Weisen Sie Ihr Root-Zertifikat, Ihr Client-Zertifikat und Ihre WiFi-Profile denselben Geräte- oder Benutzergruppen zu. Verwenden Sie die integrierten Berichte von Intune, um den Status der Profilbereitstellung zu überwachen. Eine erfolgreiche Bereitstellung zeigt alle drei Profile in der Konfigurationsprofilliste des Geräts als „Erfolgreich“ an. Ein kritischer Punkt bei der NPS-Konfiguration für Windows Server-Umgebungen: Seit Anfang 2024 hat Microsoft die Anforderungen an das Zertifikatsmapping verschärft. Wenn Sie Gerätezertifikate für in Azure AD eingebundene Geräte verwenden, die sich gegenüber einem lokalen NPS authentifizieren, müssen Sie sicherstellen, dass das Attribut „altSecurityIdentities“ auf dem Computerobjekt in Active Directory mit dem Fingerabdruck des Zertifikats ausgefüllt ist. Dies geschieht nicht automatisch – Sie benötigen ein Skript oder einen Workflow, um dies zu handhaben, was normalerweise ausgelöst wird, wenn die CA ein neues Zertifikat ausstellt. [IMPLEMENTIERUNGSEMPFEHLUNGEN & STOLPERSTEINE — ca. 2 Minuten] Lassen Sie mich Ihnen die drei Stolpersteine nennen, die mir bei Unternehmensbereitstellungen am häufigsten begegnen. Stolperstein eins: Lücken in der Zertifikatskette. Das Gerät muss jedem Zertifikat in der Kette von der Root-CA bis zum Zertifikat des RADIUS-Servers vertrauen. Wenn das Zertifikat Ihres RADIUS-Servers von einer Zwischen-CA ausgestellt wurde, müssen Sie sowohl das Root- als auch das Zwischenzertifikat auf den Geräten bereitstellen. Ich habe erlebt, dass Bereitstellungen wochenlang fehlschlugen, weil jemand zwar das Root-, aber nicht das Zwischenzertifikat bereitgestellt hatte. Stolperstein zwei: Timing bei der Profilzuweisung. Intune-Profile landen nicht sofort auf den Geräten. In einer großen Umgebung kann es nach der Zuweisung 15 bis 30 Minuten dauern, bis Profile verteilt sind. Testen Sie nicht sofort nach dem Erstellen von Profilen. Verwenden Sie die Schaltfläche „Synchronisieren“ im Intune-Portal, um einen Check-in zu erzwingen, und warten Sie dann. Zudem müssen Client-Zertifikatsprofile bereitgestellt und bestätigt sein, bevor das WiFi-Profil angewendet wird – wenn das WiFi-Profil auf ein Zertifikat verweist, das noch nicht existiert, schlägt das Profil auf einigen Plattformen geräuschlos fehl. Stolperstein drei: Zertifikatswiderruf bei BYOD. Wenn ein Gerät aus Intune abgemeldet wird – weil ein Mitarbeiter das Unternehmen verlässt oder ein Gerät verloren geht –, benötigen Sie einen Prozess zum Widerrufen des Zertifikats. Wenn Sie SCEP mit ADCS verwenden, konfigurieren Sie den Verteilungspunkt für die Zertifikatssperrliste (CRL) korrekt und stellen Sie sicher, dass Ihr RADIUS-Server bei jeder Authentifizierung die CRL oder OCSP überprüft. Dies ist eine Compliance-Anforderung unter Frameworks wie PCI DSS, die vorschreiben, dass Zugriffskontrollmechanismen unverzüglich widerrufen werden müssen, wenn sie nicht mehr benötigt werden. Zum Thema Compliance: Wenn Sie in einem PCI DSS-Bereich arbeiten – beispielsweise in Einzelhandels-Zahlungsumgebungen –, ist die zertifikatsbasierte 802.1X-Authentifizierung Ihre stärkste Kontrolle für den drahtlosen Netzwerkzugriff. Sie erfüllt die PCI DSS-Anforderung 1.3 bezüglich Netzwerkzugriffskontrollen und die Anforderung 8.6 bezüglich Authentifizierungsfaktoren. Dokumentieren Sie Ihren Prozess zur Verwaltung des Zertifikatslebenszyklus als Teil Ihrer Compliance-Nachweise. Für GDPR-regulierte Umgebungen, insbesondere im Gastgewerbe und im öffentlichen Sektor, ist die Trennung zwischen Ihrem internen 802.1X-Netzwerk und Ihrem Gäste-WiFi-Netzwerk von entscheidender Bedeutung. Ihr über Intune verwaltetes Unternehmensnetzwerk sollte sich auf einem völlig separaten VLAN und einer anderen SSID befinden als jedes Gäste- oder Besuchernetzwerk. Die Gäste-WiFi-Plattform von Purple übernimmt die dem Besucher zugewandte Seite – Captive Portal, Einwilligungserfassung, Analysen –, während Ihr über Intune verwaltetes Unternehmensnetzwerk die Mitarbeiter- und Betriebsgeräte abdeckt. Diese beiden Netzwerke sollten niemals dieselbe Authentifizierungsinfrastruktur nutzen. [SCHNELLES Q&A — ca. 1 Minute] Lassen Sie uns kurz einige Fragen durchgehen, die regelmäßig gestellt werden. Kann ich Intune Cloud PKI anstelle von On-Premises ADCS verwenden? Ja. Microsofts Intune Cloud PKI, das 2024 veröffentlicht wurde, bietet eine vollständig verwaltete CA in Azure. Es macht den NDES-Server für SCEP überflüssig und vereinfacht die Connector-Einrichtung erheblich. Für Neuinstallationen oder Organisationen ohne bestehende ADCS-Infrastruktur ist dies der empfohlene Weg. Funktioniert das auch für macOS- und iOS-Geräte? Ja. Intune unterstützt Zertifikatsprofile für Windows, iOS, iPadOS, Android und macOS. Die Profiltypen und Konfigurationsoptionen variieren je nach Plattform leicht, aber die Kernarchitektur – Trusted Root, Client-Zertifikat, WiFi-Profil – bleibt konsistent. Wie sieht es mit persönlichen Geräten in einem BYOD-Programm aus? SCEP ist hier Ihr bester Freund. Mit den Gerätekompatibilitätsrichtlinien von Intune können Sie festlegen, dass ein Gerät Mindestsicherheitsstandards erfüllen muss, bevor ein Zertifikat ausgestellt wird. Wenn das Gerät die Kompatibilität verliert – keine Bildschirmsperre, veraltetes Betriebssystem –, kann das Zertifikat widerrufen und der Netzwerkzugriff automatisch entzogen werden. Kann Purple in diese Architektur integriert werden? Absolut. Die Plattform von Purple befindet sich auf der Seite des Gästenetzwerks und übernimmt die Captive Portal-Authentifizierung, das Einwilligungsmanagement und die Analysen. Das 802.1X-Unternehmensnetzwerk und das Gäste-WiFi von Purple laufen parallel – gleiche physische Infrastruktur, unterschiedliche SSIDs und VLANs –, was Ihnen eine vollständige Trennung zwischen der Konnektivität der Mitarbeiter und der Interaktion mit Besuchern ermöglicht. [ZUSAMMENFASSUNG & NÄCHSTE SCHRITTE — ca. 1 Minute] Zusammenfassend lässt sich sagen: Die Bereitstellung von WiFi-Zertifikaten über Intune ist ein fünfstufiger Prozess – CA-Konfiguration, Bereitstellung des Trusted Root, Client-Zertifikatsprofil, WiFi-Profil und Gruppenzuweisung. Wählen Sie SCEP für BYOD und hochsichere Umgebungen; PKCS für einfachere, unternehmenseigene Geräteflotten. Achten Sie auf die richtige Reihenfolge, berücksichtigen Sie die NPS-Zertifikatszuordnung und richten Sie vom ersten Tag an einen Workflow für den Zertifikatswiderruf ein. Der Business Case ist überzeugend: Sie eliminieren gemeinsam genutzte WiFi-Passwörter, erhalten Authentifizierungsprotokolle pro Gerät und Benutzer, erfüllen die Anforderungen an die drahtlose Sicherheit nach PCI DSS und ISO 27001 und reduzieren den IT-Aufwand für die Verwaltung von WiFi-Zugangsdaten in einer großen Infrastruktur. Wenn Sie ein Deployment planen und verstehen möchten, wie sich die Guest-WiFi- und Analytics-Plattform von Purple in Ihre Unternehmens-Netzwerkarchitektur einfügt, besuchen Sie purple.ai. Wir bieten detaillierte Leitfäden zur Azure Entra ID-Integration, zur 802.1X-Architektur und zum Design von Gastnetzwerken für das Gastgewerbe, den Einzelhandel und den öffentlichen Sektor. Vielen Dank fürs Zuhören. Bis zum nächsten Mal.