Azure AD und Entra ID WiFi-Authentifizierung: Integrations- und Konfigurationshandbuch

Executive Summary

Für moderne Unternehmen, die stark in das Microsoft-Ökosystem investiert haben, ist die Verknüpfung der Cloud-Identitätsinfrastruktur mit physischen drahtlosen Netzwerken ein kritisches Sicherheitsgebot. In der Vergangenheit basierte die WiFi-Authentifizierung auf lokalen Active Directory Domain Services (AD DS) und dem Windows Network Policy Server (NPS). Da Unternehmen jedoch zu Microsoft Entra ID (ehemals Azure AD) migrieren und Zero-Trust-Sicherheitsmodelle einführen, ist der traditionelle, auf Anmeldedaten basierende Authentifizierungsansatz — PEAP-MSCHAPv2 — nicht mehr ausreichend oder sicher.

Dieser Leitfaden bietet IT-Managern, Netzwerkarchitekten und Leitern des Standortbetriebs einen praktischen Fahrplan für die Implementierung der Azure AD WiFi-Authentifizierung. Wir untersuchen die architektonischen Unterschiede zwischen der Beibehaltung einer lokalen NPS-Infrastruktur und der Migration zu einer Cloud-nativen RADIUS-Lösung. Vor allem zeigen wir im Detail, wie Sie Microsoft Intune für die zertifikatsbasierte Authentifizierung (EAP-TLS) nutzen können, was passwortbezogene Sicherheitslücken eliminiert und eine nahtlose, reibungslose Benutzererfahrung bietet. Unabhängig davon, ob Sie ein Hotel mit 500 Zimmern, eine Einzelhandelskette oder eine große Bereitstellung im öffentlichen Sektor verwalten, hilft Ihnen dieser Leitfaden, Ihre drahtlose Netzwerkperipherie mit Ihren vorhandenen Microsoft-Identitätsinvestitionen zu sichern. Für eine umfassendere Diskussion der Bereitstellungsmodelle lesen Sie unseren Cloud RADIUS vs On-Premise RADIUS: Decision Guide for IT Teams .

Technischer Deep-Dive: Architektur und Standards

Das Fundament für sicheres Enterprise-WiFi ist der Standard IEEE 802.1X, der eine portbasierte Netzwerkzugriffskontrolle bietet. In einer Microsoft-zentrierten Umgebung erfordert die Integration von 802.1X mit Entra ID eine sorgfältige Architekturplanung über drei Ebenen hinweg: die drahtlose Infrastruktur, den Authentifizierungsserver und das Identitätsverzeichnis.

Die Rolle von RADIUS und 802.1X

Wenn ein Client-Gerät (der Supplicant) versucht, sich mit einem WPA2/WPA3-Enterprise-Netzwerk zu verbinden, blockiert der Wireless Access Point (der Authenticator) den gesamten Datenverkehr mit Ausnahme von EAP-Paketen (Extensible Authentication Protocol). Der Access Point leitet diese Pakete an einen RADIUS-Server weiter. Der RADIUS-Server validiert die Identität des Benutzers oder Geräts mit einem Verzeichnisdienst und gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Dieses Dreiparteienmodell — Supplicant, Authenticator, Authentifizierungsserver — ist der Eckpfeiler der drahtlosen Sicherheit in Unternehmen und wird ausführlich in unserem Wireless Access Points Definition: Your Ultimate 2026 Guide beschrieben.

Architektonische Ansätze für Microsoft-Umgebungen

Es gibt zwei primäre Architekturen für die Integration von Microsoft-Identitäten mit der WiFi-Authentifizierung, jeweils mit unterschiedlichen Vor- und Nachteilen:

Hybrid On-Premise (Windows NPS + AD DS + Azure AD Connect): Dies ist der traditionelle Ansatz. Windows NPS fungiert als RADIUS-Server und authentifiziert Anfragen gegen ein lokales Active Directory. Um dies mit der Cloud zu verknüpfen, synchronisiert Azure AD Connect lokale Identitäten mit Entra ID. Dieser Ansatz ist zwar robust, erfordert jedoch die Wartung einer lokalen Serverinfrastruktur, die Verwaltung von Hochverfügbarkeit und die Bereitstellung einer komplexen PKI (ADCS) bei der Implementierung von EAP-TLS.

