Autenticação WiFi empresarial sem Active Directory ou servidor local
Este guia explica como implementar a autenticação WiFi WPA2/3-Enterprise segura sem um Active Directory local, Windows NPS ou servidor RADIUS. Abrange a incompatibilidade de protocolos entre fornecedores de identidade na nuvem e 802.1X, as vantagens do EAP-TLS face ao PEAP-MSCHAPv2 e como implementar o RADIUS na nuvem com certificados emitidos por MDM em conformidade com o Microsoft Entra ID, Okta ou Google Workspace. Escrito para responsáveis de TI em organizações focadas na nuvem e com forte presença de Mac/Chromebook que pretendem descontinuar a infraestrutura local.
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: 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.
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.
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
Definições Principais
802.1X
Uma norma IEEE (IEEE 802.1X-2020) para controlo de acesso à rede baseado em portas. Exige que os dispositivos se autentiquem antes de o ponto de acesso conceder acesso à rede, utilizando uma troca EAP mediada por um servidor RADIUS.
As equipas de TI utilizam o 802.1X para garantir que apenas utilizadores e dispositivos autorizados se ligam à rede corporativa. Este fornece encriptação por utilizador, chaves por sessão e um registo de auditoria completo de cada evento de ligação.
RADIUS
Remote Authentication Dial-In User Service (RFC 2865). Um protocolo de rede que fornece gestão centralizada de Autenticação, Autorização e Contabilização (AAA) para acesso à rede.
Os pontos de acesso encaminham todos os pedidos de ligação para o servidor RADIUS, que decide se admite o dispositivo e qual a VLAN a atribuir-lhe. O Cloud RADIUS substitui os servidores NPS ou FreeRADIUS locais.
EAP-TLS
Extensible Authentication Protocol-Transport Layer Security (RFC 5216). Um método de autenticação 802.1X que utiliza a troca mútua de certificados X.509 em vez de palavras-passe.
O EAP-TLS é o padrão de excelência para frotas de dispositivos geridos. É resistente a phishing, não requer armazenamento de hashes de palavras-passe e é o único método 802.1X que cumpre as orientações de MFA resistente a phishing da CISA.
PEAP-MSCHAPv2
Protected Extensible Authentication Protocol com Microsoft Challenge Handshake Authentication Protocol versão 2. Um método 802.1X legado que valida palavras-passe contra hashes NTLM armazenados no Active Directory.
O PEAP-MSCHAPv2 falha em ambientes exclusivamente na nuvem porque o Entra ID não armazena hashes NTLM. As organizações que estão a migrar do AD local devem substituir o PEAP pelo EAP-TLS.
SCEP
Simple Certificate Enrollment Protocol. Um protocolo utilizado por plataformas MDM para solicitar e instalar automaticamente certificados digitais em dispositivos, sem interação do utilizador.
As equipas de TI utilizam o SCEP com o Intune ou o Jamf para aprovisionar silenciosamente certificados WiFi em dispositivos de colaboradores. O SCEP substitui o servidor NDES (Network Device Enrollment Service) local em implementações prioritariamente na nuvem.
SCIM
System for Cross-domain Identity Management (RFC 7644). Uma norma aberta que automatiza a troca em tempo real de informações de identidade de utilizadores entre sistemas de TI.
O SCIM garante que, quando um colaborador é desativado no Entra ID ou Okta, essa alteração é enviada imediatamente para o serviço Cloud RADIUS, revogando o acesso WiFi em segundos em vez de horas.
NPS
Network Policy Server. A implementação de RADIUS da Microsoft, normalmente executada em Windows Server como parte de um ambiente Active Directory local.
As organizações focadas na nuvem estão a descontinuar o NPS para eliminar VMs de Windows Server, atualizações de SO e a dependência do Active Directory local. O Cloud RADIUS é a substituição direta.
RadSec
RADIUS sobre TLS (RFC 6614). Um protocolo que encripta o tráfego de autenticação RADIUS utilizando TLS, substituindo o transporte de texto simples baseado em UDP utilizado pelo RADIUS tradicional.
O RadSec é essencial ao utilizar o Cloud RADIUS, uma vez que o tráfego de autenticação deve atravessar a internet pública entre o ponto de acesso e o serviço de nuvem. O Purple suporta RadSec nativamente.
iPSK
Individual Pre-Shared Key. Uma variante do WPA2-Personal que atribui uma chave pré-partilhada única a cada dispositivo, em vez de uma única chave partilhada para todos os dispositivos.
O iPSK é utilizado para dispositivos IoT, impressoras e outro hardware que não suporta 802.1X EAP-TLS. Fornece responsabilização por dispositivo e atribuição de VLAN sem necessitar de suporte para certificados.
Dynamic VLAN
Uma técnica de segmentação de rede onde o servidor RADIUS devolve um identificador de VLAN na resposta Access-Accept, e o ponto de acesso coloca o dispositivo nessa VLAN automaticamente.
As VLANs dinâmicas permitem que as equipas de TI segmentem funcionários, prestadores de serviços, dispositivos IoT e convidados em segmentos de rede separados com base na pertença a grupos do fornecedor de identidade, sem alterações manuais na firewall.
Exemplos Práticos
Uma cadeia de retalho com 400 lojas precisa de proteger o WiFi dos funcionários em todas as localizações. Utilizam pontos de acesso Cisco Meraki e o Microsoft Entra ID com o Intune para a gestão de dispositivos. Atualmente, utilizam uma PSK WPA2-Personal partilhada porque não têm Active Directory local para executar o NPS. Uma auditoria interna recente sinalizou a PSK partilhada como uma falha de conformidade com a norma PCI DSS.
A cadeia de retalho implementa o RADIUS na nuvem da Purple. Primeiro, ligam a Purple ao Entra ID através do consentimento de administrador OAuth e configuram o aprovisionamento SCIM. No Intune, criam um Perfil de Certificado Fidedigno para a AC raiz da Purple e um perfil de certificado SCEP direcionado ao grupo de dispositivos 'Staff-Retail'. O Intune envia silenciosamente os certificados para todos os terminais de ponto de venda geridos e tablets dos funcionários. No painel da Meraki, atualizam o SSID dos funcionários para WPA2-Enterprise, introduzem os endpoints primário e secundário do RADIUS na nuvem da Purple e ativam a atribuição dinâmica de VLAN. Quando um dispositivo se liga, apresenta o seu certificado emitido pelo Intune, a Purple valida-o face à AC e verifica o grupo do Entra ID, e o dispositivo é colocado na VLAN 10 (rede de funcionários) ou na VLAN 20 (rede de gestão) com base na pertença ao grupo. A PSK partilhada é desativada. A implementação nas 400 lojas demora um fim de semana, uma vez que não é implementado hardware local - apenas alterações de configuração de SSID na Meraki.
Uma universidade com 15.000 estudantes utiliza o Google Workspace como o seu fornecedor de identidade principal. A equipa de TI pretende fornecer WiFi seguro para funcionários e estudantes num parque de dispositivos BYOD composto por MacBooks, Chromebooks e telemóveis Android. Não têm Active Directory local nem interesse em gerir servidores.
A universidade integra o RADIUS na nuvem da Purple com o Google Workspace. Para os Chromebooks geridos, utilizam a Consola de Administração do Google para enviar um perfil de certificado WiFi via SCEP, registando silenciosamente cada dispositivo. Para os MacBooks e telemóveis Android BYOD, implementam uma aplicação de integração leve que autentica o utilizador com as suas credenciais do Google e instala um certificado no dispositivo com um único toque. As ligações subsequentes utilizam EAP-TLS de forma silenciosa. A Purple mapeia as Unidades Organizacionais do Google Workspace para VLANs: os funcionários entram na VLAN 10, os estudantes na VLAN 20 e os visitantes convidados num SSID de Captive Portal. Quando um estudante se licencia e a sua conta Google é suspensa, o SCIM envia a alteração para a Purple e o seu acesso WiFi é revogado em poucos minutos.
Perguntas de Prática
Q1. A sua organização migrou totalmente do Active Directory local para o Microsoft Entra ID. O seu WiFi de funcionários atual utiliza PEAP-MSCHAPv2 contra um servidor NPS que estava associado ao domínio antigo. Após a desativação do controlador de domínio, os funcionários relatam que já não conseguem ligar-se ao WiFi. Qual é a causa raiz e qual é a correção correta a longo prazo?
Dica: Considere o que o PEAP-MSCHAPv2 exige do diretório e se o Entra ID o fornece.
Ver resposta modelo
A causa raiz é que o PEAP-MSCHAPv2 exige que o servidor RADIUS valide a palavra-passe do utilizador contra um hash NTLM armazenado no Active Directory. Com o controlador de domínio desativado, o NPS não tem nenhum diretório contra o qual validar. O Entra ID não armazena hashes NTLM, pelo que o NPS não pode ser redirecionado para o Entra ID. A correção correta a longo prazo é substituir o NPS por um serviço de cloud RADIUS, migrar de PEAP-MSCHAPv2 para EAP-TLS e utilizar o MDM (Intune) para emitir certificados de dispositivo via SCEP. Isto elimina a dependência de qualquer diretório local.
Q2. Está a implementar o cloud RADIUS para uma frota de 200 dispositivos MacBooks corporativos geridos pelo Jamf Pro. O seu fornecedor de identidade é o Okta. Qual é a forma mais segura e operacionalmente eficiente de aprovisionar as credenciais de WiFi para estes dispositivos?
Dica: Procure um método que não exija interação do utilizador, evite palavras-passe e se integre com o seu MDM existente.
Ver resposta modelo
Configure o Jamf Pro para utilizar SCEP para enviar silenciosamente certificados de dispositivo para os MacBooks. Crie um payload SCEP num perfil de configuração do Jamf, apontando para a CA gerida pelo seu fornecedor de cloud RADIUS. Defina o âmbito do perfil para o grupo de dispositivos relevante. O Jamf enviará o certificado para cada MacBook automaticamente, sem qualquer interação do utilizador. Configure o perfil de WiFi no mesmo perfil de configuração para utilizar EAP-TLS com o certificado emitido por SCEP. Ligue o serviço de cloud RADIUS ao Okta via SCIM para garantir que, quando um funcionário for desativado no Okta, o seu acesso ao WiFi seja revogado imediatamente.
Q3. Um funcionário é despedido às 9:00 de uma segunda-feira. A sua conta do Entra ID é desativada pelos RH às 9:05. Às 9:30, um alerta de segurança mostra que o portátil do funcionário ainda está ligado ao WiFi corporativo a partir do parque de estacionamento. Que configuração está em falta e como a resolve?
Dica: Como é que o servidor RADIUS sabe que o estado do utilizador foi alterado no fornecedor de identidade?
Ver resposta modelo
A implementação está a depender de sincronizações LDAP periódicas em vez de aprovisionamento SCIM. A sincronização LDAP ainda não foi executada desde que a conta foi desativada, pelo que o serviço de cloud RADIUS ainda considera o utilizador ativo. A solução é ativar o aprovisionamento SCIM entre o Entra ID e o serviço de cloud RADIUS. O SCIM envia as alterações de estado do utilizador em tempo real, pelo que, quando a conta é desativada no Entra ID às 9:05, o serviço RADIUS recebe a alteração imediatamente. Na próxima vez que o dispositivo tentar reautenticar-se (controlado pelo tempo limite da sessão no ponto de acesso), receberá um Access-Reject. Definir um tempo limite de sessão curto (15 a 30 minutos) no ponto de acesso limita a janela máxima entre a desativação da conta e a expulsão da rede.
Q4. O seu espaço tem 50 dispositivos IoT - leitores de sinalização digital, sensores ambientais e impressoras - que não suportam 802.1X EAP-TLS. Como protege estes dispositivos na mesma infraestrutura de WiFi que a sua rede de funcionários EAP-TLS?
Dica: Considere qual o método de autenticação que fornece responsabilidade por dispositivo sem exigir suporte a certificados.
Ver resposta modelo
Utilize iPSK (chaves pré-partilhadas individuais) para os dispositivos IoT. Atribua uma chave pré-partilhada única a cada dispositivo no painel do cloud RADIUS, juntamente com uma atribuição de VLAN. Cada dispositivo autentica-se com a sua chave única, que o servidor RADIUS valida e utiliza para colocar o dispositivo na VLAN de IoT, isolada da rede de funcionários. Se um dispositivo for comprometido ou desativado, revoga apenas a chave desse dispositivo sem afetar nenhum outro. Esta abordagem fornece responsabilidade por dispositivo e segmentação de rede sem exigir suporte a suplicante 802.1X no hardware IoT.
Continue a ler esta série
Como revogar o acesso WiFi quando um funcionário sai
Este guia mostra às equipas de TI e de operações de espaços como remover o acesso WiFi da equipa quando um funcionário sai, sem perturbar o resto da força de trabalho. Compara a desprovisionação baseada em certificados 802.1X, iPSK específico de identidade e SCIM, fornecendo de seguida um manual de procedimentos para o próprio dia, um método de teste e um modelo de provas de auditoria.
Secure BYOD WiFi: Integração de certificados Passpoint vs xPSK (iPSK)
Um guia técnico abrangente para equipas de TI sobre como proteger dispositivos não geridos de funcionários e estudantes (BYOD) utilizando certificados Passpoint EAP-TLS com configuração automática (zero-touch) vs xPSK específicos do fabricante (iPSK/easyPSK, DPSK, PPSK, MPSK).
WPA2 Personal vs Enterprise: qual é a diferença e qual deve utilizar?
Este guia de referência técnica fornece uma comparação autoritária entre os padrões de segurança sem fios WPA2 Personal e WPA2 Enterprise. Detalha os handshakes criptográficos subjacentes, os requisitos de arquitetura e as metodologias de implementação necessárias para que os líderes de TI protejam as redes empresariais. Os leitores aprenderão a transitar de palavras-passe partilhadas para uma autenticação individualizada, baseada em certificados, para se alinharem com os quadros de conformidade e mitigarem ameaças internas.
Tem dúvidas sobre a sua configuração específica?
A nossa equipa trabalha com operadores de espaços, gestores de TI e engenheiros de rede em 80.000 espaços. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua área o resolveram.