Verwendung von Microsoft Intune zur Bereitstellung von WiFi-Zertifikaten auf Geräten

WIE SIE MICROSOFT INTUNE NUTZEN, UM WIFI ZERTIFIKATE AUF GERÄTE ZU ÜBERTRAGEN 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, und diese Episode ist ein gezieltes Briefing zu einer der praktischsten - und ehrlich gesagt am meisten unterschätzten - Funktionen im Microsoft Intune Toolkit: der automatisierten 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 sich diese 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 per E-Mail gesendet wurde. Genau das löst die Zertifikatsbereitstellung über Intune. In den nächsten neun Minuten werde ich Ihnen erklären, wie das funktioniert, wie man es bereitstellt und welche Fallstricke die meisten Teams beim ersten Versuch stolpern lassen. [TECHNISCHER DEEP-DIVE — ca. 5 Minuten] Beginnen wir mit der Architektur. Das Fundament hierbei ist IEEE 802.1X - der portbasierte Netzwerkzugriffskontrollstandard, der seit über zwei Jahrzehnten das Rückgrat der Enterprise WiFi Sicherheit 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 Supplicant), Ihrem WiFi Access Point (dem Authenticator) und Ihrem RADIUS Server, der als Authentifizierungsserver die endgültige Entscheidung trifft. 802.1X unterstützt mehrere 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 im Spiel. Keine Anmeldedaten, die per Phishing gestohlen werden können. Das ist unser Ziel. Die Herausforderung bestand schon immer darin, diese Zertifikate in großem Umfang auf die Geräte zu übertragen. Hier kommt Microsoft Intune ins Spiel. Intune unterstützt zwei Mechanismen zur Zertifikatsbereitstellung: SCEP (Simple Certificate Enrolment Protocol) und PKCS (Public Key Cryptography Standards). Es ist wichtig, den Unterschied zu verstehen. Bei SCEP wird der private Schlüssel direkt auf dem Gerät selbst generiert. Das Gerät erstellt eine Zertifikatsignierungsanforderung, sendet sie über einen Zwischenserver namens NDES (Network Device Enrolment Service) an Ihre Zertifizierungsstelle (CA) und die CA stellt das Zertifikat wieder aus. Der private Schlüssel verlässt das Gerät nie. Dies ist der sicherere Ansatz und wird für BYOD-Umgebungen und Hochsicherheits-Deployments empfohlen. Bei PKCS generiert die Zertifizierungsstelle das Schlüsselpaar, und der Intune Certificate Connector stellt den privaten Schlüssel und das Zertifikat auf dem Gerät bereit. Die Einrichtung ist einfacher - es ist kein NDES-Server erforderlich - aber der private Schlüssel wird über den Connector übertragen, was bei der Bewertung Ihrer Sicherheitslage berücksichtigt werden sollte. Für die meisten Enterprise-Bereitstellungen empfehle ich SCEP für BYOD- und gemischte Geräteumgebungen sowie PKCS, wenn Sie eine homogene Flotte von unternehmenseigenen Windows Geräten haben und die Komplexität der Infrastruktur minimieren möchten. Lassen Sie uns nun über die Bereitstellungsreihenfolge sprechen - denn die Reihenfolge ist entscheidend, und Fehler an dieser Stelle sind die häufigste Ursache für fehlgeschlagene Rollouts. Schritt eins: Konfigurieren Sie Ihre Zertifizierungsstelle. Sie benötigen eine Zertifikatvorlage auf Ihrer Active Directory-Zertifikatdienstinstanz - oder wenn Sie vollständig Cloud-native sind, ist die Intune Cloud PKI von Microsoft jetzt allgemein verfügbar und macht die lokale CA-Anforderung völlig überflüssig. Die Vorlage benötigt die korrekten Schlüsselerweiterungen für die Schlüsselverwendung: Client-Authentifizierung ist obligatorisch. Stellen Sie die minimale Schlüsselgröße auf 2048 Bit ein, oder auf 4096, wenn die Sicherheitsrichtlinie Ihrer Organisation dies erfordert. Schritt zwei: Stellen Sie das vertrauenswürdige Stammzertifikat 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 Stamm-CA-Zertifikat hoch und weisen es Ihren Gerätegruppen zu. Dies muss auf den Geräten ankommen, bevor ein WiFi Profil oder ein Client-Zertifikatprofil angewendet wird. 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 die URL Ihres NDES-Servers verweist - oder Ihr PKCS-Profil, das auf Ihre Zertifizierungsstelle verweist. Der alternative Antragstellername (Subject Alternative Name) sollte den User Principal Name für Benutzerzertifikate oder die AAD-Geräte-ID für Gerätezertifikate enthalten. Dieser Unterschied 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 Domänenbeitrittsszenarien 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 Vertrauenseinstellungen für den Server - hier verweisen Sie auf den Zertifikatsnamen des RADIUS-Servers - 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 die Bereitstellung. Weisen Sie Ihr Stammzertifikat, Ihr Client-Zertifikat und Ihre WiFi Profile denselben Geräte- oder Benutzergruppen zu. Nutzen Sie die integrierte Berichterstattung 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 Geräte verwenden, die in Azure AD eingebunden sind und sich gegenüber einem lokalen NPS authentifizieren, müssen Sie sicherstellen, dass das Attribut altSecurityIdentities im 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 Zertifizierungsstelle ein neues Zertifikat ausstellt. [IMPLEMENTIERUNGSEMPFEHLUNGEN & FALLSTRICKE - ca. 2 Minuten] Lassen Sie mich Ihnen die drei Fallstricke nennen, die ich in Enterprise-Bereitstellungen am häufigsten sehe. Fallstrick eins: Lücken in der Zertifikatskette. Das Gerät muss jedem Zertifikat in der Kette vertrauen, von der Root-Zertifizierungsstelle bis zum Zertifikat des RADIUS-Servers. Wenn Ihr RADIUS-Serverzertifikat von einer Zwischenzertifizierungsstelle ausgestellt wurde, müssen Sie sowohl das Root- als auch das Zwischenzertifikat auf den Geräten bereitstellen. Ich habe erlebt, dass Bereitstellungen wochenlang fehlgeschlagen sind, weil jemand das Root-Zertifikat, aber nicht das Zwischenzertifikat bereitgestellt hat. Fallstrick zwei: Zeitpunkt der Profilzuweisung. Intune-Profile landen nicht augenblicklich auf den Geräten. In einer großen Infrastruktur kann es nach der Zuweisung 15 bis 30 Minuten dauern, bis die Profile verteilt sind. Testen Sie nicht sofort nach dem Erstellen von Profilen. Verwenden Sie die Sync-Schaltfläche 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. Fallstrick drei: Sperrung von BYOD-Zertifikaten. Wenn die Registrierung eines Geräts in Intune aufgehoben wird - weil ein Mitarbeiter das Unternehmen verlässt oder ein Gerät verloren geht - benötigen Sie einen Prozess zur Sperrung 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 das OCSP überprüft. Dies ist eine Compliance-Anforderung im Rahmen von Frameworks wie PCI-DSS, die vorschreibt, dass Mechanismen zur Zugriffskontrolle unverzüglich widerrufen werden müssen, wenn sie nicht mehr benötigt werden. Zum Thema Compliance: Wenn Sie in einem PCI-DSS-Geltungsbereich tätig sind - beispielsweise in Zahlungsumgebungen im Einzelhandel - ist die zertifikatsbasierte 802.1X-Authentifizierung Ihre stärkste Kontrolle für den drahtlosen Netzwerkzugriff. Sie erfüllt die PCI-DSS-Anforderung 1.3 in Bezug auf Netzwerksicherheitskontrollen und die Anforderung 8.6 in Bezug auf 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 Corporate 802.1X-Netzwerk und Ihrem Guest 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 Guest- oder Besucher-Netzwerk. Die Guest WiFi-Plattform von Purple übernimmt die dem Besucher zugewandte Seite - Captive Portal, Erfassung von Einwilligungen, Analysen - während Ihr über Intune verwaltetes Unternehmensnetzwerk die Mitarbeiter- und Betriebsgeräte bedient. Diese beiden Netzwerke sollten niemals dieselbe Authentifizierungsinfrastruktur nutzen. [SCHNELLE FRAGEN & ANTWORTEN - ca. 1 Minute] Lassen Sie mich kurz ein paar Fragen durchgehen, die regelmäßig auftauchen. Kann ich Intune Cloud PKI anstelle von lokalem ADCS verwenden? Ja. Die im Jahr 2024 veröffentlichte Intune Cloud PKI von Microsoft bietet eine vollständig verwaltete CA in Azure. Sie macht den NDES-Server für SCEP überflüssig und vereinfacht die Connector-Einrichtung erheblich. Für Neuinstallationen oder Unternehmen 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 - vertrauenswürdiger Root, Client-Zertifikat, WiFi-Profil - ist konsistent. Wie sieht es mit privaten Geräten in einem BYOD-Programm aus? SCEP ist hier Ihr bester Partner. Mit den Geräte-Compliance-Richtlinien von Intune können Sie festlegen, dass ein Gerät die Mindestsicherheitsstandards erfüllen muss, bevor ein Zertifikat ausgestellt wird. Wenn das Gerät die Compliance-Vorgaben nicht mehr erfüllt - keine Bildschirmsperre, veraltetes OS - kann das Zertifikat widerrufen und der Netzwerkzugriff automatisch gesperrt werden. Kann Purple in diese Architektur integriert werden? Absolut. Die Plattform von Purple befindet sich auf der Seite des Guest-Netzwerks und übernimmt die Authentifizierung über das Captive Portal, das Einwilligungsmanagement und die Analysen. Das Corporate 802.1X-Netzwerk und das Guest WiFi von Purple laufen parallel - gleiche physische Infrastruktur, unterschiedliche SSIDs und VLANs - was Ihnen eine vollständige Trennung zwischen der Konnektivität für 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 Prozess in fünf Schritten - CA-Konfiguration, Bereitstellung des vertrauenswürdigen Roots, Client-Zertifikatsprofil, WiFi-Profil und Gruppenzuweisung. Wählen Sie SCEP für BYOD und hochsichere Umgebungen; PKCS für einfachere, unternehmenseigene Gerätebestände. Achten Sie auf die richtige Reihenfolge, bewältigen Sie die Anforderungen an die NPS-Zertifikatszuordnung und richten Sie von Tag eins an einen Workflow für den Zertifikatswiderruf ein. Der geschäftliche Nutzen liegt auf der Hand: Sie eliminieren gemeinsam genutzte WiFi-Passwörter, erhalten Authentifizierungsprotokolle pro Gerät und Benutzer, erfüllen die drahtlosen Sicherheitsanforderungen von PCI-DSS und ISO 27001 und reduzieren den IT-Overhead für die Verwaltung von WiFi-Anmeldedaten in einem großen Unternehmen.Wenn Sie eine Bereitstellung planen und verstehen möchten, wie sich die Gast-WiFi- und Analyseplattform von Purple in Ihre Unternehmensnetzwerkarchitektur einfügt, besuchen Sie purple.ai. Wir bieten detaillierte Leitfäden zur Integration von Azure Entra ID, 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.