Cloud-Native (Cloud RADIUS + Entra ID + Intune): Dieser moderne Ansatz macht lokale NPS-Server überflüssig. Ein Cloud RADIUS-Drittanbieter integriert sich über die Microsoft Graph API direkt in Entra ID. Die Authentifizierung findet vollständig in der Cloud statt. Diese Architektur entspricht einer Cloud-First-Strategie, reduziert den betrieblichen Aufwand erheblich und steht im Einklang mit den Prinzipien des Zero-Trust-Netzwerkzugriffs.

EAP-TLS vs. PEAP-MSCHAPv2: Die entscheidende Wahl

Die Wahl der EAP-Methode ist die folgenschwerste Sicherheitsentscheidung bei dieser Bereitstellung. PEAP-MSCHAPv2 basiert darauf, dass Benutzer ihre Domain-Anmeldedaten eingeben. Dies ist anfällig für Diebstahl von Anmeldedaten, Man-in-the-Middle-Angriffe und führt zu einer schlechten Benutzererfahrung, wenn Passwörter ablaufen. Untersuchungen haben konsistent gezeigt, dass PEAP-MSCHAPv2 durch Angriffe mit gefälschten Access Points kompromittiert werden kann.

EAP-TLS (Transport Layer Security) ist der Goldstandard der Branche für sicheres WiFi. Es verwendet digitale Zertifikate, die auf dem Client-Gerät installiert sind, für eine gegenseitige Authentifizierung – sowohl der Client als auch der Server weisen ihre Identität nach. Es müssen keine Passwörter eingegeben werden, und die Verbindung ist kryptografisch stark. In einer Microsoft-Umgebung werden Zertifikate in der Regel mit Microsoft Intune über SCEP (Simple Certificate Enrollment Protocol) oder PKCS bereitgestellt. Dies ist der empfohlene Weg für alle neuen Bereitstellungen und ist unerlässlich für die Einhaltung von PCI DSS (Anforderung 8) und GDPR-Datenschutzverpflichtungen.

Implementierungsleitfaden: Schritt-für-Schritt-Bereitstellung

Die Implementierung der Entra ID WiFi-Authentifizierung mit EAP-TLS und Intune erfordert die Koordination mehrerer Komponenten in den Bereichen Identität, Geräteverwaltung und Netzwerkinfrastruktur. Der folgende Fünf-Phasen-Ansatz wird für eine Cloud-native Bereitstellung empfohlen.

Phase 1: Vorbereitung der Identitäts- und Geräteverwaltungsinfrastruktur

Überprüfen Sie zunächst, ob Ihr Entra ID-Mandant über die entsprechende Lizenzierung verfügt. Microsoft 365 E3/E5 oder Enterprise Mobility + Security (EMS) E3/E5 umfasst die Intune-Geräteverwaltung und die Funktionen für bedingten Zugriff, die für diese Bereitstellung erforderlich sind. Ohne Intune ist eine automatisierte Zertifikatsbereitstellung nicht möglich.

Richten Sie als Nächstes Ihre Public-Key-Infrastruktur (PKI) ein. Sie haben drei Optionen: eine Cloud-native PKI, die von Ihrem Cloud-RADIUS-Anbieter bereitgestellt wird, Microsofts eigene Cloud-PKI (verfügbar mit der Intune Suite-Lizenzierung) oder eine bestehende On-Premise-ADCS-Bereitstellung, die über den Microsoft Intune Certificate Connector mit Intune verbunden ist. Für neue Bereitstellungen wird eine Cloud-native PKI dringend empfohlen, um On-Premise-Abhängigkeiten zu vermeiden.

Phase 2: Konfigurieren von Intune für die Zertifikatsbereitstellung

Erstellen Sie im Microsoft Intune Admin Center ein Konfigurationsprofil für ein vertrauenswürdiges Zertifikat. Laden Sie das Root-CA-Zertifikat Ihrer PKI hoch und weisen Sie es Ihren Zielgerätegruppen zu. Dieser Schritt ist entscheidend: Er stellt sicher, dass Client-Geräte dem vom RADIUS-Server während des TLS-Handshakes präsentierten Zertifikat vertrauen, wodurch Man-in-the-Middle-Angriffe verhindert werden.

