Autenticação WiFi com Azure AD e Entra ID: Guia de Integração e Configuração
Este guia de referência técnica fornece aos gerentes de TI, arquitetos de rede e diretores de operações de locais um roteiro prático para integrar o Microsoft Entra ID (Azure AD) com redes WiFi corporativas usando RADIUS e 802.1X. Ele abrange a decisão arquitetônica entre o Windows NPS on-premise e o RADIUS nativo da nuvem, a implementação da autenticação EAP-TLS baseada em certificado via Microsoft Intune e as melhores práticas operacionais para proteger o acesso sem fio em ambientes de hospitalidade, varejo e setor público. Para organizações que já investem no ecossistema Microsoft 365 e Entra ID, este guia preenche a lacuna entre a gestão de identidade na nuvem e a segurança da rede física.
Resumo Executivo
Para empresas modernas fortemente investidas no ecossistema Microsoft, conectar a infraestrutura de identidade na nuvem com redes sem fio físicas é um imperativo de segurança crítico. Historicamente, a autenticação WiFi dependia do Active Directory Domain Services (AD DS) on-premise e do Windows Network Policy Server (NPS). No entanto, à medida que as organizações migram para o Microsoft Entra ID (anteriormente Azure AD) e adotam modelos de segurança zero-trust, a abordagem tradicional de autenticação baseada em credenciais — PEAP-MSCHAPv2 — não é mais suficiente ou segura.
Este guia fornece aos gerentes de TI, arquitetos de rede e diretores de operações de locais um roteiro prático para implementar a autenticação WiFi do Azure AD. Exploramos as diferenças arquitetônicas entre manter uma infraestrutura NPS on-premise e migrar para uma solução RADIUS nativa da nuvem. Crucialmente, detalhamos como aproveitar o Microsoft Intune para autenticação baseada em certificado (EAP-TLS), o que elimina vulnerabilidades relacionadas a senhas e proporciona uma experiência contínua e sem atritos para os usuários finais. Quer você esteja gerenciando um hotel de 500 quartos, uma rede de varejo ou uma grande implantação no setor público, este guia ajudará você a proteger sua borda sem fio usando seus investimentos existentes em identidade Microsoft. Para uma discussão mais ampla sobre modelos de implantação, consulte nosso Guia de Decisão Cloud RADIUS vs On-Premise RADIUS para Equipes de TI .
Aprofundamento Técnico: Arquitetura e Padrões
A base do WiFi corporativo seguro é o padrão IEEE 802.1X, que fornece controle de acesso à rede baseado em porta. Em um ambiente centrado na Microsoft, a integração do 802.1X com o Entra ID requer um planejamento arquitetônico cuidadoso em três camadas: a infraestrutura sem fio, o servidor de autenticação e o diretório de identidade.
O Papel do RADIUS e 802.1X
Quando um dispositivo cliente (o suplicante) tenta se conectar a uma rede WPA2/WPA3-Enterprise, o Ponto de Acesso Sem Fio (o autenticador) bloqueia todo o tráfego, exceto os pacotes EAP (Extensible Authentication Protocol). O ponto de acesso encaminha esses pacotes para um servidor RADIUS. O servidor RADIUS valida a identidade do usuário ou dispositivo em um serviço de diretório e retorna uma mensagem Access-Accept ou Access-Reject. Este modelo de três partes — suplicante, autenticador, servidor de autenticação — é a pedra angular da segurança sem fio corporativa e é descrito em detalhes em nossa Definição de Pontos de Acesso Sem Fio: Seu Guia Definitivo para 2026 .
Abordagens Arquitetônicas para Ambientes Microsoft
Existem duas arquiteturas principais para integrar a identidade Microsoft com a autenticação WiFi, cada uma com compensações distintas:
| Dimensão | On-Premise Híbrido (NPS) | Nativo da Nuvem (Cloud RADIUS) |
|---|---|---|
| Infraestrutura | Necessário VM Windows Server ou bare metal | Sem servidores on-premise |
| Fonte de Identidade | AD DS via LDAP/Kerberos | Entra ID diretamente via API |
| Autoridade de Certificação | ADCS on-premise + Conector Intune | Intune Cloud PKI ou PKI de fornecedor |
| Escalabilidade | HA/balanceamento de carga manual | Escalado automaticamente pelo provedor |
| Ideal Para | AD Híbrido, dispositivos legados | Organizações cloud-first, gerenciadas pelo Intune |
| Complexidade Operacional | Maior inicial e contínua | Menor sobrecarga operacional |
On-Premise Híbrido (Windows NPS + AD DS + Azure AD Connect): Esta é a abordagem tradicional. O Windows NPS atua como o servidor RADIUS, autenticando solicitações em um Active Directory on-premise. Para vincular isso à nuvem, o Azure AD Connect sincroniza identidades on-premise com o Entra ID. Embora robusto, isso requer a manutenção da infraestrutura de servidor on-premise, o gerenciamento de alta disponibilidade e a implantação de uma PKI complexa (ADCS) se estiver implementando EAP-TLS.
Nativo da Nuvem (Cloud RADIUS + Entra ID + Intune): Esta abordagem moderna elimina a necessidade de servidores NPS on-premise. Um provedor de Cloud RADIUS de terceiros se integra diretamente ao Entra ID via Microsoft Graph API. A autenticação acontece inteiramente na nuvem. Esta arquitetura se alinha com uma estratégia cloud-first, reduzindo significativamente a sobrecarga operacional e alinhando-se aos princípios de acesso à rede zero-trust.
EAP-TLS vs. PEAP-MSCHAPv2: A Escolha Crítica
A escolha do método EAP é a decisão de segurança individual mais consequente nesta implantação. O PEAP-MSCHAPv2 depende de usuários inserindo suas credenciais de domínio. Isso é vulnerável a roubo de credenciais, ataques man-in-the-middle e cria uma experiência de usuário ruim quando as senhas expiram. Pesquisas demonstraram consistentemente que o PEAP-MSCHAPv2 pode ser comprometido por meio de ataques de pontos de acesso falsos.
EAP-TLS (Transport Layer Security) é o padrão ouro da indústria para WiFi seguro. Ele usa certificados digitais instalados no dispositivo cliente para autenticação mútua — tanto o cliente quanto o servidor provam sua identidade. Não há senhas para digitar e a conexão é cryptograficamente forte. Em um ambiente Microsoft, os certificados são normalmente implantados usando o Microsoft Intune via SCEP (Simple Certificate Enrollment Protocol) ou PKCS. Este é o caminho recomendado para todas as novas implantações e é essencial para a conformidade com o PCI DSS (Requisito 8) e as obrigações de proteção de dados do GDPR.
Guia de Implementação: Implantação Passo a Passo
A implementação da autenticação Entra ID WiFi usando EAP-TLS e Intune exige a coordenação de diversos componentes em identidade, gerenciamento de dispositivos e infraestrutura de rede. A abordagem de cinco fases a seguir é recomendada para uma implantação nativa na nuvem.
Fase 1: Preparar a Infraestrutura de Identidade e Gerenciamento de Dispositivos
Comece verificando se o seu locatário do Entra ID possui o licenciamento adequado. O Microsoft 365 E3/E5 ou o Enterprise Mobility + Security (EMS) E3/E5 inclui o gerenciamento de dispositivos Intune e os recursos de Acesso Condicional necessários para esta implantação. Sem o Intune, a implantação automatizada de certificados não é possível.
Em seguida, estabeleça sua Infraestrutura de Chaves Públicas (PKI). Você tem três opções: uma PKI nativa na nuvem fornecida pelo seu fornecedor de Cloud RADIUS, a própria Cloud PKI da Microsoft (disponível com o licenciamento Intune Suite) ou uma implantação ADCS local existente conectada ao Intune por meio do Microsoft Intune Certificate Connector. Para novas implantações, uma PKI nativa na nuvem é fortemente recomendada para evitar dependências locais.
Fase 2: Configurar o Intune para Implantação de Certificados
No centro de administração do Microsoft Intune, crie um perfil de configuração de Certificado Confiável. Faça o upload do certificado da CA Raiz da sua PKI e implante-o nos seus grupos de dispositivos de destino. Esta etapa é crítica: ela garante que os dispositivos clientes confiem no certificado apresentado pelo servidor RADIUS durante o handshake TLS, prevenindo ataques de man-in-the-middle.
Em seguida, crie um perfil de Certificado SCEP (ou PKCS, se a sua PKI exigir). Configure o formato do Nome do Assunto — para autenticação baseada em usuário, use CN={{UserPrincipalName}}; para autenticação baseada em dispositivo, use CN={{DeviceName}} ou o número de série do dispositivo. Defina o Nome Alternativo do Assunto (SAN) para incluir o User Principal Name ou o ID do dispositivo. Atribua ambos os perfis aos grupos de usuários ou dispositivos do Entra ID apropriados.
Fase 3: Configurar a Integração do Cloud RADIUS
Conceda ao seu provedor de Cloud RADIUS as permissões necessárias da Microsoft Graph API no seu locatário do Entra ID. No mínimo, o provedor exige User.Read.All e GroupMember.Read.All para validar as associações de grupo durante a autenticação. Alguns provedores também exigem Device.Read.All para políticas baseadas em dispositivos.
No portal de gerenciamento do Cloud RADIUS, defina suas políticas de autenticação. Uma política bem estruturada para um ambiente corporativo pode ser: "Permitir o acesso se o certificado for emitido pela [CA Confiável] E o usuário for membro do grupo do Entra ID [Corporate-WiFi-Users] E o dispositivo estiver marcado como Em Conformidade no Intune." Esta política em camadas impõe a identidade e a integridade do dispositivo simultaneamente.
Fase 4: Configurar a Infraestrutura Sem Fio
No seu controlador de LAN sem fio ou painel de gerenciamento na nuvem (como Cisco Meraki, Aruba Central ou Juniper Mist), adicione os endereços IP do servidor Cloud RADIUS e os segredos compartilhados como servidores de autenticação RADIUS. Configure servidores primários e secundários para redundância. Defina o tempo limite do RADIUS para um mínimo de 5 segundos para acomodar a latência de ida e volta da nuvem.
Crie um novo SSID configurado para WPA2-Enterprise ou WPA3-Enterprise. Atribua os servidores RADIUS a este SSID. Para implantações em Hospitalidade , certifique-se de que este SSID corporativo esteja em uma VLAN separada de qualquer rede de convidados. Para ambientes de Varejo , considere implantar o SSID corporativo apenas em áreas internas, mantendo a rede do salão de vendas separada.
Fase 5: Implantar o Perfil de WiFi via Intune
Crie um perfil de configuração de WiFi no Intune. Defina o SSID para corresponder exatamente ao que você configurou na infraestrutura sem fio. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Nas configurações de EAP, selecione EAP-TLS como o método de autenticação. Vincule o perfil de certificado SCEP como o certificado do cliente e especifique o perfil de CA Raiz Confiável que você implantou na Fase 2.
Atribua este perfil de WiFi aos mesmos grupos de dispositivos que receberam os perfis de certificado. Os dispositivos receberão silenciosamente o certificado e a configuração de WiFi durante a próxima sincronização do Intune e se conectarão automaticamente quando estiverem ao alcance do SSID — sem necessidade de interação do usuário.
Melhores Práticas para Ambientes Corporativos
As recomendações a seguir representam o consenso do setor para implantações seguras e escalonáveis do Microsoft 802.1X em locais corporativos.
Exija o EAP-TLS em todas as novas implantações. Não implante novas redes usando PEAP-MSCHAPv2. Os riscos de segurança do WiFi baseado em credenciais são bem documentados e incompatíveis com uma postura de segurança zero-trust. O EAP-TLS é essencial para a conformidade com PCI DSS, GDPR e ISO 27001.
Automatize o ciclo de vida dos certificados. Certifique-se de que, quando um usuário for desativado no Entra ID ou um dispositivo for retirado no Intune, o certificado correspondente seja revogado automaticamente ou a política RADIUS bloqueie o acesso imediatamente. Isso é particularmente importante em ambientes com alta rotatividade, como Hospitalidade e Varejo , onde as mudanças de pessoal são frequentes.
Implemente o Acesso Condicional do Entra ID. Aproveite as políticas de Acesso Condicional para impor a conformidade do dispositivo como uma condição de acesso à rede. Exigir que os dispositivos sejam marcados como 'Em Conformidade' no Intune antes que possam se autenticar no RADIUS garante que apenas dispositivos atualizados e em conformidade com as políticas acessem a rede corporativa.
Segmente rigorosamente as redes corporativas e de convidados. O 802.1X foi projetado para dispositivos corporativos gerenciados. Para visitantes, prestadores de serviço e BYOD, implemente uma solução de Guest WiFi dedicada com um Captive Portal. Isso pode ser integrado ao Entra ID B2B para acesso de prestadores de serviço, ou usar logins sociais e verificação por SMS para acesso do público em geral. Nunca permita dispositivos não gerenciados no SSID 802.1X corporativo.
Planeje para dispositivos legados e IoTdispositivos. Impressoras, sensores de IoT e dispositivos legados que não suportam certificados exigem uma estratégia separada. Use MAC Authentication Bypass (MAB) para dispositivos conhecidos, ou um SSID WPA2-Personal dedicado com uma PSK complexa e rotacionada, isolada em uma VLAN dedicada. A plataforma Sensors da Purple, por exemplo, pode operar em uma VLAN de IoT dedicada, separada da infraestrutura de autenticação corporativa.
Monitore eventos de autenticação. Integre logs RADIUS com seu SIEM ou use a plataforma WiFi Analytics para monitorar falhas de autenticação, avisos de expiração de certificado e padrões de acesso incomuns. O monitoramento proativo evita interrupções antes que elas impactem as operações.
Solução de Problemas e Mitigação de Riscos
Mesmo implantações bem planejadas encontram problemas. A seguir, os modos de falha mais comuns e suas resoluções.
Falhas na Implantação de Certificados. O problema mais comum em uma implantação EAP-TLS é a falha dos dispositivos em receber certificados do Intune. Isso geralmente é causado por um Intune Certificate Connector mal configurado (se estiver usando ADCS local), URL SCEP incorreta ou dispositivos que não sincronizam com o Intune. Sempre verifique o status do Certificate Connector no centro de administração do Intune e verifique os logs de sincronização do dispositivo. Certifique-se de que a conta de serviço SCEP tenha as permissões necessárias na CA.
Problemas de Tempo Limite (Timeout) do RADIUS. Se o ponto de acesso não conseguir alcançar o servidor RADIUS dentro do tempo limite configurado, os clientes não conseguirão se conectar. Certifique-se de que suas regras de firewall permitam as portas UDP 1812 (autenticação) e 1813 (accounting) de saída para as faixas de IP do provedor de Cloud RADIUS. Se estiver usando NPS local, implante no mínimo dois servidores NPS e configure seus pontos de acesso para failover entre eles.
Falhas de Confiança de Certificado. Se os clientes receberem um erro de "certificado de servidor não confiável", o perfil de CA de Raiz Confiável não foi implantado corretamente no dispositivo. Verifique a atribuição do perfil no Intune e verifique o repositório de certificados do dispositivo. Este é um problema comum com dispositivos recém-registrados que ainda não concluíram sua primeira sincronização com o Intune.
Extensão NPS para Azure MFA. Embora seja tecnicamente possível usar a Extensão NPS para impor a Autenticação de Múltiplos Fatores para WiFi, isso é fortemente desencorajado para o acesso primário. A experiência do usuário de receber uma solicitação de MFA toda vez que um dispositivo faz roaming entre pontos de acesso é severamente disruptiva. Confie na autenticação forte fornecida pelo certificado do dispositivo e aplique o MFA na camada de aplicação.
Conflitos de Política de Grupo. Em ambientes híbridos, os Objetos de Política de Grupo (GPOs) que configuram o cliente sem fio do Windows podem entrar em conflito com os perfis de WiFi do Intune. Certifique-se de que os perfis do Intune tenham precedência revisando as configurações de registro de MDM e, quando necessário, bloqueando a configuração sem fio baseada em GPO para dispositivos gerenciados pelo Intune.
ROI e Impacto nos Negócios
A migração para uma arquitetura RADIUS nativa da nuvem integrada ao Entra ID entrega valor mensurável e quantificável em várias dimensões.
Redução de Chamados no Helpdesk. Problemas de WiFi relacionados a senhas — bloqueios, senhas expiradas, suplicantes mal configurados — são uma fonte significativa de chamados de suporte de TI em ambientes baseados em credenciais. O EAP-TLS elimina isso completamente. As organizações geralmente relatam uma redução de 30 a 50% no volume de helpdesk relacionado ao WiFi após a migração para a autenticação baseada em certificado.
Economia de Custos de Infraestrutura. A desativação de servidores NPS locais reduz os custos de computação, as taxas de licenciamento de SO e a sobrecarga operacional de aplicar patches e manter clusters de alta disponibilidade. Para uma organização de médio porte que opera dois servidores NPS, isso pode representar uma economia de £15.000 a £30.000 por ano em custos de infraestrutura e operacionais.
Melhoria na Postura de Segurança e Conformidade. Afastar-se da autenticação baseada em credenciais mitiga o risco de roubo de credenciais e movimento lateral, protegendo dados corporativos sensíveis. Para organizações sujeitas ao PCI DSS, isso aborda diretamente os requisitos de controle de acesso à rede. Para organizações de Saúde que lidam com dados de pacientes, isso apoia a conformidade com o DSPT. Para operadores de Transporte , isso se alinha aos requisitos da Diretiva NIS2 para segurança de rede.
Melhoria na Experiência do Usuário. Conexão WiFi automática e contínua — sem solicitações de senha, sem bloqueios e sem configuração manual — melhora a produtividade e reduz o atrito para a equipe. Isso é particularmente impactante em ambientes de alta mobilidade, como centros de distribuição, enfermarias de hospitais e lojas de varejo.
Ao tratar sua rede WiFi como uma extensão de sua estratégia de identidade na nuvem, você garante um acesso seguro e sem atritos que escala com sua organização. Para mais orientações sobre os aspectos de integração de SD-WAN em redes corporativas modernas, consulte Os Principais Benefícios do SD-WAN para Empresas Modernas . Para considerações de implantação específicas para o setor de hospitalidade, consulte Soluções Modernas de WiFi para Hospitalidade que Seus Hóspedes Merecem .
Termos-Chave e Definições
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.
Estudos de Caso
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.
Análise de Cenário
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?
💡 Dica:Consider what NPS requires to function and whether those dependencies will exist post-migration. Also consider the security implications of the current EAP method.
Mostrar Abordagem Recomendada
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?
💡 Dica:Consider the difference between user-based and device-based certificate profiles in Intune, and how RADIUS policies can be scoped to device identity.
Mostrar Abordagem Recomendada
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?
💡 Dica:Remember the architectural principle separating managed device authentication from unmanaged device access. Consider how Entra ID B2B could be leveraged.
Mostrar Abordagem Recomendada
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?
💡 Dica:Consider the options available for devices that cannot support EAP-TLS, and the importance of network segmentation.
Mostrar Abordagem Recomendada
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.
Principais Conclusões
- ✓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.
