Autenticação WiFi Azure AD e Entra ID: Guia de Integração e Configuração
Este guia de referência técnica fornece aos gestores de TI, arquitetos de rede e diretores de operações de espaços um roteiro prático para integrar o Microsoft Entra ID (Azure AD) com redes WiFi empresariais utilizando RADIUS e 802.1X. Abrange a decisão arquitetural entre o Windows NPS on-premise e o RADIUS nativo da cloud, a implementação de autenticação EAP-TLS baseada em certificados via Microsoft Intune e as melhores práticas operacionais para proteger o acesso sem fios em ambientes de hotelaria, retalho e setor público. Para organizações que já investem no ecossistema Microsoft 365 e Entra ID, este guia faz a ponte entre a gestão de identidade na cloud e a segurança física da rede.
Resumo Executivo
Para as empresas modernas com forte investimento no ecossistema Microsoft, a ligação da infraestrutura de identidade na cloud às redes sem fios físicas é um imperativo de segurança crítico. Historicamente, a autenticação WiFi dependia dos 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 — já não é suficiente nem segura.
Este guia fornece aos gestores de TI, arquitetos de rede e diretores de operações de espaços um roteiro prático para implementar a autenticação WiFi Azure AD. Exploramos as diferenças arquiteturais entre manter uma pegada NPS on-premise e migrar para uma solução RADIUS nativa da cloud. Crucialmente, detalhamos como tirar partido do Microsoft Intune para autenticação baseada em certificados (EAP-TLS), o que elimina vulnerabilidades relacionadas com palavras-passe e proporciona uma experiência fluida e sem fricção para os utilizadores finais. Quer esteja a gerir um hotel de 500 quartos, uma cadeia de retalho ou uma grande implementação no setor público, este guia ajudará a proteger a sua extremidade sem fios utilizando os seus investimentos atuais em identidade Microsoft. Para uma discussão mais ampla sobre modelos de implementação, consulte o nosso Cloud RADIUS vs On-Premise RADIUS: Guia de Decisão para Equipas de TI .
Análise Técnica Aprofundada: Arquitetura e Normas
A base do WiFi empresarial seguro é a norma IEEE 802.1X, que fornece controlo de acesso à rede baseado em portas. Num ambiente centrado na Microsoft, a integração do 802.1X com o Entra ID requer um planeamento arquitetural cuidadoso em três camadas: a infraestrutura sem fios, o servidor de autenticação e o diretório de identidade.
O Papel do RADIUS e do 802.1X
Quando um dispositivo cliente (o suplicante) tenta ligar-se a uma rede WPA2/WPA3-Enterprise, o Ponto de Acesso Sem Fios (o autenticador) bloqueia todo o tráfego, exceto os pacotes EAP (Extensible Authentication Protocol). O ponto de acesso encaminha estes pacotes para um servidor RADIUS. O servidor RADIUS valida a identidade do utilizador ou do dispositivo num serviço de diretório e devolve 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 fios empresarial e é descrito em detalhe no nosso Definição de Pontos de Acesso Sem Fios: O Seu Guia Definitivo para 2026 .
Abordagens Arquiteturais para Ambientes Microsoft
Existem duas arquiteturas principais para integrar a identidade Microsoft com a autenticação WiFi, cada uma com vantagens e desvantagens distintas:
| Dimensão | Híbrido On-Premise (NPS) | Nativo da Cloud (Cloud RADIUS) |
|---|---|---|
| Infraestrutura | VM Windows Server ou bare metal necessário | Sem servidores on-premise |
| Fonte de Identidade | AD DS via LDAP/Kerberos | Entra ID diretamente via API |
| Autoridade de Certificação | ADCS on-premise + Intune Connector | Intune Cloud PKI ou PKI de fornecedor |
| Escalabilidade | HA/balanceamento de carga manual | Escalado automaticamente pelo fornecedor |
| Ideal Para | AD Híbrido, dispositivos legados | Organizações cloud-first geridas pelo Intune |
| Complexidade Operacional | Maior (inicial e contínua) | Menor custo operacional |
Híbrido On-Premise (Windows NPS + AD DS + Azure AD Connect): Esta é a abordagem tradicional. O Windows NPS atua como o servidor RADIUS, autenticando pedidos num Active Directory on-premise. Para ligar isto à cloud, o Azure AD Connect sincroniza as identidades on-premise com o Entra ID. Embora robusto, isto requer a manutenção de infraestrutura de servidores on-premise, a gestão de alta disponibilidade e a implementação de uma PKI complexa (ADCS) se implementar EAP-TLS.
Nativo da Cloud (Cloud RADIUS + Entra ID + Intune): Esta abordagem moderna elimina a necessidade de servidores NPS on-premise. Um fornecedor de Cloud RADIUS de terceiros integra-se diretamente com o Entra ID via Microsoft Graph API. A autenticação acontece inteiramente na cloud. Esta arquitetura alinha-se com uma estratégia cloud-first, reduzindo significativamente a carga operacional e alinhando-se com os 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 mais consequente nesta implementação. O PEAP-MSCHAPv2 depende da introdução de credenciais de domínio pelos utilizadores. Isto é vulnerável a roubo de credenciais, ataques man-in-the-middle e cria uma má experiência de utilizador quando as palavras-passe expiram. A investigação tem demonstrado consistentemente que o PEAP-MSCHAPv2 pode ser comprometido através de ataques de pontos de acesso falsos.
EAP-TLS (Transport Layer Security) é o padrão de ouro da indústria para WiFi seguro. Utiliza certificados digitais instalados no dispositivo cliente para autenticação mútua — tanto o cliente como o servidor provam a sua identidade. Não há palavras-passe para digitar e a ligação é criptograficamente forte. Num ambiente Microsoft, os certificados são normalmente implementados utilizando o Microsoft Intune via SCEP (Simple Certificate Enrollment Protocol) ou PKCS. Este é o caminho recomendado para todas as novas implementações e éessencial para a conformidade com a PCI DSS (Requisito 8) e as obrigações de proteção de dados do GDPR.
Guia de Implementação: Implementação Passo a Passo
A implementação da autenticação Entra ID WiFi utilizando EAP-TLS e Intune requer a coordenação de vários componentes em toda a infraestrutura de identidade, gestão de dispositivos e rede. A seguinte abordagem de cinco fases é recomendada para uma implementação nativa na nuvem.
Fase 1: Preparar a Infraestrutura de Gestão de Identidade e Dispositivos
Comece por verificar se o seu tenant do Entra ID possui o licenciamento adequado. O Microsoft 365 E3/E5 ou o Enterprise Mobility + Security (EMS) E3/E5 incluem as capacidades de gestão de dispositivos Intune e de Acesso Condicional necessárias para esta implementação. Sem o Intune, a implementação automatizada de certificados não é possível.
Em seguida, estabeleça a sua Infraestrutura de Chaves Públicas (PKI). 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 implementação ADCS on-premise existente ligada ao Intune através do Microsoft Intune Certificate Connector. Para novas implementações, recomenda-se vivamente uma PKI nativa na nuvem para evitar dependências on-premise.
Fase 2: Configurar o Intune para Implementação de Certificados
No centro de administração do Microsoft Intune, crie um perfil de configuração de Certificado Confiável. Carregue o certificado Root CA da sua PKI e implemente-o nos seus grupos de dispositivos de destino. Este passo é crítico: garante que os dispositivos clientes confiam no certificado apresentado pelo servidor RADIUS durante o TLS handshake, prevenindo ataques man-in-the-middle.
Em seguida, crie um perfil de Certificado SCEP (ou PKCS, se a sua PKI o exigir). Configure o formato do Nome do Assunto — para autenticação baseada no utilizador, utilize CN={{UserPrincipalName}}; para autenticação baseada no dispositivo, utilize 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 utilizadores ou dispositivos Entra ID apropriados.
Fase 3: Configurar a Integração Cloud RADIUS
Conceda ao seu fornecedor de Cloud RADIUS as permissões necessárias da Microsoft Graph API no seu tenant do Entra ID. No mínimo, o fornecedor requer User.Read.All e GroupMember.Read.All para validar as adesões a grupos durante a autenticação. Alguns fornecedores também exigem Device.Read.All para políticas baseadas em dispositivos.
No portal de gestão do Cloud RADIUS, defina as 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 utilizador for membro do grupo Entra ID [Corporate-WiFi-Users] E o dispositivo estiver marcado como Em Conformidade no Intune." Esta política em camadas impõe simultaneamente a identidade e a integridade do dispositivo.
Fase 4: Configurar a Infraestrutura Sem Fios
No seu controlador de LAN sem fios ou painel de gestão na nuvem (como Cisco Meraki, Aruba Central ou Juniper Mist), adicione os endereços IP do servidor Cloud RADIUS e os segredos partilhados como servidores de autenticação RADIUS. Configure servidores primários e secundários para redundância. Defina o tempo de espera (timeout) 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 implementações em Hospitalidade , certifique-se de que este SSID corporativo está numa VLAN separada de qualquer rede de convidados. Para ambientes de Retalho , considere implementar o SSID corporativo apenas em áreas de back-of-house, mantendo a rede da área de vendas separada.
Fase 5: Implementar o Perfil WiFi via Intune
Crie um perfil de configuração WiFi no Intune. Defina o SSID para corresponder exatamente ao que configurou na infraestrutura sem fios. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Nas definições de EAP, selecione EAP-TLS como o método de autenticação. Associe o perfil de certificado SCEP como o certificado de cliente e especifique o perfil de Root CA Confiável que implementou na Fase 2.
Atribua este perfil WiFi aos mesmos grupos de dispositivos que receberam os perfis de certificado. Os dispositivos receberão silenciosamente o certificado e a configuração WiFi durante a próxima sincronização do Intune e ligar-se-ão automaticamente quando estiverem ao alcance do SSID — sem necessidade de interação do utilizador.
Melhores Práticas para Ambientes Empresariais
As seguintes recomendações representam o consenso da indústria para implementações seguras e escaláveis de Microsoft 802.1X em locais empresariais.
Exija EAP-TLS em todas as novas implementações. Não implemente novas redes utilizando PEAP-MSCHAPv2. Os riscos de segurança do WiFi baseado em credenciais estão bem documentados e são incompatíveis com uma postura de segurança zero-trust. O EAP-TLS é essencial para a conformidade com a PCI DSS, GDPR e ISO 27001.
Automatize o ciclo de vida dos certificados. Garanta que, quando um utilizador é desativado no Entra ID ou um dispositivo é retirado no Intune, o certificado correspondente é automaticamente revogado ou a política RADIUS bloqueia imediatamente o acesso. Isto é particularmente importante em ambientes de elevada rotatividade, como Hospitalidade e Retalho , 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 condição para o acesso à rede. Exigir que os dispositivos sejam marcados como 'Em Conformidade' no Intune antes de poderem autenticar-se no RADIUS garante que apenas dispositivos atualizados e em conformidade com as políticas acedam à rede corporativa.
Segmente rigorosamente as redes corporativas e de convidados. O 802.1X foi concebido para dispositivos corporativos geridos. Para visitantes, prestadores de serviços e BYOD, implemente uma solução de Guest WiFi dedicada com um Captive Portal. Isto pode integrar-se com o Entra ID B2B para acesso de prestadores de serviços, ou utilizar logins sociais e verificação por SMS para acesso do público em geral. Nunca permita dispositivos não geridos no SSID 802.1X corporativo.
**Planeie para legado e IoT dispositivos. Impressoras, sensores IoT e dispositivos legados que não suportam certificados requerem uma estratégia separada. Utilize MAC Authentication Bypass (MAB) para dispositivos conhecidos, ou um SSID WPA2-Personal dedicado com uma PSK complexa e rotativa, isolada numa VLAN dedicada. A plataforma Sensors da Purple, por exemplo, pode operar numa VLAN de IoT dedicada, separada da infraestrutura de autenticação corporativa.
Monitorize eventos de autenticação. Integre os registos RADIUS com o seu SIEM ou utilize a plataforma WiFi Analytics para monitorizar falhas de autenticação, avisos de expiração de certificados e padrões de acesso invulgares. A monitorização proativa evita interrupções antes que estas afetem as operações.
Resolução de Problemas e Mitigação de Riscos
Mesmo as implementações bem planeadas encontram problemas. Os seguintes são os modos de falha mais comuns e as suas resoluções.
Falhas na Implementação de Certificados. O problema mais comum numa implementação EAP-TLS é a falha dos dispositivos em receber certificados do Intune. Isto é tipicamente causado por um Intune Certificate Connector mal configurado (se utilizar ADCS on-premise), um URL SCEP incorreto ou dispositivos que não sincronizam com o Intune. Verifique sempre o estado do Certificate Connector no centro de administração do Intune e consulte os registos de sincronização dos dispositivos. Certifique-se de que a conta de serviço SCEP tem as permissões necessárias na CA.
Problemas de Timeout de RADIUS. Se o ponto de acesso não conseguir contactar o servidor RADIUS dentro do tempo de espera configurado, os clientes não conseguirão ligar-se. Certifique-se de que as suas regras de firewall permitem as portas UDP 1812 (autenticação) e 1813 (accounting) de saída para os intervalos de IP do fornecedor de Cloud RADIUS. Se utilizar NPS on-premise, implemente no mínimo dois servidores NPS e configure os seus pontos de acesso para failover entre eles.
Falhas de Confiança no Certificado. Se os clientes receberem um erro de "certificado de servidor não confiável", o perfil Trusted Root CA não foi implementado corretamente no dispositivo. Verifique a atribuição do perfil no Intune e consulte o repositório de certificados do dispositivo. Este é um problema comum em dispositivos recém-registados que ainda não concluíram a sua primeira sincronização com o Intune.
Extensão NPS para Azure MFA. Embora seja tecnicamente possível utilizar a Extensão NPS para impor a Autenticação de Multi-Fator para WiFi, tal é fortemente desencorajado para o acesso principal. A experiência do utilizador ao receber uma solicitação de MFA sempre que um dispositivo faz roaming entre pontos de acesso é gravemente disruptiva. Confie na autenticação forte fornecida pelo certificado do dispositivo e, em vez disso, imponha o MFA na camada de aplicação.
Conflitos de Política de Grupo. Em ambientes híbridos, os Group Policy Objects (GPOs) que configuram o cliente sem fios Windows podem entrar em conflito com os perfis de WiFi do Intune. Assegure que os perfis do Intune têm precedência, revendo as definições de registo MDM e, onde necessário, bloqueando a configuração sem fios baseada em GPO para dispositivos geridos pelo Intune.
ROI e Impacto no Negócio
A migração para uma arquitetura RADIUS nativa na nuvem integrada com o Entra ID proporciona um valor mensurável e quantificável em várias dimensões.
Redução de Tickets de Helpdesk. Problemas de WiFi relacionados com palavras-passe — bloqueios, palavras-passe expiradas, suplicantes mal configurados — são uma fonte significativa de tickets de suporte de TI em ambientes baseados em credenciais. O EAP-TLS elimina-os inteiramente. As organizações reportam tipicamente uma redução de 30–50% no volume de helpdesk relacionado com WiFi após a migração para a autenticação baseada em certificados.
Poupança em Custos de Infraestrutura. A desativação de servidores NPS on-premise 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édia dimensão que utilize dois servidores NPS, isto pode representar uma poupança de £15.000–£30.000 por ano em custos operacionais e de infraestrutura.
Postura de Segurança e Conformidade Reforçadas. 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, isto aborda diretamente os requisitos de controlo de acesso à rede. Para organizações de Saúde que lidam com dados de pacientes, apoia a conformidade com o DSPT. Para operadores de Transporte , alinha-se com os requisitos da Diretiva NIS2 para segurança de rede.
Experiência do Utilizador Melhorada. A ligação WiFi automática e contínua — sem solicitações de palavra-passe, sem bloqueios e sem configuração manual — melhora a produtividade e reduz a fricção para os funcionários. Isto é particularmente impactante em ambientes de alta mobilidade, como centros de distribuição, enfermarias hospitalares e áreas de venda a retalho.
Ao tratar a sua rede WiFi como uma extensão da sua estratégia de identidade na nuvem, garante um acesso seguro e sem fricção que escala com a sua organização. Para mais orientações sobre os aspetos de integração de SD-WAN em redes empresariais modernas, consulte Os Principais Benefícios da SD-WAN para Empresas Modernas . Para considerações de implementação específicas para o setor da hotelaria, consulte Soluções Modernas de WiFi para Hotelaria que os 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ários
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.