Erstellen Sie als Nächstes ein SCEP-Zertifikatsprofil (oder PKCS, falls Ihre PKI dies erfordert). Konfigurieren Sie das Format des Antragstellernamens (Subject Name) – verwenden Sie für die benutzerbasierte Authentifizierung CN={{UserPrincipalName}}; für die gerätebasierte Authentifizierung verwenden Sie CN={{DeviceName}} oder die Seriennummer des Geräts. Stellen Sie den alternativen Antragsteller-Namen (SAN) so ein, dass er den User Principal Name oder die Geräte-ID enthält. Weisen Sie beide Profile den entsprechenden Entra ID-Geräte- oder Benutzergruppen zu.

Phase 3: Cloud RADIUS-Integration konfigurieren

Erteilen Sie Ihrem Cloud RADIUS-Anbieter die erforderlichen Microsoft Graph API-Berechtigungen in Ihrem Entra ID-Mandanten. Der Anbieter benötigt mindestens User.Read.All und GroupMember.Read.All, um Gruppenmitgliedschaften während der Authentifizierung zu validieren. Einige Anbieter erfordern auch Device.Read.All für gerätebasierte Richtlinien.

Definieren Sie im Cloud RADIUS-Verwaltungsportal Ihre Authentifizierungsrichtlinien. Eine gut strukturierte Richtlinie für eine Unternehmensumgebung könnte wie folgt lauten: "Zugriff erlauben, wenn das Zertifikat von [Trusted CA] ausgestellt wurde UND der Benutzer Mitglied der Entra ID-Gruppe [Corporate-WiFi-Users] ist UND das Gerät in Intune als konform markiert ist." Diese mehrschichtige Richtlinie setzt sowohl die Identität als auch den Gerätestatus gleichzeitig durch.

Phase 4: Drahtlose Infrastruktur konfigurieren

Fügen Sie in Ihrem Wireless-LAN-Controller oder Cloud-Verwaltungs-Dashboard (wie Cisco Meraki, Aruba Central oder Juniper Mist) die Cloud RADIUS-Server-IP-Adressen und Shared Secrets als RADIUS-Authentifizierungsserver hinzu. Konfigurieren Sie Primär- und Sekundärserver für Redundanz. Stellen Sie das RADIUS-Timeout auf mindestens 5 Sekunden ein, um die Latenzzeiten für Cloud-Roundtrips auszugleichen.

Erstellen Sie eine neue SSID, die für WPA2-Enterprise oder WPA3-Enterprise konfiguriert ist. Weisen Sie dieser SSID die RADIUS-Server zu. Stellen Sie bei Hospitality -Bereitstellungen sicher, dass sich diese Unternehmens-SSID in einem separaten VLAN von allen Gastnetzwerken befindet. In Retail -Umgebungen sollten Sie in Erwägung ziehen, die Unternehmens-SSID nur in Back-of-House-Bereichen bereitzustellen und das Netzwerk der Verkaufsfläche getrennt zu halten.

Phase 5: WiFi-Profil über Intune bereitstellen

Erstellen Sie ein WiFi-Konfigurationsprofil in Intune. Stellen Sie die SSID so ein, dass sie genau mit der auf der drahtlosen Infrastruktur konfigurierten übereinstimmt. Wählen Sie WPA2-Enterprise oder WPA3-Enterprise als Sicherheitstyp. Wählen Sie unter den EAP-Einstellungen EAP-TLS als Authentifizierungsmethode. Verknüpfen Sie das SCEP-Zertifikatsprofil als Client-Zertifikat und geben Sie das in Phase 2 bereitgestellte Trusted Root CA-Profil an.

Weisen Sie dieses WiFi-Profil denselben Gerätegruppen zu, die die Zertifikatsprofile erhalten haben. Die Geräte erhalten das Zertifikat und die WiFi-Konfiguration bei der nächsten Intune-Synchronisierung im Hintergrund und verbinden sich automatisch, sobald sie sich in Reichweite der SSID befinden – ohne dass eine Benutzerinteraktion erforderlich ist.

Best Practices für Unternehmensumgebungen

Die folgenden Empfehlungen entsprechen dem Branchenkonsens für sichere, skalierbare Microsoft 802.1X-Bereitstellungen in Unternehmensumgebungen.

