Autenticazione WiFi Enterprise senza Active Directory o server on-premise
Questa guida spiega come implementare un'autenticazione WiFi WPA2/3-Enterprise sicura senza Active Directory on-premise, Windows NPS o server RADIUS. Copre la discrepanza di protocollo tra i provider di identità cloud e 802.1X, i vantaggi di EAP-TLS rispetto a PEAP-MSCHAPv2 e come implementare il RADIUS cloud con certificati emessi da MDM per Microsoft Entra ID, Okta o Google Workspace. Scritta per i responsabili IT di organizzazioni cloud-first e con un'alta presenza di Mac/Chromebook pronte a dismettere l'infrastruttura on-premise.
Ascolta questa guida
Visualizza trascrizione del podcast
Parte della nostra serie principale: Enterprise WiFi Security Guide →
Management-Summary
Die meisten Unternehmen haben ihre Identitätsverwaltung in die Cloud verlagert. Microsoft Entra ID, Okta und Google Workspace verwalten heute Benutzer, Gruppen und Zugriffsrichtlinien für E-Mails, SaaS-Apps und die Geräteverwaltung. Doch das Enterprise-WiFi hat nicht Schritt gehalten. Access Points erwarten immer noch einen RADIUS-Server. Dieser RADIUS-Server war in der Vergangenheit meist ein Windows Network Policy Server (NPS), der mit einem lokalen Active Directory-Domänencontroller verbunden war.
Diese Diskrepanz zwingt IT-Teams dazu, eine redundante lokale Infrastruktur zu unterhalten, nur um das WiFi am Laufen zu halten. Die Lösung ist Cloud-RADIUS: ein vollständig verwalteter Authentifizierungsdienst, der RADIUS mit Ihren Access Points und OAuth2, SCIM sowie SAML mit Ihrem Cloud-Identity-Provider spricht. Kombinieren Sie dies mit der Bereitstellung von EAP-TLS-Zertifikaten über Ihr MDM, und Sie erhalten eine vollständige 802.1X-Bereitstellung – ganz ohne lokale Server, ohne OS-Patching und mit sofortigem Entzug von Zugriffsrechten direkt über Ihr Cloud-Verzeichnis.
Purple betreibt Cloud-RADIUS an über 80.000 Standorten weltweit mit einer Ausfallsicherheit von 99,999 % (interne Daten von Purple, 2024) und nativen Integrationen für Microsoft Entra ID, Okta und Google Workspace. In weniger als einer Stunde können Sie auf Ihren bestehenden Access Points von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet live gehen.
Technischer Deep-Dive
Die Protokoll-Diskrepanz als Kern des Problems
Die grundlegende Herausforderung besteht darin, dass Cloud-Identity-Provider und WiFi-Access-Points völlig unterschiedliche Sprachen sprechen. Microsoft Entra ID (ehemals Azure AD) authentifiziert Benutzer über SAML, OIDC und OAuth2 – also die Protokolle, die Browser und SaaS-Apps nutzen. WiFi-Access-Points verwenden RADIUS (Remote Authentication Dial-In User Service, RFC 2865), ein UDP-basiertes Protokoll aus den 1990er-Jahren, das für Wählleitungen und VPNs entwickelt wurde. Microsoft hat nie einen nativen RADIUS-Endpunkt für Entra ID bereitgestellt. Sie können einen Meraki- oder Aruba-Access-Point nicht direkt auf Azure verweisen und erwarten, dass 802.1X funktioniert.
Das ist die Hürde, an die jedes Cloud-First-IT-Team stößt, wenn es versucht, das Mitarbeiter-WiFi mit WPA2-Enterprise oder WPA3-Enterprise zu sichern. Es braucht eine Brücke zwischen dem Access Point und dem Cloud-Identity-Provider. Diese Brücke ist Cloud-RADIUS.
Warum PEAP-MSCHAPv2 ohne Active Directory scheitert
In der Vergangenheit basierten 802.1X-Bereitstellungen auf PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol mit Microsoft Challenge Handshake Authentication Protocol Version 2). Der Benutzer gab seinen Benutzernamen und sein Passwort ein, der Access Point leitete die Anfrage an den RADIUS-Server weiter und der RADIUS-Server glich das Passwort mit einem in Active Directory gespeicherten NTLM-Hash ab.
Microsoft Entra ID speichert keine NTLM-Hashes. Dies ist keine Konfigurationslücke, sondern eine bewusste architektonische Entscheidung. Entra ID ist ein moderner Cloud-Identity-Provider, kein Domänencontroller. Folglich kann ein RADIUS-Server, der auf Entra ID verweist, eine PEAP-MSCHAPv2-Anfrage nicht validieren. Der einzige Weg, PEAP mit Entra ID zu nutzen, besteht darin, Entra Domain Services bereitzustellen – ein kostenpflichtiges, verwaltetes Active Directory, das mit Entra ID synchronisiert wird – und NPS darauf aufzusetzen. Damit führen Sie genau das wieder ein, was Sie eigentlich abschaffen wollten: Windows Server-VMs, OS-Patching, NTLM-Hash-Speicherung und manuelle Zertifikatsverwaltung.
EAP-TLS: Die richtige Lösung für Cloud-First-Unternehmen
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) ersetzt Passwörter durch digitale X.509-Zertifikate. Das Gerät legt dem RADIUS-Server ein Zertifikat vor. Der RADIUS-Server validiert das Zertifikat anhand einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA). Da bei diesem Austausch kein Passwort übertragen wird, benötigt der RADIUS-Server keinen NTLM-Hash-Speicher. Er muss lediglich der CA vertrauen und die Gruppenmitgliedschaft des Benutzers im Identity-Provider prüfen, um das richtige VLAN und die passende Zugriffsrichtlinie anzuwenden.
EAP-TLS ist von Haus aus phishing-resistent. Es gibt keine Anmeldedaten, die gestohlen werden könnten. Es erfüllt die CISA-Richtlinien für phishing-resistente Multi-Faktor-Authentifizierung und entspricht den PCI-DSS-Anforderungen für starke Authentifizierung in Netzwerken, die Karteninhaberdaten verarbeiten. Es ist die von IEEE 802.1X empfohlene Authentifizierungsmethode für verwaltete Geräteflotten.
Cloud-First-802.1X-Authentifizierungsarchitektur: Geräte authentifizieren sich über EAP-TLS über den Cloud-RADIUS von Purple, der Zertifikate validiert und gruppenbasierte Richtlinien von Entra ID, Okta oder Google Workspace anwendet.
Wie MDM die lokale CA ersetzt
In einer traditionellen 802.1X-Bereitstellung wurden Zertifikate von einer lokalen Zertifizierungsstelle ausgestellt, auf der Active Directory Certificate Services (AD CS) lief. In einer Cloud-First-Bereitstellung übernimmt das MDM diese Rolle mithilfe von SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro und andere MDM-Plattformen können Zertifikate von einer in der Cloud gehosteten CA anfordern und diese geräuschlos auf verwaltete Geräte übertragen.
Der Ablauf sieht wie folgt aus: Der IT-Administrator erstellt im MDM ein SCEP-Zertifikatsprofil, das auf die Gerätegruppen ausgerichtet ist, die WiFi-Zugriff benötigen. Das MDM pusht das Zertifikat automatisch auf Windows-, macOS-, iOS-, iPadOS-, Android Enterprise- und ChromeOS-Geräte. Der Benutzer bemerkt davon nichts. Das Zertifikat ist an die Geräteidentität im MDM gebunden und verlängert sich vor dem Ablauf automatisch. Wenn sich das Gerät mit dem WiFi verbindet, legt es das Zertifikat dem Cloud-RADIUS-Server vor. Dieser validiert es anhand der CA und wendet die entsprechende Netzwerkrichtlinie an.
Für Unternehmen, die Microsoft Intune nutzen, bietet Microsoft Cloud PKI eine vollständig verwaltete CA, die sich direkt in Intune-SCEP-Profile integrieren lässt. Dadurch wird ein lokaler NDES-Server (Network Device Enrollment Service) überflüssig. Für von Jamf verwaltete Mac- und iOS-Flotten erfüllt die integrierte CA von Jamf oder eine Cloud-CA eines Drittanbieters denselben Zweck.
SCIM und sofortiger Entzug von Zugriffsrechten
Einer der betrieblich wichtigsten Aspekte von Cloud-RADIUS ist das SCIM-Provisioning (System for Cross-domain Identity Management). SCIM is ein offener Standard, der Identitätsänderungen in Echtzeit von der Single Source of Truth – Ihrem Cloud-Identity-Provider – an abhängige Systeme überträgt. Wenn ein Mitarbeiter in Entra ID oder Okta deaktiviert wird, überträgt SCIM diese Änderung sofort an den Cloud-RADIUS-Dienst. Beim nächsten Authentifizierungsversuch des Geräts gibt der RADIUS-Server ein Access-Reject zurück. Wenn auf dem Access Point ein kurzes Sitzungs-Timeout konfiguriert ist, wird das Gerät innerhalb weniger Minuten nach der Deaktivierung des Kontos aus dem Netzwerk entfernt.
Dies ist eine erhebliche Sicherheitsverbesserung gegenüber Netzwerken mit gemeinsam genutzten PSKs (wo der Zugriff nur durch Ändern des Passworts auf allen Geräten entzogen werden kann) und gegenüber älteren RADIUS-Bereitstellungen, die auf periodischen LDAP-Synchronisierungen mit einem Zeitfenster von Stunden oder Tagen basieren.
RadSec: Sicherung des RADIUS-Verkehrs über das Internet
Klassisches RADIUS verwendet UDP und bietet nur eine grundlegende Nachrichtenauthentifizierung. Wenn sich Ihr RADIUS-Server im selben Rechenzentrum wie Ihre Access Points befindet, ist das akzeptabel. Wenn Ihr RADIUS-Server jedoch ein Cloud-Dienst ist, läuft der Authentifizierungsverkehr über das öffentliche Internet. RadSec (RADIUS over TLS, RFC 6614) verschlüsselt den RADIUS-Austausch mittels TLS und sorgt so für Vertraulichkeit und Integrität des Authentifizierungsverkehrs. Purple unterstützt RadSec nativ, mit einem IPsec-Fallback für Access Points, die RadSec noch nicht unterstützen.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.
Implementierungsleitfaden
Die Bereitstellung von Cloud-RADIUS mit EAP-TLS erfordert vier koordinierte Schritte. Eine Pilot-SSID kann in weniger als einer Stunde live gehen, wenn Entra ID und ein MDM bereits vorhanden sind.
Schritt 1: Cloud-RADIUS mit Ihrem Identity-Provider verbinden
Verbinden Sie Purple über die OAuth2-Admin-Zustimmung (für Entra ID) oder ein API-Token (für Okta und Google Workspace) mit Ihrem Identity-Provider. Dies autorisiert Purple, Benutzer, Gruppen und Gruppenmitgliedschaften aus dem Verzeichnis auszulesen. Konfigurieren Sie das SCIM-Provisioning, um Änderungen des Benutzerstatus in Echtzeit an Purple zu übertragen. Es werden keine Anmeldedaten von Dienstprinzipalen auf der Festplatte gespeichert. Gruppenänderungen werden beim nächsten Authentifizierungsereignis wirksam, nicht nach einem festen Synchronisierungszeitplan.
Schritt 2: MDM und SCEP-Profil konfigurieren
Erstellen Sie in Microsoft Intune ein Profil für vertrauenswürdige Zertifikate für den CA-Root und anschließend ein SCEP-Zertifikatsprofil, das auf die von Purple verwaltete CA verweist. Richten Sie beide Profile auf die Gerätegruppen aus, die WiFi-Zugriff benötigen. Konfigurieren Sie für Jamf eine SCEP-Payload in einem Konfigurationsprofil. Das MDM pusht die Zertifikate geräuschlos. Überprüfen Sie die Zertifikatsbereitstellung im MDM-Compliance-Dashboard, bevor Sie fortfahren.
Schritt 3: Netzwerkrichtlinien im Cloud-RADIUS-Dashboard definieren
Erstellen Sie RADIUS-Richtlinien, die Gruppen des Identity-Providers bestimmten VLANs und Zugriffskontrollen zuweisen. Weisen Sie beispielsweise der Entra ID-Gruppe „Staff-Finance“ das VLAN 20 mit vollem Internetzugriff zu und der Gruppe „Staff-Contractors“ das VLAN 30 mit zeitlich begrenztem Zugriff, der automatisch abläuft. Das Dashboard von Purple wendet diese Richtlinien direkt beim Authentifizierungsvorgang an, ohne dass Änderungen an der Firewall erforderlich sind.
Schritt 4: Access-Point-Konfiguration aktualisieren
Aktualisieren Sie die SSID-Konfiguration auf Ihren Access Points, um WPA2-Enterprise oder WPA3-Enterprise mit 802.1X zu verwenden. Geben Sie die Hostnamen oder IP-Adressen der primären und sekundären Cloud-RADIUS-Endpunkte von Purple zusammen mit dem Shared Secret ein. Konfigurieren Sie die Access Points so, dass sie eine dynamische VLAN-Zuweisung basierend auf den von Purple zurückgegebenen RADIUS-Attributen nutzen. Testen Sie dies mit einer einzelnen SSID auf einer Auswahl von Access Points, bevor Sie den Rollout für den gesamten Standort durchführen.
Cloud-RADIUS vs. lokaler RADIUS: Ein direkter Vergleich in Bezug auf Bereitstellungszeit, Active Directory-Abhängigkeit, Hochverfügbarkeit, OS-Patching, Identitätsintegration und Zertifikats-Lebenszyklusmanagement.
Best Practices
Diese Empfehlungen spiegeln die IEEE-802.1X-Standards, die PCI-DSS-v4.0-Anforderungen und die Betriebserfahrung an den über 80.000 Standorten von Purple wider.
Schreiben Sie EAP-TLS für verwaltete Geräte vor. Passwörter sind anfällig für Phishing und Credential Stuffing. Zertifikate bieten einen kryptografischen Identitäts- und Geräte-Compliance-Nachweis. EAP-TLS ist die einzige 802.1X-Methode, die von Haus aus phishing-resistent ist.
Nutzen Sie SCIM für den sofortigen Entzug von Zugriffsrechten. Periodische LDAP-Synchronisierungen lassen ein Zeitfenster offen, in dem ein ausgeschiedener Mitarbeiter weiterhin Netzwerkzugriff hat. SCIM stellt sicher, dass der Zugriff in dem Moment entzogen wird, in dem das Konto im Identity-Provider deaktiviert wird.
Stellen Sie Multi-Region-RADIUS bereit. Konfigurieren Sie Ihre Access Points mit mindestens zwei RADIUS-Endpunkten in verschiedenen geografischen Regionen. Purple bietet standardmäßig ein Active-Active-Multi-Region-Failover, das in Sekundenschnelle umschaltet.
Segmentieren Sie den Datenverkehr mit dynamischen VLANs. Nutzen Sie die Gruppenmitgliedschaften des Identity-Providers, um Benutzer dynamisch bestimmten VLANs zuzuweisen. Dies isoliert sensiblen Datenverkehr und begrenzt das Schadensausmaß eines kompromittierten Geräts, ohne dass manuelle Änderungen an der Firewall erforderlich sind.
Aktivieren Sie RadSec. Wenn Ihre Access Points RadSec unterstützen, aktivieren Sie es, um den Authentifizierungsverkehr zwischen dem Access Point und dem Cloud-RADIUS-Server zu verschlüsseln. Dies ist besonders wichtig für Filialen und Standorte, an denen sich der Access Point in einem nicht vertrauenswürdigen Netzwerksegment befindet.
Überwachen Sie den Zertifikats-Lebenszyklus. Stellen Sie die automatische MDM-Verlängerung so ein, dass sie bei 80 % der Zertifikatslaufzeit ausgelöst wird. Bei einem einjährigen Zertifikat beginnt die Verlängerung nach 10 Monaten. Richten Sie Warnmeldungen für Geräte ein, bei denen die Verlängerung vor Ablauf des Zertifikats fehlschlägt.
Für eine umfassendere Betrachtung von Sicherheitsstandards und Frameworks für Enterprise-WiFi lesen Sie unseren Leitfaden Enterprise WiFi Security: A Complete Guide for 2026 .
Fehlerbehebung und Risikominimierung
Der Übergang zu Cloud-RADIUS bringt neue Abhängigkeiten mit sich. Bereiten Sie sich auf diese häufigen Fehlerszenarien vor, bevor sie den Produktivbetrieb beeinträchtigen.
Ablauf von Zertifikaten. Wenn ein Gerätezertifikat abläuft, bevor das MDM es verlängert, schlägt die Authentifizierung des Geräts geräuschlos fehl. Der Benutzer sieht eine Fehlermeldung ohne Erklärung. Beugen Sie dem vor, indem Sie die automatische MDM-Verlängerung auf 80 % der Zertifikatslaufzeit einstellen und das MDM-Compliance-Dashboard auf Geräte mit bald ablaufenden Zertifikaten überwachen.
MDM-Synchronisierungsfehler. Ein Gerät, das die MDM-Compliance-Richtlinien nicht mehr erfüllt oder sich nicht meldet, erhält möglicherweise kein verlängertes Zertifikat. Implementieren Sie Compliance-Richtlinien, die fehlerhafte Geräte kennzeichnen und Administratoren warnen, bevor das Zertifikat abläuft.
Firewall blockiert RADIUS-Verkehr. Die Access Points müssen die Cloud-RADIUS-Endpunkte über den UDP-Port 1812 (Authentifizierung) und den UDP-Port 1813 (Accounting) oder über den TCP-Port 2083 für RadSec erreichen können. Ausgehende Firewall-Regeln in Filialen blockieren diese Ports häufig. Testen Sie die Erreichbarkeit aus dem Management-VLAN des Access Points vor der Bereitstellung.
SCIM-Provisionierungsfehler. Wenn die SCIM-Verbindung zwischen dem Identity-Provider und Purple unterbrochen wird, werden Änderungen des Benutzerstatus nicht übertragen. Überwachen Sie den SCIM-Synchronisierungsstatus sowohl im Identity-Provider als auch im Purple-Dashboard. Richten Sie Warnmeldungen für Synchronisierungsfehler ein.
Altsysteme ohne Zertifikatsunterstützung. IoT-Geräte, Drucker und ältere Hardware unterstützen EAP-TLS möglicherweise nicht. Verwenden Sie für diese Geräte iPSK (individual pre-shared keys) anstelle eines gemeinsam genutzten PSK. Purple unterstützt iPSK nativ, weist jedem Gerät einen eindeutigen Schlüssel zu und platziert jedes Gerät im richtigen VLAN, ohne dass eine 802.1X-Supplicant-Unterstützung erforderlich ist.
ROI und geschäftliche Auswirkungen
Die migration von lokalem RADIUS zu Cloud-RADIUS bietet messbaren Mehrwert für Infrastruktur, Betrieb und Sicherheit.
| Dimension | Lokaler NPS | Cloud-RADIUS (Purple) |
|---|---|---|
| Infrastrukturkosten | Windows Server-Lizenzen, VM-Rechenleistung, Speicher | Abonnement pro AP, keine Server-Hardware |
| Bereitstellungszeit | Tage bis Wochen | Unter einer Stunde |
| Hochverfügbarkeit | Manuell – zwei Server plus Replikation | Multi-Region Active-Active, Standard |
| OS-Patching | Monatlich, durch Ihr Team | Vom Anbieter verwaltet |
| WiFi-Helpdesk-Tickets | Hoch – Passwort-Resets, manuelles Onboarding | Um 80 % reduziert (Kundendaten von Purple) |
| Entzug von Zugriffsrechten | Stunden bis Tage via LDAP-Sync | Sekunden via SCIM |
IT-Teams, die das Mitarbeiter-WiFi von Purple nutzen, verzeichnen in der Regel einen Rückgang der WiFi-Support-Tickets um 80 % (interne Daten von Purple, 2024), was auf den Wegfall von Passwort-Resets und manuellem Geräte-Onboarding zurückzuführen ist. Die zertifikatsbasierte Authentifizierung erfüllt zudem die PCI-DSS-Anforderung 8.3 für starke Authentifizierung und die ISO 27001-Maßnahme A.9.4 für die System- und Anwendungszugriffskontrolle, was den Audit-Aufwand für Ihr Sicherheitsteam verringert.
Für Unternehmen in den Bereichen Einzelhandel und Gastgewerbe reduziert die Möglichkeit, Mitarbeiter-WiFi und Gäste-WiFi über ein einziges Cloud-Dashboard mit einer einheitlichen Identitätsebene zu verwalten, die betriebliche Komplexität an mehreren Standorten. Für Transportunternehmen und Gesundheitsdienstleister erfüllen der sofortige Entzug von Zugriffsrechten und der vollständige Audit-Trail regulatorische Anforderungen ohne zusätzliche Tools.
Die WiFi Analytics -Ebene von Purple ergänzt die Authentifizierungsinfrastruktur um Belegungsdaten und Daten zum hybriden Arbeiten. So wird das Mitarbeiter-WiFi von einer Kostenstelle zu einer Quelle für betriebliche Erkenntnisse.
Weiterführende Literatur: Enterprise WiFi Security: A Complete Guide for 2026 – OpenWrt Custom Firmware Integration with Purple WiFi
Definizioni chiave
802.1X
Uno standard IEEE (IEEE 802.1X-2020) per il controllo dell'accesso alla rete basato su porte. Richiede che i dispositivi si autentichino prima che l'access point conceda l'accesso alla rete, utilizzando uno scambio EAP mediato da un server RADIUS.
I team IT utilizzano l'802.1X per garantire che solo gli utenti e i dispositivi autorizzati si connettano alla rete aziendale. Fornisce crittografia per singolo utente, chiavi per singola sessione e un audit trail completo di ogni evento di connessione.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Un protocollo di rete che fornisce una gestione centralizzata di Authentication, Authorization, and Accounting (AAA) per l'accesso alla rete.
Gli access point inoltrano ogni richiesta di connessione al server RADIUS, che decide se ammettere il dispositivo e a quale VLAN assegnarlo. Cloud RADIUS sostituisce i server NPS o FreeRADIUS on-premises.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Un metodo di autenticazione 802.1X che utilizza uno scambio reciproco di certificati X.509 al posto delle password.
EAP-TLS rappresenta il gold standard per le flotte di dispositivi gestiti. È resistente al phishing, non richiede un archivio di hash delle password ed è l'unico metodo 802.1X che soddisfa le linee guida CISA per l'MFA resistente al phishing.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol con Microsoft Challenge Handshake Authentication Protocol versione 2. Un metodo legacy 802.1X che convalida le password confrontandole con gli hash NTLM memorizzati in Active Directory.
PEAP-MSCHAPv2 non funziona in ambienti esclusivamente cloud perché Entra ID non memorizza gli hash NTLM. Le organizzazioni che migrano da AD on-premises devono sostituire PEAP con EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Un protocollo utilizzato dalle piattaforme MDM per richiedere e installare automaticamente certificati digitali sui dispositivi, senza alcuna interazione da parte dell'utente.
I team IT utilizzano SCEP con Intune o Jamf per distribuire in modo silenzioso i certificati WiFi ai dispositivi dei dipendenti. SCEP sostituisce il server NDES (Network Device Enrollment Service) on-premises nelle distribuzioni cloud-first.
SCIM
System for Cross-domain Identity Management (RFC 7644). Uno standard aperto che automatizza lo scambio in tempo reale di informazioni sull'identità degli utenti tra i sistemi IT.
SCIM garantisce che quando un dipendente viene disabilitato in Entra ID o Okta, tale modifica venga inviata immediatamente al servizio cloud RADIUS, revocando l'accesso WiFi nel giro di pochi secondi anziché di ore.
NPS
Network Policy Server. L'implementazione RADIUS di Microsoft, solitamente eseguita su Windows Server come parte di un ambiente Active Directory on-premises.
Le organizzazioni cloud-first stanno dismettendo NPS per eliminare le VM Windows Server, l'applicazione delle patch del sistema operativo e la dipendenza da Active Directory on-premises. Cloud RADIUS è il sostituto diretto.
RadSec
RADIUS over TLS (RFC 6614). Un protocollo che crittografa il traffico di autenticazione RADIUS utilizzando TLS, sostituendo il trasporto in chiaro basato su UDP utilizzato dal RADIUS tradizionale.
RadSec è essenziale quando si utilizza il cloud RADIUS, poiché il traffico di autenticazione deve attraversare l'internet pubblica tra l'access point e il servizio cloud. Purple supporta RadSec nativamente.
iPSK
Individual Pre-Shared Key. Una variante di WPA2-Personal che assegna una chiave precondivisa univoca a ciascun dispositivo, anziché un'unica chiave condivisa per tutti i dispositivi.
L'iPSK viene utilizzato per i dispositivi IoT, le stampanti e altri componenti hardware che non supportano l'802.1X EAP-TLS. Fornisce tracciabilità per singolo dispositivo e assegnazione della VLAN senza richiedere il supporto dei certificati.
Dynamic VLAN
Una tecnica di segmentazione della rete in cui il server RADIUS restituisce un identificatore VLAN nella risposta Access-Accept e l'access point inserisce automaticamente il dispositivo in quella VLAN.
Le VLAN dinamiche consentono ai team IT di segmentare il personale, i collaboratori esterni, i dispositivi IoT e gli ospiti in segmenti di rete separati in base all'appartenenza ai gruppi dell'identity provider, senza modifiche manuali al firewall.
Esempi pratici
Una catena di vendita al dettaglio con 400 punti vendita deve proteggere il WiFi del personale in tutte le sedi. Utilizza access point Cisco Meraki e Microsoft Entra ID con Intune per la gestione dei dispositivi. Attualmente utilizza una chiave PSK WPA2-Personal condivisa perché non dispone di un Active Directory on-premises per eseguire NPS. Un recente audit interno ha segnalato la PSK condivisa come una lacuna di conformità PCI DSS.
La catena implementa il cloud RADIUS di Purple. Innanzitutto, collega Purple a Entra ID tramite il consenso amministratore OAuth e configura il provisioning SCIM. In Intune, crea un Profilo certificato attendibile per la CA root di Purple e un profilo certificato SCEP associato al gruppo di dispositivi "Staff-Retail". Intune distribuisce silenziosamente i certificati a tutti i terminali POS gestiti e ai tablet del personale. Nella dashboard Meraki, aggiorna l'SSID del personale a WPA2-Enterprise, inserisce gli endpoint primario e secondario del cloud RADIUS di Purple e abilita l'assegnazione dinamica della VLAN. Quando un dispositivo si connette, presenta il certificato emesso da Intune, Purple lo convalida rispetto alla CA e controlla il gruppo Entra ID, e il dispositivo viene inserito nella VLAN 10 (rete del personale) o nella VLAN 20 (rete di gestione) in base all'appartenenza al gruppo. La PSK condivisa viene dismessa. Il roll-out su 400 siti richiede un solo fine settimana, poiché non viene distribuito alcun hardware in loco, ma solo modifiche alla configurazione dell'SSID in Meraki.
Un'università con 15.000 studenti utilizza Google Workspace come provider di identità principale. Il team IT desidera fornire un WiFi sicuro per il personale e gli studenti su un parco dispositivi BYOD composto da MacBook, Chromebook e telefoni Android. Non hanno un Active Directory on-premises e non hanno intenzione di gestire server.
L'università integra il cloud RADIUS di Purple con Google Workspace. Per i Chromebook gestiti, utilizza Google Admin per distribuire un profilo di certificato WiFi tramite SCEP, registrando silenziosamente ogni dispositivo. Per i MacBook e i telefoni Android BYOD, distribuisce un'applicazione di onboarding leggera che autentica l'utente con le sue credenziali Google e installa un certificato sul dispositivo con un solo tocco. Le connessioni successive utilizzano EAP-TLS in modo silenzioso. Purple mappa le unità organizzative di Google Workspace sulle VLAN: il personale atterra sulla VLAN 10, gli studenti sulla VLAN 20 e i visitatori ospiti su un SSID con Captive Portal. Quando uno studente si laurea e il suo account Google viene sospeso, SCIM invia la modifica a Purple e il suo accesso WiFi viene revocato nel giro di pochi minuti.
Domande di esercitazione
Q1. La tua organizzazione è migrata completamente da Active Directory on-premises a Microsoft Entra ID. La tua attuale WiFi per il personale utilizza PEAP-MSCHAPv2 tramite un server NPS associato al vecchio dominio. Dopo la disattivazione del controller di dominio, il personale segnala di non riuscire più a connettersi alla WiFi. Qual è la causa principale e quale la corretta soluzione a lungo termine?
Suggerimento: Considera ciò che PEAP-MSCHAPv2 richiede alla directory e se Entra ID lo fornisce.
Visualizza risposta modello
La causa principale è che PEAP-MSCHAPv2 richiede al server RADIUS di convalidare la password dell'utente rispetto a un hash NTLM memorizzato in Active Directory. Con il controller di dominio disattivato, NPS non ha una directory con cui effettuare la convalida. Entra ID non memorizza gli hash NTLM, quindi NPS non può essere reindirizzato a Entra ID. La soluzione corretta a lungo termine consiste nel sostituire NPS con un servizio cloud RADIUS, migrare da PEAP-MSCHAPv2 a EAP-TLS e utilizzare l'MDM (Intune) per emettere certificati di dispositivo tramite SCEP. Questo elimina la dipendenza da qualsiasi directory on-premises.
Q2. Stai distribuendo il cloud RADIUS per una flotta di 200 MacBook aziendali gestiti da Jamf Pro. Il tuo identity provider è Okta. Qual è il modo più sicuro ed efficiente dal punto di vista operativo per fornire le credenziali WiFi a questi dispositivi?
Suggerimento: Cerca un metodo che non richieda alcuna interazione da parte dell'utente, eviti le password e si integri con il tuo MDM esistente.
Visualizza risposta modello
Configura Jamf Pro per utilizzare SCEP per inviare in modo invisibile i certificati di dispositivo ai MacBook. Crea un payload SCEP in un profilo di configurazione Jamf, puntando alla CA gestita dal tuo provider cloud RADIUS. Associa il profilo al gruppo di dispositivi pertinente. Jamf invierà automaticamente il certificato a ciascun MacBook, senza alcuna interazione da parte dell'utente. Configura il profilo WiFi nello stesso profilo di configurazione per utilizzare EAP-TLS con il certificato emesso tramite SCEP. Connetti il servizio cloud RADIUS a Okta tramite SCIM per garantire che, quando un dipendente viene disattivato in Okta, il suo accesso alla WiFi venga revocato immediatamente.
Q3. Un dipendente viene licenziato alle 9:00 di lunedì. Il suo account Entra ID viene disattivato dalle Risorse Umane alle 9:05. Alle 9:30, un avviso di sicurezza mostra che il laptop del dipendente è ancora connesso alla WiFi aziendale dal parcheggio. Quale configurazione manca e come si risolve il problema?
Suggerimento: In che modo il server RADIUS viene a conoscenza del fatto che lo stato dell'utente è cambiato nell'identity provider?
Visualizza risposta modello
La distribuzione si affida a sincronizzazioni LDAP periodiche anziché al provisioning SCIM. La sincronizzazione LDAP non è ancora stata eseguita da quando l'account è stato disattivato, quindi il servizio cloud RADIUS considera l'utente ancora attivo. La soluzione consiste nell'abilitare il provisioning SCIM tra Entra ID e il servizio cloud RADIUS. SCIM invia le modifiche dello stato dell'utente in tempo reale, quindi quando l'account viene disattivato in Entra ID alle 9:05, il servizio RADIUS riceve immediatamente la modifica. Al successivo tentativo di riautenticazione del dispositivo (controllato dal timeout di sessione sull'access point), questo riceverà un Access-Reject. L'impostazione di un timeout di sessione breve (da 15 a 30 minuti) sull'access point limita la finestra temporale massima tra la disattivazione dell'account e l'espulsione dalla rete.
Q4. La tua sede ha 50 dispositivi IoT (lettori di segnaletica digitale, sensori ambientali e stampanti) che non supportano 802.1X EAP-TLS. Come puoi proteggere questi dispositivi sulla stessa infrastruttura WiFi della rete del personale EAP-TLS?
Suggerimento: Considera quale metodo di autenticazione fornisce una responsabilità per singolo dispositivo senza richiedere il supporto dei certificati.
Visualizza risposta modello
Utilizza iPSK (chiavi pre-condivise individuali) per i dispositivi IoT. Assegna una chiave pre-condivisa univoca a ciascun dispositivo nella dashboard del cloud RADIUS, insieme a un'assegnazione VLAN. Ciascun dispositivo si autentica con la sua chiave univoca, che il server RADIUS convalida e utilizza per collocare il dispositivo nella VLAN IoT, isolata dalla rete del personale. Se un dispositivo viene compromesso o disattivato, revochi solo la chiave di quel dispositivo senza influire su nessun altro. Questo approccio garantisce la responsabilità per singolo dispositivo e la segmentazione della rete senza richiedere il supporto del supplicant 802.1X sull'hardware IoT.
Continua a leggere questa serie
Come revocare l'accesso WiFi quando un dipendente lascia l'azienda
Questa guida mostra ai team IT e di gestione delle sedi come rimuovere l'accesso WiFi del personale quando un dipendente lascia l'azienda, senza interrompere il resto della forza lavoro. Confronta la tecnologia 802.1X basata su certificati, l'iPSK specifico per l'identità e il deprovisioning guidato da SCIM, fornendo poi un runbook per il giorno stesso, un metodo di test e un modello di evidenza di audit.
WiFi BYOD sicuro: onboarding con certificati Passpoint vs xPSK (iPSK)
Una guida tecnica completa per i team IT su come proteggere i dispositivi non gestiti di dipendenti e studenti (BYOD) utilizzando certificati Passpoint EAP-TLS zero-touch rispetto a soluzioni xPSK specifiche del fornitore (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual è la differenza e quale dovresti usare?
Questa guida di riferimento tecnica fornisce un confronto autorevole tra gli standard di sicurezza wireless WPA2 Personal e WPA2 Enterprise. Dettaglia gli handshake crittografici sottostanti, i requisiti architetturali e le metodologie di implementazione necessarie ai leader IT per proteggere le reti aziendali. I lettori impareranno come passare da passphrase condivise a un'autenticazione individualizzata e basata su certificati per allinearsi ai framework di conformità e mitigare le minacce interne.
Hai domande sulla tua configurazione specifica?
Il nostro team collabora con gestori di sedi, responsabili IT e ingegneri di rete in 80.000 sedi. Prenota una chiamata di 20 minuti e ti mostreremo come altri professionisti come te hanno risolto il problema.