Azure AD und Entra ID WiFi-Authentifizierung: Integrations- und Konfigurationsleitfaden
Dieser technische Leitfaden bietet IT-Managern, Netzwerkarchitekten und Leitern des Standortbetriebs einen praktischen Fahrplan für die Integration von Microsoft Entra ID (Azure AD) in Unternehmens-WiFi-Netzwerke unter Verwendung von RADIUS und 802.1X. Er behandelt die architektonische Entscheidung zwischen lokalem Windows NPS und Cloud-nativem RADIUS, die Bereitstellung zertifikatsbasierter EAP-TLS-Authentifizierung über Microsoft Intune sowie betriebliche Best Practices zur Absicherung des drahtlosen Zugangs in den Bereichen Gastgewerbe, Einzelhandel und im öffentlichen Sektor. Für Unternehmen, die bereits in das Microsoft 365- und Entra ID-Ökosystem investiert haben, schließt dieser Leitfaden die Lücke zwischen Cloud-Identitätsmanagement und physischer Netzwerksicherheit.
Management-Zusammenfassung
Für moderne Unternehmen, die stark in das Microsoft-Ökosystem investiert haben, ist die Verknüpfung der Cloud-Identitätsinfrastruktur mit physischen drahtlosen Netzwerken eine kritische Sicherheitsanforderung. Historisch gesehen 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 herkömmliche anmeldedatenbasierte 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 eines lokalen NPS-Fußabdrucks und der Migration zu einer Cloud-nativen RADIUS-Lösung. Entscheidend ist, dass wir detailliert beschreiben, wie Microsoft Intune für die zertifikatsbasierte Authentifizierung (EAP-TLS) genutzt werden kann, was passwortbezogene Schwachstellen eliminiert und eine nahtlose, reibungslose Erfahrung für Endbenutzer bietet. Unabhängig davon, ob Sie ein Hotel mit 500 Zimmern, eine Einzelhandelskette oder einen großen Einsatz im öffentlichen Sektor verwalten, hilft Ihnen dieser Leitfaden dabei, Ihren Wireless Edge unter Nutzung Ihrer bestehenden Microsoft-Identitätsinvestitionen abzusichern. Für eine umfassendere Diskussion der Bereitstellungsmodelle siehe unseren Cloud RADIUS vs On-Premise RADIUS: Entscheidungsleitfaden für IT-Teams .
Technischer Deep-Dive: Architektur und Standards
Die Grundlage für sicheres Unternehmens-WiFi ist der Standard IEEE 802.1X, der eine portbasierte Netzwerkzugriffskontrolle bietet. In einer Microsoft-zentrierten Umgebung erfordert die Integration von 802.1X in Entra ID eine sorgfältige Architekturplanung über drei Ebenen hinweg: die Wireless-Infrastruktur, den Authentifizierungsserver und das Identitätsverzeichnis.
Die Rolle von RADIUS und 802.1X
Wenn ein Client-Gerät (der Supplicant) versucht, eine Verbindung zu einem WPA2/WPA3-Enterprise-Netzwerk herzustellen, blockiert der Wireless Access Point (der Authenticator) den gesamten Datenverkehr außer 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 gegenüber einem Verzeichnisdienst und gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Dieses Drei-Parteien-Modell – Supplicant, Authenticator, Authentifizierungsserver – ist der Eckpfeiler der drahtlosen Sicherheit in Unternehmen und wird ausführlich in unserem Wireless Access Points Definition: Ihr ultimativer Leitfaden für 2026 beschrieben.
Architekturansätze für Microsoft-Umgebungen
Es gibt zwei primäre Architekturen für die Integration der Microsoft-Identität in die WiFi-Authentifizierung, jede mit unterschiedlichen Vor- und Nachteilen:
| Dimension | Hybrid On-Premise (NPS) | Cloud-Native (Cloud RADIUS) |
|---|---|---|
| Infrastruktur | Windows Server VM oder Bare Metal erforderlich | Keine lokalen Server |
| Identitätsquelle | AD DS über LDAP/Kerberos | Entra ID direkt über API |
| Zertifizierungsstelle | ADCS lokal + Intune Connector | Intune Cloud PKI oder Anbieter-PKI |
| Skalierbarkeit | Manuelle HA/Lastverteilung | Automatisch skaliert durch Anbieter |
| Ideal für | Hybrid AD, Legacy-Geräte | Cloud-first, Intune-verwaltete Organisationen |
| Betriebliche Komplexität | Höher (initial und laufend) | Geringerer Betriebsaufwand |
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über einem lokalen Active Directory. Um dies mit der Cloud zu verknüpfen, synchronisiert Azure AD Connect lokale Identitäten mit Entra ID. Dies ist zwar robust, erfordert jedoch die Wartung einer lokalen Serverinfrastruktur, die Verwaltung der Hochverfügbarkeit und die Bereitstellung einer komplexen PKI (ADCS), wenn EAP-TLS implementiert wird.
Cloud-Native (Cloud RADIUS + Entra ID + Intune): Dieser moderne Ansatz macht lokale NPS-Server überflüssig. Ein Drittanbieter von Cloud RADIUS integriert sich über die Microsoft Graph API direkt in Entra ID. Die Authentifizierung erfolgt vollständig in der Cloud. Diese Architektur entspricht einer Cloud-First-Strategie, reduziert den Betriebsaufwand 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 folgenreichste Sicherheitsentscheidung bei dieser Bereitstellung. PEAP-MSCHAPv2 verlässt sich darauf, dass Benutzer ihre Domänen-Anmeldedaten eingeben. Dies ist anfällig für den 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 über betrügerische 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 unter Verwendung von 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
Beginnen Sie mit der Überprüfung, ob Ihr Entra ID Tenant über die entsprechende Lizenzierung verfügt. Microsoft 365 E3/E5 oder Enterprise Mobility + Security (EMS) E3/E5 umfasst die Intune-Geräteverwaltung und die Conditional Access-Funktionen, die für diese Bereitstellung erforderlich sind. Ohne Intune ist eine automatisierte Zertifikatsbereitstellung nicht möglich.
Etablieren Sie als Nächstes Ihre Public-Key-Infrastruktur (PKI). Sie haben drei Optionen: eine Cloud-native PKI Ihres Cloud RADIUS-Anbieters, 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: Konfiguration von Intune für die Zertifikatsbereitstellung
Erstellen Sie im Microsoft Intune Admin Center ein Konfigurationsprofil für vertrauenswürdige Zertifikate (Trusted Certificate). Laden Sie das Root-CA-Zertifikat Ihrer PKI hoch und stellen Sie es für Ihre Zielgerätegruppen bereit. 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. Legen Sie den Subject Alternative Name (SAN) so fest, 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: Konfiguration der Cloud RADIUS-Integration
Erteilen Sie Ihrem Cloud RADIUS-Anbieter die erforderlichen Microsoft Graph API-Berechtigungen in Ihrem Entra ID Tenant. Der Anbieter benötigt mindestens User.Read.All und GroupMember.Read.All, um Gruppenmitgliedschaften während der Authentifizierung zu validieren. Einige Anbieter benötigen 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 [Vertrauenswürdige CA] ausgestellt wurde UND der Benutzer Mitglied der Entra ID-Gruppe [Corporate-WiFi-Users] ist UND das Gerät in Intune als konform (Compliant) markiert ist.“ Diese mehrschichtige Richtlinie erzwingt gleichzeitig die Identität und den Gerätezustand.
Phase 4: Konfiguration der Wireless-Infrastruktur
Fügen Sie in Ihrem Wireless LAN Controller oder Cloud-Management-Dashboard (wie Cisco Meraki, Aruba Central oder Juniper Mist) die IP-Adressen und Shared Secrets des Cloud RADIUS-Servers als RADIUS-Authentifizierungsserver hinzu. Konfigurieren Sie Primär- und Sekundärserver für Redundanz. Stellen Sie den RADIUS-Timeout auf mindestens 5 Sekunden ein, um Cloud-Roundtrip-Latenzen zu berücksichtigen.
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 jeglichen Gastnetzwerken befindet. Erwägen Sie in Retail -Umgebungen, die Unternehmens-SSID nur in Back-of-House-Bereichen bereitzustellen und das Netzwerk der Verkaufsfläche getrennt zu halten.
Phase 5: Bereitstellung des WiFi-Profils über Intune
Erstellen Sie ein WiFi-Konfigurationsprofil in Intune. Stellen Sie die SSID so ein, dass sie exakt mit der in der Wireless-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 Profil für die vertrauenswürdige Root-CA 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 geräuschlos während ihrer nächsten Intune-Synchronisierung und verbinden sich automatisch, wenn 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 an Unternehmensstandorten.
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 mit einer Zero-Trust-Sicherheitsstrategie unvereinbar. EAP-TLS ist unerlässlich für die Einhaltung von PCI DSS, GDPR und ISO 27001.
Automatisieren Sie den Zertifikatslebenszyklus. Stellen Sie sicher, dass ein Zertifikat automatisch widerrufen wird oder die RADIUS-Richtlinie den Zugriff sofort blockiert, wenn ein Benutzer in Entra ID deaktiviert oder ein Gerät in Intune außer Dienst gestellt wird. Dies ist besonders wichtig in Umgebungen mit hoher Fluktuation wie Hospitality und Retail , in denen Personalwechsel häufig vorkommen.
Implementieren Sie Entra ID Conditional Access. Nutzen Sie Conditional Access-Richtlinien, um die Gerätekonformität als Bedingung für den Netzwerkzugriff zu erzwingen. Die Anforderung, dass Geräte in Intune als „konform“ markiert sein müssen, bevor sie sich gegenüber RADIUS authentifizieren können, stellt sicher, dass nur gepatchte, richtlinienkonforme Geräte auf das Unternehmensnetzwerk zugreifen.
Segmentieren Sie Unternehmens- und Gastnetzwerke strikt. 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 mit Entra ID B2B für den Zugriff von Auftragnehmern integriert werden oder Social Logins und SMS-Verifizierung für den allgemeinen öffentlichen Zugriff nutzen. Erlauben Sie niemals nicht verwalteten Geräten den Zugriff auf die Unternehmens-802.1X-SSID.
Planen Sie für Legacy- und IoT-GeräteGeräte.** Drucker, IoT-Sensoren und Legacy-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, rotierten 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.
Authentifizierungsereignisse überwachen. 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. Proaktives Monitoring verhindert Ausfälle, bevor sie den Betrieb beeinträchtigen.
Fehlerbehebung & Risikominderung
Selbst gut geplante Implementierungen können auf Probleme stoßen. Im Folgenden finden Sie die häufigsten Fehlermodi und deren Lösungen.
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 On-Premise ADCS), eine falsche SCEP-URL oder eine fehlende Synchronisierung der Geräte mit Intune verursacht. Überprüfen Sie stets 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 innerhalb des konfigurierten Timeouts nicht 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. Bei Verwendung von On-Premise NPS sollten Sie mindestens zwei NPS-Server bereitstellen und Ihre Access Points so konfigurieren, dass ein Failover zwischen ihnen erfolgt.
Fehler beim Zertifikatsvertrauen. Wenn Clients die Fehlermeldung „Nicht vertrauenswürdiges Serverzertifikat“ erhalten, wurde das Profil der vertrauenswürdigen Stammzertifizierungsstelle (Trusted Root CA) 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 eine Multi-Faktor-Authentifizierung für WiFi zu erzwingen, wird für den primären Zugriff dringend davon abgeraten. Die Benutzererfahrung, bei jedem Roaming zwischen Access Points eine MFA-Aufforderung zu erhalten, ist extrem störend. Verlassen Sie sich stattdessen auf die starke Authentifizierung durch das Gerätezertifikat und erzwingen Sie MFA auf der Anwendungsebene.
Konflikte bei Gruppenrichtlinien. In hybriden Umgebungen können Gruppenrichtlinienobjekte (GPOs), die den Windows-Wireless-Client konfigurieren, mit Intune WiFi-Profilen in Konflikt stehen. 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 verschiedenen Dimensionen.
Weniger Helpdesk-Tickets. Passwortbezogene WiFi-Probleme – Sperrungen, 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-Aufkommens um 30–50 % nach der Migration zur zertifikatsbasierten Authentifizierung.
Einsparungen bei den Infrastrukturkosten. Die Außerbetriebnahme von On-Premise NPS-Servern reduziert Rechenkosten, Betriebssystem-Lizenzgebühren und den betrieblichen Aufwand für das Patchen und Warten 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 bei Infrastruktur- und Betriebskosten bedeuten.
Verbesserte Sicherheitslage und Compliance. Die Abkehr von der anmeldedatenbasierten Authentifizierung mindert das Risiko von Diebstahl von Anmeldedaten und Lateral Movement und schützt so sensible Unternehmensdaten. Für Unternehmen, die PCI DSS unterliegen, adressiert dies direkt die Anforderungen an die Netzwerkzugriffskontrolle. Für Healthcare -Organisationen, die Patientendaten verarbeiten, 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 Sperrungen und ohne manuelle Konfiguration – steigert die Produktivität und reduziert Reibungsverluste für die Mitarbeiter. Dies ist besonders wirkungsvoll in Umgebungen mit hoher Mobilität, wie z. B. in Distributionszentren, Krankenhausstationen und auf Verkaufsflächen im Einzelhandel.
Indem Sie Ihr WiFi-Netzwerk als Erweiterung Ihrer Cloud-Identity-Strategie betrachten, gewährleisten Sie einen sicheren, reibungslosen Zugriff, der mit Ihrem Unternehmen mitwächst. Weitere Informationen zu den SD-WAN-Integrationsaspekten moderner Unternehmensnetzwerke finden Sie unter Die wichtigsten Vorteile von SD-WAN für moderne Unternehmen . Spezifische Überlegungen zur Bereitstellung im Gastgewerbe finden Sie unter Moderne Hospitality-WiFi-Lösungen, die Ihre Gäste verdienen .
Schlüsselbegriffe & Definitionen
802.1X
An IEEE standard for port-based Network Access Control (PNAC). It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN, preventing unauthorised access before authentication is complete.
The foundational protocol that prevents unauthorised devices from accessing the enterprise network. All WPA2/WPA3-Enterprise deployments rely on 802.1X.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users who connect and use a network service. Defined in RFC 2865.
The server component that validates credentials or certificates against the directory (Entra ID or AD DS) and instructs the access point to grant or deny access.
Supplicant
The client device (laptop, smartphone, IoT device) attempting to connect to the network. In Windows, the built-in wireless client acts as the supplicant.
In Intune deployments, the supplicant must be configured with the correct WiFi profile and client certificate to communicate successfully with the RADIUS server.
Authenticator
The network device — typically a Wireless Access Point or managed switch — that facilitates the authentication process between the supplicant and the RADIUS server. It enforces access control based on the RADIUS response.
The access point must be configured with the RADIUS server IP address and shared secret. It acts as a relay, forwarding EAP packets between the client and the RADIUS server.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
An EAP method that relies on digital certificates for mutual authentication between the client and the RADIUS server. It is defined in RFC 5216 and is considered one of the most secure EAP standards available.
The recommended authentication method for all new Microsoft 802.1X deployments. It eliminates passwords entirely and is required for compliance with PCI DSS and zero-trust network access frameworks.
NPS (Network Policy Server)
Microsoft's implementation of a RADIUS server and proxy, available as a role in Windows Server. NPS can authenticate users and devices against Active Directory Domain Services.
The traditional on-premise solution for enterprise WiFi authentication in Microsoft environments. Many organisations are now migrating from NPS to Cloud RADIUS solutions as they move to Entra ID.
SCEP (Simple Certificate Enrollment Protocol)
A protocol used for issuing digital certificates to network devices in a scalable, automated manner. Defined in RFC 8894.
The primary method Microsoft Intune uses to silently deploy client certificates to managed devices for EAP-TLS WiFi authentication. Requires a SCEP-compatible Certificate Authority.
Microsoft Entra ID
Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory. It provides user authentication, group management, Conditional Access, and integration with thousands of applications.
The central identity provider in modern Microsoft environments. Cloud RADIUS solutions integrate with Entra ID via Microsoft Graph API to validate user and device identities during WiFi authentication.
Conditional Access
An Entra ID feature that enforces access policies based on signals such as user identity, device compliance status, location, and risk level. Policies can require devices to be Intune-compliant before granting access.
Used in advanced RADIUS deployments to ensure that only compliant, managed devices can authenticate to the corporate WiFi network, even if they present a valid certificate.
PEAP-MSCHAPv2
Protected EAP with Microsoft Challenge Handshake Authentication Protocol version 2. A credential-based EAP method that uses a username and password for authentication, tunnelled within a TLS session.
The legacy authentication method used in many existing NPS deployments. It is vulnerable to credential theft and man-in-the-middle attacks and should be migrated to EAP-TLS in all new deployments.
Fallstudien
A 200-location retail chain needs to secure their back-office WiFi for store manager laptops. They currently use a shared WPA2-Personal password (PSK) across all stores, which is rarely rotated. They use Entra ID and Intune for device management. How should they modernise their wireless security?
The retail chain should migrate to WPA3-Enterprise using EAP-TLS across all 200 locations. The recommended architecture is a Cloud RADIUS solution integrated directly with their Entra ID tenant, eliminating the need for on-premise NPS servers at each site. Using Intune, they deploy a SCEP certificate profile to issue unique device certificates to the store manager laptops. A Trusted Root CA profile is deployed first to ensure devices trust the RADIUS server. A WiFi configuration profile is then deployed via Intune, silently connecting devices to the new SSID using the issued certificate. The old PSK SSID is decommissioned once all devices have migrated. For the store's customer-facing WiFi, a separate captive portal solution handles guest access without impacting the corporate authentication infrastructure.
A large conference centre uses on-premise Windows NPS for staff WiFi authentication. They are experiencing frequent connectivity failures during large events because the NPS server becomes overwhelmed with concurrent authentication requests from 500+ staff devices. They are also migrating their identity infrastructure to Entra ID. What is the recommended architecture going forward?
The conference centre should migrate from the on-premise NPS server to a Cloud RADIUS provider that integrates directly with Entra ID. Staff devices should be transitioned to certificate-based authentication (EAP-TLS) managed via Intune, resolving both the scalability issue and the Entra ID migration requirement simultaneously. For the high volume of event attendees, a separate, segmented network using a captive portal solution handles guest onboarding without impacting the corporate RADIUS infrastructure. The two networks should be on separate VLANs with appropriate firewall rules between them. The on-premise NPS server can be decommissioned once all staff devices have successfully migrated.
Szenarioanalyse
Q1. Your organisation is completing a full migration from on-premise Active Directory to Entra ID only — no on-premise domain controllers will remain. You currently use Windows NPS for WiFi authentication using PEAP-MSCHAPv2. What is the most secure and operationally efficient approach for the new cloud-only environment, and what specific steps are required?
💡 Hinweis:Consider what NPS requires to function and whether those dependencies will exist post-migration. Also consider the security implications of the current EAP method.
Empfohlenen Ansatz anzeigen
The most secure and efficient approach is to implement a Cloud RADIUS solution integrated directly with Entra ID, and transition to EAP-TLS certificate-based authentication managed via Microsoft Intune. NPS cannot authenticate against Entra ID directly — it requires on-premise AD DS — so it cannot survive the migration without Azure AD Connect maintaining a hybrid identity. The steps are: (1) Select a Cloud RADIUS provider and grant it Microsoft Graph API permissions in Entra ID. (2) Establish a cloud-native PKI or use Microsoft Cloud PKI. (3) Deploy Trusted Root CA and SCEP certificate profiles via Intune. (4) Deploy a WiFi configuration profile via Intune configured for EAP-TLS. (5) Configure the SSID on the wireless infrastructure to use the Cloud RADIUS servers. (6) Decommission NPS once all devices have migrated.
Q2. A hospital IT team wants to implement 802.1X for their medical carts (Windows laptops) using Entra ID. They want to ensure that if a cart is stolen, it cannot connect to the network even if the associated user account is still active. How should the certificate profile and RADIUS policy be configured to achieve this?
💡 Hinweis:Consider the difference between user-based and device-based certificate profiles in Intune, and how RADIUS policies can be scoped to device identity.
Empfohlenen Ansatz anzeigen
The IT team should configure Intune to deploy device certificates (not user certificates) to the medical carts. In the SCEP profile, the Subject Name should reference the device identity (e.g., CN={{DeviceName}} or the device serial number) rather than the user UPN. The RADIUS policy should be configured to authenticate the device certificate and validate the device against Entra ID device objects. If a cart is stolen, the IT team can remotely wipe the device via Intune (which removes the certificate from the device's certificate store) or revoke the specific device certificate in the PKI. Either action immediately blocks network access without affecting any user accounts. This approach is superior to user-based certificates for shared devices like medical carts.
Q3. You have successfully deployed EAP-TLS via Intune for all 800 corporate laptops across a university campus. However, the IT department frequently brings in external contractors who need internet access for project work. These contractors use their own personal or company-issued laptops that are not enrolled in your Intune tenant. How should you provide access for these contractors without compromising the security of the corporate 802.1X network?
💡 Hinweis:Remember the architectural principle separating managed device authentication from unmanaged device access. Consider how Entra ID B2B could be leveraged.
Empfohlenen Ansatz anzeigen
Do not attempt to provision 802.1X access for unmanaged contractor devices. Instead, deploy a separate Guest SSID backed by a Captive Portal solution. For contractors who have their own corporate Entra ID tenants, configure the captive portal to support Entra ID B2B collaboration, allowing them to authenticate with their own corporate credentials via the portal. For contractors without a compatible identity provider, use a sponsored access workflow where a university staff member approves the access request. The contractor network should be on a separate VLAN with internet-only access and no route to internal university resources. This maintains the integrity of the 802.1X corporate network while providing a secure, auditable access path for external parties.
Q4. During a post-deployment review, your security team flags that several devices on the corporate WiFi are still using PEAP-MSCHAPv2 despite the EAP-TLS rollout. Investigation reveals these are IoT devices — smart displays, environmental sensors, and a fleet of network printers — that do not support certificate-based authentication. How should these devices be handled?
💡 Hinweis:Consider the options available for devices that cannot support EAP-TLS, and the importance of network segmentation.
Empfohlenen Ansatz anzeigen
IoT devices and legacy hardware that cannot support EAP-TLS should not be placed on the corporate 802.1X SSID. The recommended approach is to create a dedicated IoT SSID on a separate VLAN with strict firewall rules limiting communication to only the services those devices require (e.g., print servers, management platforms). For authentication, use MAC Authentication Bypass (MAB) for devices with known, fixed MAC addresses, or a WPA2-Personal SSID with a complex, regularly rotated PSK. The IoT VLAN should have no access to corporate file shares, Active Directory, or sensitive internal resources. Purple's Sensors platform, for example, is designed to operate on a dedicated IoT network segment, separate from corporate infrastructure.
Wichtigste Erkenntnisse
- ✓Traditional on-premise Windows NPS servers are being replaced by Cloud RADIUS solutions that integrate directly with Entra ID, eliminating on-premise infrastructure dependencies.
- ✓Credential-based authentication (PEAP-MSCHAPv2) is a significant security risk and should be migrated to EAP-TLS certificate-based authentication in all new and existing deployments.
- ✓EAP-TLS is the gold standard for secure, passwordless WiFi — certificates are deployed silently via Microsoft Intune using SCEP or PKCS profiles.
- ✓Microsoft Intune is the cornerstone of a modern Microsoft WiFi authentication stack, managing the full certificate lifecycle from issuance to revocation.
- ✓802.1X is designed exclusively for Intune-managed corporate devices; unmanaged guests and contractors must use a separate Captive Portal solution.
- ✓Entra ID Conditional Access can enforce device compliance as a prerequisite for WiFi authentication, ensuring only patched and policy-compliant devices connect.
- ✓RADIUS ports 1812 (authentication) and 1813 (accounting) must be open outbound from the wireless infrastructure to the RADIUS server — this is the most common cause of deployment failures.