Schreiben Sie EAP-TLS für alle neuen Bereitstellungen vor. Stellen Sie keine neuen Netzwerke mit PEAP-MSCHAPv2 bereit. Die Sicherheitsrisiken von anmeldedatenbasiertem WiFi sind gut dokumentiert und unvereinbar mit einem Zero-Trust-Sicherheitskonzept. EAP-TLS ist für die Einhaltung von PCI DSS, GDPR und ISO 27001 unerlässlich. Automatisieren Sie den Zertifikatslebenszyklus. Stellen Sie sicher, dass bei der Deaktivierung eines Benutzers in Entra ID oder der Ausmusterung eines Geräts in Intune das entsprechende Zertifikat automatisch widerrufen wird oder die RADIUS-Richtlinie den Zugriff sofort blockiert. Dies ist besonders wichtig in Branchen mit hoher Fluktuation wie dem Gastgewerbe und dem Einzelhandel , wo Personalwechsel häufig vorkommen.

Implementieren Sie Entra ID Conditional Access. Nutzen Sie Richtlinien für bedingten Zugriff, um die Geräte-Compliance als Bedingung für den Netzwerkzugriff durchzusetzen. Indem Sie vorschreiben, dass Geräte in Intune als „konform“ markiert sein müssen, bevor sie sich bei RADIUS authentifizieren können, stellen Sie sicher, dass nur gepatchte, richtlinienkonforme Geräte auf das Unternehmensnetzwerk zugreifen.

Segmentieren Sie Unternehmens- und Gastnetzwerke konsequent. 802.1X ist für verwaltete Unternehmensgeräte konzipiert. Implementieren Sie für Besucher, Auftragnehmer und BYOD eine dedizierte Guest WiFi -Lösung mit einem Captive Portal. Diese kann für den Zugriff von Auftragnehmern in Entra ID B2B integriert werden oder Social Logins und SMS-Verifizierung für den allgemeinen öffentlichen Zugriff nutzen. Erlauben Sie niemals unverwalteten Geräten den Zugriff auf die 802.1X-SSID des Unternehmens.

Planen Sie für Legacy- und IoT-Geräte. Drucker, IoT-Sensoren und ältere Geräte, die keine Zertifikate unterstützen, erfordern eine separate Strategie. Verwenden Sie MAC Authentication Bypass (MAB) für bekannte Geräte oder eine dedizierte WPA2-Personal-SSID mit einem komplexen, rotierenden PSK, isoliert in einem dedizierten VLAN. Die Sensors -Plattform von Purple kann beispielsweise in einem dedizierten IoT-VLAN betrieben werden, das von der Authentifizierungsinfrastruktur des Unternehmens getrennt ist.

Überwachen Sie Authentifizierungsereignisse. Integrieren Sie RADIUS-Protokolle in Ihr SIEM oder nutzen Sie die WiFi Analytics -Plattform, um Authentifizierungsfehler, Warnungen zum Ablauf von Zertifikaten und ungewöhnliche Zugriffsmuster zu überwachen. Proaktive Überwachung verhindert Ausfälle, bevor sie den Betrieb beeinträchtigen.

Fehlerbehebung & Risikominderung

Selbst gut geplante Bereitstellungen stoßen auf Probleme. Im Folgenden sind die häufigsten Fehlerszenarien und deren Behebung aufgeführt.

Fehler bei der Zertifikatsbereitstellung. Das häufigste Problem bei einer EAP-TLS-Bereitstellung besteht darin, dass Geräte keine Zertifikate von Intune erhalten. Dies wird in der Regel durch einen falsch konfigurierten Intune Certificate Connector (bei Verwendung von lokalem ADCS), eine falsche SCEP-URL oder eine fehlerhafte Synchronisierung der Geräte mit Intune verursacht. Überprüfen Sie immer den Status des Certificate Connectors im Intune Admin Center und kontrollieren Sie die Synchronisierungsprotokolle der Geräte. Stellen Sie sicher, dass das SCEP-Dienstkonto über die erforderlichen Berechtigungen auf der CA verfügt.

RADIUS-Timeout-Probleme. Wenn der Access Point den RADIUS-Server nicht innerhalb des konfigurierten Timeouts erreichen kann, schlägt die Verbindung der Clients fehl. Stellen Sie sicher, dass Ihre Firewall-Regeln die UDP-Ports 1812 (Authentifizierung) und 1813 (Accounting) ausgehend zu den IP-Bereichen des Cloud-RADIUS-Anbieters zulassen. Wenn Sie ein lokales NPS verwenden, stellen Sie mindestens zwei NPS-Server bereit und konfigurieren Sie Ihre Access Points für ein Failover zwischen diesen. Zertifikatsvertrauensfehler. Wenn Clients die Fehlermeldung "Nicht vertrauenswürdiges Serverzertifikat" erhalten, wurde das vertrauenswürdige Stamm-Zertifizierungsstellenprofil nicht korrekt auf dem Gerät bereitgestellt. Überprüfen Sie die Profilzuweisung in Intune und kontrollieren Sie den Zertifikatsspeicher des Geräts. Dies ist ein häufiges Problem bei neu registrierten Geräten, die ihre erste Intune-Synchronisierung noch nicht abgeschlossen haben.

NPS-Erweiterung für Azure MFA. Obwohl es technisch möglich ist, die NPS-Erweiterung zu verwenden, um die Multi-Faktor-Authentifizierung für WiFi zu erzwingen, wird dies für den primären Zugriff dringend abgeraten. Die Benutzererfahrung, bei jedem Wechsel des Geräts zwischen Access Points eine MFA-Aufforderung zu erhalten, ist äußerst störend. Verlassen Sie sich stattdessen auf die starke Authentifizierung durch das Gerätezertifikat und erzwingen Sie MFA auf der Anwendungsebene.

Gruppenrichtlinienkonflikte. In Hybrid-Umgebungen können Gruppenrichtlinienobjekte (GPOs), die den Windows-Wireless-Client konfigurieren, mit Intune-WiFi-Profilen kollidieren. Stellen Sie sicher, dass Intune-Profile Vorrang haben, indem Sie die MDM-Registrierungseinstellungen überprüfen und gegebenenfalls die GPO-basierte Wireless-Konfiguration für von Intune verwaltete Geräte blockieren.

ROI & geschäftliche Auswirkungen

Die Migration zu einer Cloud-nativen RADIUS-Architektur, die in Entra ID integriert ist, liefert messbaren, quantifizierbaren Mehrwert in mehreren Dimensionen.

Reduzierung von Helpdesk-Tickets. Passwortbezogene WiFi-Probleme – Sperren, abgelaufene Passwörter, falsch konfigurierte Supplicants – sind eine erhebliche Quelle für IT-Support-Tickets in anmeldedatenbasierten Umgebungen. EAP-TLS eliminiert diese vollständig. Unternehmen berichten in der Regel von einer Reduzierung des WiFi-bezogenen Helpdesk-Volumens um 30–50 % nach der Migration zur zertifikatsbasierten Authentifizierung.

Einsparungen bei den Infrastrukturkosten. Die Außerbetriebnahme von On-Premise-NPS-Servern reduziert die Rechenkosten, die Betriebssystem-Lizenzgebühren und den betrieblichen Aufwand für das Patchen und Verwalten von Hochverfügbarkeits-Clustern. Für ein mittelgroßes Unternehmen, das zwei NPS-Server betreibt, kann dies Einsparungen von 15.000 bis 30.000 £ pro Jahr an Infrastruktur- und Betriebskosten bedeuten.

Verbesserte Sicherheitslage und Compliance. Die Abkehr von der anmeldedatenbasierten Authentifizierung mindert das Risiko von Diebstahl von Anmeldedaten und lateralen Bewegungen und schützt sensible Unternehmensdaten. Für Unternehmen, die PCI DSS unterliegen, adressiert dies direkt die Anforderungen an die Netzwerkzugriffskontrolle. Für Healthcare -Organisationen, die mit Patientendaten arbeiten, unterstützt es die DSPT-Compliance. Für Transport -Betreiber entspricht es den Anforderungen der NIS2-Richtlinie für Netzwerksicherheit.

Verbesserte Benutzererfahrung. Eine nahtlose, automatische WiFi-Verbindung – ohne Passwortabfragen, ohne Sperren und ohne manuelle Konfiguration – steigert die Produktivität und verringert Reibungsverluste für die Mitarbeiter. Dies ist besonders in hochmobilen Umgebungen wie Vertriebszentren, Krankenhausstationen und Verkaufsflächen im Einzelhandel von großer Bedeutung. Indem Sie Ihr WiFi-Netzwerk als Erweiterung Ihrer Cloud-Identity-Strategie behandeln, gewährleisten Sie einen sicheren, reibungslosen Zugriff, der mit Ihrem Unternehmen skaliert. Weitere Informationen zu den Aspekten der SD-WAN-Integration in modernen Unternehmensnetzwerken finden Sie unter The Core SD-WAN Benefits for Modern Businesses . Spezifische Bereitstellungsaspekte für das Gastgewerbe finden Sie unter Modern Hospitality WiFi Solutions Your Guests Deserve .