Resolução de Problemas de Falhas de Autenticação 802.1X (RADIUS/EAP)
Guia de diagnóstico passo a passo para resolver erros de autenticação 802.1X, EAP-TLS, PEAP e RADIUS em redes WiFi corporativas.
Video overview
Ouça este guia
Ver transcrição do podcast
Parte da nossa série principal: Guia de Segurança de WiFi Corporativa →
Resumo Executivo
Para líderes de TI que gerenciam WiFi corporativo em hotéis, redes de varejo, estádios e locais do setor público, a autenticação 802.1X é a espinha dorsal do controle de acesso à rede - e quando ela falha, o impacto é imediato e operacionalmente grave. Um único perfil de suplicante mal configurado, um certificado RADIUS expirado ou um segredo compartilhado divergente pode bloquear centenas de usuários simultaneamente, gerando escalonamentos de suporte, perda de receita e possíveis violações de conformidade.
O IEEE 802.1X define o controle de acesso à rede baseado em porta, operando na Camada 2 do modelo OSI. Ele trabalha em conjunto com o Extensible Authentication Protocol (EAP) e um servidor RADIUS para autenticar cada dispositivo antes de conceder acesso à rede. O protocolo suporta múltiplos métodos EAP - EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS e EAP-FAST - cada um com perfis de segurança, requisitos de certificado e complexidade operacional distintos.
Este guia fornece uma estrutura de diagnóstico estruturada para resolver falhas do 802.1X na cadeia de autenticação de três componentes: o Suplicante (dispositivo final), o Autenticador (ponto de acesso ou switch) e o Servidor de Autenticação (RADIUS). Ele inclui estudos de caso reais, uma árvore de decisão de triagem rápida, práticas recomendadas de implementação alinhadas com os padrões PCI-DSS v4.0 e WPA3-Enterprise, e uma biblioteca de exemplos práticos extraídos de implantações em hotelaria e varejo.
Para organizações que implantam Guest WiFi ao lado de redes de funcionários, entender onde o 802.1X falha - e como corrigi-lo rapidamente - é uma prioridade operacional e comercial direta.
Detalhamento Técnico
A Arquitetura de Autenticação 802.1X
O padrão IEEE 802.1X define um modelo de três componentes que rege cada troca de autenticação de WiFi corporativo. Compreender o papel de cada componente é o pré-requisito para uma solução de problemas eficaz.
O Suplicante é o dispositivo do usuário final - um laptop, smartphone, tablet ou terminal de ponto de venda. Ele executa um componente de software (o cliente suplicante, integrado ao sistema operacional no Windows, macOS, iOS e Android) que inicia a troca EAP e apresenta as credenciais para a rede. A configuração do suplicante - especificamente o método EAP, as configurações de confiança de certificado e a origem da credencial - é uma das fontes mais comuns de falhas de autenticação.
O Authenticator é o ponto de acesso sem fio ou switch gerenciado. Criticamente, o Authenticator não toma decisões de autenticação. Ele age como um relay sem estado, bloqueando todo o tráfego de dados na porta controlada até que o servidor RADIUS emita uma decisão de autorização. Ele se comunica com o Supplicant usando quadros EAPOL (EAP over LAN) por meio do meio com ou sem fio, e com o servidor RADIUS usando pacotes RADIUS Access-Request e Access-Accept/Reject pelas portas UDP 1812 (autenticação) e 1813 (accounting).
O Authentication Server é o servidor RADIUS. É aqui que ocorre a validação real das credenciais. O servidor RADIUS negocia o método EAP com o Supplicant, valida as credenciais em um diretório de identidade (Active Directory, Azure AD, Okta ou LDAP) e retorna um Access-Accept com atributos opcionais de atribuição de VLAN, ou um Access-Reject com um código de motivo. Em implantações modernas, este é cada vez mais um serviço hospedado na nuvem - consulte Como Implementar Autenticação 802.1X com Cloud RADIUS para obter um guia completo de implantação.
Comparação de Métodos EAP
O EAP não é um método de autenticação único, mas sim um framework que suporta múltiplos métodos internos. A escolha do método EAP tem implicações diretas na postura de segurança, nos requisitos de infraestrutura de certificados e nos tipos de falhas que você provavelmente irá encontrar.
| Método EAP | Requisito de Certificado | Nível de Segurança | Complexidade de Implantação | Caso de Uso Principal |
|---|---|---|---|---|
| EAP-TLS | Mútuo (cliente + servidor) | Mais alto | Alta (requer PKI + MDM) | Dispositivos corporativos gerenciados |
| PEAP-MSCHAPv2 | Apenas no servidor | Médio | Média | Ambientes integrados ao AD |
| EAP-TTLS | Apenas no servidor | Médio | Média | Ambientes BYOD com sistemas operacionais mistos |
| EAP-FAST | Nenhum (usa PAC) | Médio-Alto | Baixa | Suporte a dispositivos legados |
O WPA3-Enterprise com EAP-TLS é a melhor prática atual do setor para frotas de dispositivos corporativos gerenciados. Para locais que implantam Guest WiFi e redes de funcionários em paralelo - comum em ambientes de Hospitality e Retail - uma abordagem híbrida é típica: EAP-TLS para dispositivos corporativos, Captive Portal com backend RADIUS para convidados.
O Fluxo de Autenticação: Passo a Passo
Compreender a sequência precisa da troca do 802.1X é essencial para identificar onde ocorre uma falha. O fluxo prossegue da seguinte forma:
- O Supplicant se associa ao SSID. O Authenticator abre uma porta controlada, bloqueando todo o tráfego não EAP.
- O Authenticator envia um EAP-Request/Identity para o Supplicant.
- O Supplicant responde com um EAP-Response/Identity (a identidade do usuário ou do dispositivo).
- O Authenticator encapsula isso em um Access-Request RADIUS e o encaminha para o servidor RADIUS.
- O servidor RADIUS emite um Access-Challenge, propondo o método EAP (por exemplo, EAP-TLS ou PEAP).
- O Supplicant e o servidor RADIUS negociam o método EAP e trocam credenciais por meio de múltiplas rodadas de Access-Request / Access-Challenge, transmitidas pelo Authenticator.
- O servidor RADIUS valida as credenciais em relação ao diretório de identidade e retorna um Access-Accept (com atributos opcionais de atribuição de VLAN) ou um Access-Reject (com um código de motivo).
- Se aceito, o Authenticator abre a porta controlada e o dispositivo obtém acesso à rede. Para WPA2/WPA3-Enterprise, segue-se um 4-Way Handshake para derivar as chaves de criptografia da sessão.
Uma falha em qualquer etapa dessa sequência produz um perfil de sintoma diferente. Mapear o sintoma para a etapa é a base para uma triagem rápida.
Modos de Falha Comuns e Indicadores de Diagnóstico
Modo de Falha 1: Expiração de Certificado (Servidor ou Cliente)
Este é o modo de falha mais disruptivo em implantações 802.1X de produção. Quando o certificado TLS do servidor RADIUS expira, todos os clientes falham simultaneamente na autenticação - uma interrupção completa da rede. Quando o certificado de um cliente expira (em implantações EAP-TLS), os dispositivos individuais falham enquanto outros continuam a se autenticar normalmente.
Indicadores de diagnóstico: Os logs de eventos do NPS/RADIUS mostram o Código de Motivo 22 ("O certificado do cliente expirou ou ainda não é válido") ou o Código de Motivo 16 ("A autenticação falhou devido a uma incompatibilidade de credenciais do usuário"). No Windows NPS, verifique o Event ID 6273 no log de eventos de Segurança. No FreeRADIUS, procure por TLS Alert read:fatal:certificate expired na saída de depuração.
Resolução: Renove o certificado expirado e envie o certificado CA atualizado para todos os clientes via MDM. Implemente o monitoramento automatizado de expiração de certificados com um limite de alerta de 90 dias.
Modo de Falha 2: Incompatibilidade de Segredo Compartilhado do RADIUS
O segredo compartilhado é usado para autenticar mensagens RADIUS entre o Authenticator e o servidor RADIUS. Uma incompatibilidade faz com que o servidor RADIUS descarte silenciosamente os pacotes Access-Request. Do ponto de vista do AP, o servidor RADIUS parece não responder.
Indicadores de diagnóstico: Os logs do AP mostram tempos limite e retransmissões do servidor RADIUS. O servidor RADIUS não mostra entradas de log correspondentes para as tentativas que falharam - as solicitações estão sendo descartadas antes do processamento. Uma captura do Wireshark na interface do servidor RADIUS mostrará pacotes UDP de entrada na porta 1812 que são descartados silenciosamente.
Resolução: Verifique e sincronize o segredo compartilhado tanto no Authenticator (configuração do AP/controladora) quanto no servidor RADIUS (configuração do cliente NAS). Use um segredo forte, gerado aleatoriamente, com pelo menos 32 caracteres. Implemente o RadSec (RADIUS sobre TLS) para eliminar a dependência de segredo compartilhado em implantações de RADIUS na nuvem.
Modo de Falha 3: Desconfiguração do Perfil do Supplicant
Em implantações PEAP-MSCHAPv2, os clientes devem ser configurados para validar o certificado do servidor RADIUS em relação a uma CA confiável. Se a validação do certificado estiver desativada - um atalho comum durante a implantação inicial - a rede estará vulnerável a ataques de coleta de credenciais por APs invasores. Se a CA incorreta for confiável, ou se o CN/SAN do certificado do servidor não corresponder ao nome do servidor configurado, a autenticação falhará.
Indicadores de diagnóstico: Dispositivos individuais falham enquanto outros funcionam. Os logs do RADIUS mostram falhas de handshake EAP-TLS ou falhas no estabelecimento do túnel PEAP. No Windows, o Event ID 8001 ou 8002 do WLAN-AutoConfig no log Operational indica falhas no lado do suplicante.
Resolução: Implante perfis de WiFi padronizados via MDM (Microsoft Intune, Jamf ou equivalente). Certifique-se de que o certificado da CA confiável está incluído no perfil e que a validação do certificado do servidor seja exigida. Nunca desative a validação de certificado em ambiente de produção.
Modo de Falha 4: Problemas de Trânsito de Rede (Fragmentação de MTU)
As trocas EAP-TLS envolvem a transmissão de cadeias de certificados completas, o que pode gerar pacotes RADIUS grandes. Se o caminho WAN entre o Autenticador e um servidor RADIUS em nuvem tiver um MTU baixo (comum em certas configurações de MPLS ou SD-WAN), esses pacotes podem ser fragmentados. Muitos firewalls e dispositivos de inspeção de estado descartam pacotes UDP fragmentados, fazendo com que o handshake TLS trave silenciosamente.
Indicadores de diagnóstico: A autenticação EAP-TLS falha de forma intermitente ou consistente em sites conectados via WAN, enquanto os sites com RADIUS local funcionam. As capturas de pacotes mostram pacotes Access-Request do RADIUS sendo fragmentados na interface WAN. A autenticação funciona quando o servidor RADIUS está na LAN local.
Resolução: Implante RadSec (RADIUS sobre TLS na porta TCP 2083). O TCP lida com a fragmentação e retransmissão de forma nativa, eliminando totalmente este modo de falha. Como alternativa, ajuste o MTU na interface WAN ou configure os parâmetros de fragmentação do RADIUS no servidor.
Modo de Falha 5: Falha de Conectividade do Diretório de Identidades
O servidor RADIUS deve ser capaz de alcançar o diretório de identidades (Active Directory, LDAP, Azure AD) para validar as credenciais. Uma falha de DNS, alteração de regra de firewall ou inatividade do controlador de domínio fará com que todas as tentativas de autenticação falhem, mesmo que o serviço RADIUS em si esteja funcionando corretamente.
Indicadores de diagnóstico: Os logs do servidor RADIUS mostram tentativas de autenticação sendo recebidas, mas falhando com "Não foi possível contatar o servidor LDAP" ou erros equivalentes. Event ID 6273 do NPS com Reason Code 16 ou 66. O próprio monitoramento de integridade do servidor RADIUS pode não detectar isso se a conectividade com o diretório não for monitorada explicitamente.
Resolução: Implemente um monitoramento de integridade dedicado para o caminho de conexão do RADIUS ao diretório. Configure múltiplos controladores de domínio ou réplicas LDAP como destinos de failover. Para implantações de RADIUS em nuvem, certifique-se de que a integração com o provedor de identidade (Azure AD Connect, proxy LDAP) esteja incluída no seu monitoramento de disponibilidade.
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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.
Guia de Implementação
Fase 1: Validação Pré-Implantação
Antes de implantar o 802.1X em escala, valide os seguintes pré-requisitos. Ignorar esta fase é a principal causa de falhas pós-implantação.
Primeiro, confirme se o certificado do seu servidor RADIUS é emitido por uma CA confiável para todas as plataformas de dispositivos clientes em seu parque de TI. No Windows, isso significa que a CA deve estar no repositório de Autoridades de Certificação Raiz Confiáveis. No iOS e Android, o certificado da CA deve ser explicitamente distribuído por meio de perfis MDM. Não use certificados autoassinados em produção.
Segundo, verifique a conectividade de rede entre todos os Autenticadores (APs e switches) e o servidor RADIUS nas portas UDP 1812 e 1813. Use um cliente de teste RADIUS (como o radtest no Linux ou a ferramenta de teste NPS no Windows) para confirmar a autenticação ponta a ponta antes de implantar em SSIDs de produção.
Terceiro, valide a integração do seu diretório de identidade. Confirme se o servidor RADIUS pode realizar binds LDAP e consultas de associação de grupo em seu diretório. Teste com uma conta de serviço e verifique se os atributos de atribuição de VLAN esperados são retornados na resposta Access-Accept.
Fase 2: Seleção do Método EAP e Estratégia de Certificados
Para dispositivos corporativos gerenciados, implante o EAP-TLS com certificados de cliente distribuídos via MDM. Isso elimina o risco de roubo de credenciais e fornece a postura de autenticação mais robusta. Certifique-se de que sua plataforma MDM esteja configurada para renovar automaticamente os certificados de cliente antes do vencimento.
Para ambientes com dispositivos BYOD ou não gerenciados, o PEAP-MSCHAPv2 é a escolha pragmática. Force a validação do certificado do servidor em todos os perfis de clientes. Nunca distribua perfis de WiFi com a validação de certificado desabilitada.
Para dispositivos legados (sensores de IoT, terminais de PDV mais antigos) que não podem executar um suplicante 802.1X, implemente o MAC Authentication Bypass (MAB) como alternativa. Atribua dispositivos MAB a uma VLAN altamente restrita com regras de firewall explícitas que limitem o acesso à rede apenas aos serviços que eles necessitam.
Fase 3: Implantação e Monitoramento
Implante em uma abordagem em fases: realize um piloto com um grupo controlado de 20 a 50 dispositivos, valide os logs de autenticação, confirme a atribuição de VLAN e verifique os registros de contabilização antes de expandir para todo o parque de TI. Para implantações em grandes espaços - estádios, centros de convenções, hotéis - esta abordagem em fases é essencial para conter o raio de impacto de quaisquer erros de configuração.
Implemente o monitoramento contínuo de: expiração do certificado do servidor RADIUS (alerta aos 90 dias), disponibilidade e tempo de resposta do servidor RADIUS, taxas de sucesso/falha de autenticação por SSID e local, e conectividade do diretório de identidade. Para ambientes de Saúde e Varejo sujeitos a auditoria regulatória, garanta que os logs de contabilização RADIUS sejam retidos pelo período exigido (normalmente 12 meses sob PCI-DSS).Para implantações de Transport e grandes locais públicos, considere a implantação de servidores RADIUS redundantes com failover automático. Um único servidor RADIUS é um ponto único de falha para toda a infraestrutura de controle de acesso à rede.
Melhores Práticas
As seguintes melhores práticas são baseadas nas especificações IEEE 802.1X, WPA3-Enterprise, requisitos PCI-DSS v4.0 e na experiência operacional em implantações corporativas de grande porte.
Gerenciamento do Ciclo de Vida de Certificados é o controle operacional de maior prioridade. Implemente monitoramento automatizado com alertas de 90, 60 e 30 dias antes da expiração de todos os certificados do servidor RADIUS. Para implantações EAP-TLS, estenda esse monitoramento para os certificados de clientes por meio de sua plataforma MDM. A expiração de certificados é a principal causa de interrupções de autenticação em massa em implantações 802.1X em produção.
Implantação do RadSec deve ser o padrão para qualquer implantação 802.1X em que o tráfego RADIUS passe pela internet pública ou WAN. O RadSec (RFC 6614) encapsula o RADIUS em TLS sobre TCP, oferecendo segurança de transporte, eliminando problemas de fragmentação UDP e removendo a dependência de segredos compartilhados. A maioria das plataformas modernas de nuvem RADIUS e fornecedores de AP corporativos oferecem suporte ao RadSec.
Perfis de Clientes Forçados por MDM eliminam a maior fonte isolada de erro de configuração do solicitante. Todos os dispositivos corporativos devem receber seus perfis de WiFi por meio de MDM, e não por configuração manual. Os perfis devem incluir o certificado CA confiável, exigir a validação do certificado do servidor e especificar o método EAP correto e as configurações de autenticação interna.
Segmentação de Rede via Atribuição Dinâmica de VLAN é um controle obrigatório para a conformidade com o PCI-DSS e um pilar fundamental da arquitetura de rede Zero Trust. Configure políticas de autorização RADIUS para atribuir usuários à VLAN apropriada com base na associação a grupos - equipe na VLAN corporativa, convidados em uma VLAN isolada apenas para internet, dispositivos IoT em uma VLAN de gerenciamento restrita. Isso limita o raio de alcance de qualquer dispositivo comprometido.
Retenção de Logs de Contabilização RADIUS fornece a trilha de auditoria exigida pelo Requisito 10 do PCI-DSS e é essencial para investigações forenses após um incidente de segurança. Garanta que os logs de contabilização capturem eventos de início e fim de sessão, identidade do usuário, endereço MAC do dispositivo, VLAN atribuída, duração da sessão e volume de dados. Integre a contabilização RADIUS ao seu SIEM para detecção de anomalias em tempo real.
Para organizações que implantam soluções de WiFi Analytics junto com o 802.1X, a combinação de dados de autenticação por usuário e analytics fornece uma poderosa camada de inteligência operacional - permitindo análise de tempo de permanência, planejamento de capacidade e detecção de anomalias no nível de sessão individual.
Solu''#%%&o de Problemas e Mitiga''#%%&o de Riscos
Estrutura de Triagem R''#%%&pida
Quando uma falha de autentica''#%%&o 802.1X ''#%%& relatada, a primeira pergunta de diagn''#%%&stico determina todo o caminho de solu''#%%&o de problemas: Isso est''#%%& afetando um ''#%%&nico usu''#%%&rio/dispositivo ou todos os usu''#%%&rios na rede?
Se a falha afetar todos os usu''#%%&rios simultaneamente, a causa raiz ''#%%& quase certamente no n''#%%&vel de infraestrutura: um certificado de servidor RADIUS expirado, uma queda do servidor RADIUS, uma diverg''#%%&ncia de segredo compartilhado ap''#%%&s uma altera''#%%&o de configura''#%%&o ou uma falha de conectividade entre o Autenticador e o servidor RADIUS. Comece verificando a disponibilidade do servidor RADIUS e a validade do certificado.
Se a falha afetar um ''#%%&nico usu''#%%&rio ou dispositivo, a causa raiz ''#%%& quase certamente no n''#%%&vel do cliente: um certificado de cliente expirado (EAP-TLS), uma configura''#%%&o incorreta do perfil do suplicante, credenciais incorretas ou um problema de software espec''#%%&fico do dispositivo. Comece verificando o reposit''#%%&rio de certificados do cliente e a configura''#%%&o do suplicante.
Conjunto de Ferramentas de Diagn''#%%&stico
As seguintes ferramentas s''#%%&o essenciais para a solu''#%%&o de problemas do 802.1X em diferentes componentes de infraestrutura.
| Ferramenta | Plataforma | Caso de Uso |
|---|---|---|
| NPS Event Log (Event IDs 6272/6273) | Windows Server | Sucesso/falha de autentica''#%%&o RADIUS com c''#%%&digos de motivo |
| WLAN-AutoConfig Operational Log | Windows Client | Falhas de troca EAP no lado do suplicante |
| CAPI2 Event Log | Windows Client | Falhas de valida''#%%&o de certificado |
debug radius authentication |
Cisco IOS/WLC | Depura''#%%&o de troca RADIUS no Autenticador |
radiusd -X |
FreeRADIUS | Sa''#%%&da completa de depura''#%%&o, incluindo negocia''#%%&o EAP |
| Wireshark (filtro EAPOL) | Qualquer | Captura de pacotes do lado do cliente de frames EAP |
| Wireshark (filtro EAP) | Qualquer | Captura de pacotes RADIUS do lado do servidor |
radtest |
Linux | Teste manual de autentica''#%%&o RADIUS |
Refer''#%%&ncia de C''#%%&digos de Motivo NPS
O Microsoft NPS Event ID 6273 (falha de autentica''#%%&o) inclui um C''#%%&digo de Motivo que identifica diretamente a causa da falha. Os c''#%%&digos mais significativos operacionalmente s''#%%&o:
| C''#%%&digo de Motivo | Descri''#%%&o | Prov''#%%&vel Causa Raiz |
|---|---|---|
| 16 | Falha na autentica''#%%&o devido a diverg''#%%&ncia de credenciais do usu''#%%&rio | Senha incorreta, certificado de cliente expirado ou falha na busca de diret''#%%&rio |
| 22 | O certificado do cliente expirou ou ainda n''#%%& v''#%%&lido | Expira''#%%&o do certificado do cliente - verifique a renova''#%%&o de certificado via MDM |
| 23 | Conta de usu''#%%&rio expirada | Expira''#%%&o de conta do AD - verifique o status da conta |
| 48 | A solicita''#%%&o de conex''#%%&o n''#%%&o correspondeu a nenhuma pol''#%%&tica configurada | Configura''#%%&o incorreta da pol''#%%&tica RADIUS - verifique as pol''#%%&ticas de rede do NPS |
| 66 | O usu''#%%&rio tentou usar um m''#%%&todo de autentica''#%%&o n''#%%&o habilitado na pol''#%%&tica de rede correspondente | Diverg''#%%&ncia de m''#%%&todo EAP entre cliente e servidor |
Mitiga''#%%&o de Riscos: O Desastre da Expira''#%%&o de Certificado
A interrupção de 802.1X mais comum e evitável é a expiração do certificado do servidor RADIUS. Em janeiro de 2025, uma grande rede de varejo sofreu uma interrupção total da rede de funcionários quando o certificado do servidor RADIUS expirou às 3h00 de uma segunda-feira. Às 9h00, mais de 300 terminais de ponto de venda em 45 lojas haviam perdido a conectividade de rede. O certificado tinha sido implantado dois anos antes sem nenhum monitoramento automatizado, e o lembrete de renovação foi esquecido durante uma reestruturação de equipe.
A mitigação é simples: implemente o monitoramento automatizado de expiração de certificados integrado à sua plataforma de alerta (PagerDuty, OpsGenie ou equivalente). Defina limites de alerta para 90, 60 e 30 dias. Atribua a renovação do certificado como uma responsabilidade nominal em seu runbook de operações de TI. Para plataformas RADIUS em nuvem, verifique se o provedor gerencia a renovação de certificados em seu nome - este é um diferencial fundamental entre ofertas gerenciadas e de autoatendimento.
ROI e Impacto nos Negócios
O Custo da Inatividade de Autenticação
Para operadores de locais físicos, as falhas de autenticação 802.1X se traduzem diretamente em um impacto comercial mensurável. Em ambientes de Hospitalidade, uma interrupção na rede de funcionários afeta os sistemas de gestão de propriedades, terminais de ponto de venda e a prestação de serviços aos hóspedes. No Varejo, as falhas de autenticação dos terminais de PDV interrompem completamente as transações. Em centros de conferências e estádios, as falhas de autenticação durante eventos de pico geram falhas de serviço imediatas e visíveis.
O custo operacional de uma interrupção de autenticação de 30 minutos em um hotel de 200 quartos - afetando o acesso ao PMS, o PDV do restaurante e os terminais da portaria - normalmente excede £5.000 em interrupção operacional direta, antes de contabilizar o impacto na experiência do hóspede e possíveis penalidades de SLA.
Valor de Conformidade
Para organizações dentro do escopo do PCI-DSS v4.0, uma infraestrutura 802.1X implantada corretamente atende diretamente a vários requisitos: Requisito 1 (controles de acesso à rede), Requisito 7 (restringir o acesso aos componentes do sistema), Requisito 8 (identificar usuários e autenticar o acesso) e Requisito 10 (registrar e monitorar todo o acesso). A alternativa - redes PSK compartilhadas - falha em todos os quatro requisitos e cria uma responsabilidade de auditoria significativa.
Para organizações do setor público e implantações de Saúde sujeitas a regulamentações de proteção de dados, a autenticação por usuário e os registros abrangentes de bilhetagem fornecem a trilha de auditoria necessária para demonstrar a conformidade com as obrigações de controle de acesso.
Medindo o Sucesso
Os principais indicadores de desempenho para uma implantação 802.1X bem-sucedida são: taxa de sucesso de autenticação (meta >99,5%), tempo médio de autenticação (<150ms para RADIUS em nuvem), incidentes de expiração de certificado (meta zero) e disponibilidade do servidor RADIUS (meta 99,9%). Essas métricas devem ser acompanhadas em sua plataforma de gerenciamento de rede e revisadas mensalmente como parte do ritmo de operações da sua rede.
Para organizações que utilizam o WiFi Analytics, a combinação de dados de sessão por usuário 802.1X com analytics fornece inteligência de negócios adicional: medição precisa do tempo de permanência, distribuição de tipos de dispositivos e padrões de utilização da rede que fundamentam o planejamento de capacidade e as decisões de operações do local.
Para leituras adicionais sobre soluções de controle de acesso à rede relacionadas, consulte 10 Best Network Access Control (NAC) Solutions for 2026 e Cisco Wireless APs: 2026 Guide to Products & Deployment. Para implantações em escolas e educação, WiFi in Schools: The 2026 Administrator & IT Guide aborda a implementação do 802.1X em ambientes educacionais multiusuário.
Definições principais
802.1X
O IEEE 802.1X é um padrão de controle de acesso à rede baseado em porta que define uma estrutura de autenticação que opera na Camada 2 do modelo OSI. Ele bloqueia todo o tráfego de rede de um dispositivo até que o servidor RADIUS o tenha autenticado positivamente, usando o EAP como protocolo de troca de credenciais. Aplica-se tanto a redes Ethernet cabeadas quanto a redes sem fio (WiFi).
As equipes de TI encontram o 802.1X como o mecanismo de autenticação para SSIDs WPA2-Enterprise e WPA3-Enterprise. É o padrão que permite autenticação por usuário, atribuição dinâmica de VLAN e a trilha de auditoria necessária para a conformidade com o PCI-DSS.
RADIUS (Remote Authentication Dial-In User Service)
Um protocolo de rede cliente-servidor (RFC 2865) que fornece gerenciamento centralizado de Autenticação, Autorização e Contabilização (AAA) para acesso à rede. Em implantações 802.1X, o servidor RADIUS valida as credenciais do usuário em um diretório de identidade e retorna respostas de Access-Accept ou Access-Reject para o autenticador. Ele opera nas portas UDP 1812 (autenticação) e 1813 (contabilização).
O servidor RADIUS é o componente de tomada de decisão no 802.1X. Quando a autenticação falha, os logs do servidor RADIUS contêm o código do motivo que identifica a causa raiz. Implementações comuns incluem Microsoft NPS, FreeRADIUS e serviços hospedados na nuvem.
EAP (Extensible Authentication Protocol)
Uma estrutura de protocolo (RFC 3748) que define um conjunto de métodos de autenticação usados no 802.1X. O EAP em si não é um método de autenticação, mas um contêiner que suporta múltiplos métodos internos, incluindo EAP-TLS, PEAP-MSCHAPv2, EAP-TTLS e EAP-FAST. O método EAP é negociado entre o Supplicant e o servidor RADIUS; o Authenticator retransmite os quadros EAP sem interpretá-los.
A seleção do método EAP determina a postura de segurança e a complexidade operacional da implantação. O EAP-TLS exige uma infraestrutura de PKI e MDM, mas fornece a segurança mais robusta. O PEAP-MSCHAPv2 é mais simples de implantar, mas exige uma validação rigorosa de certificados para evitar o roubo de credenciais.
Supplicant
O componente de software no dispositivo do usuário final (notebook, smartphone, terminal de PDV) que inicia a troca de autenticação 802.1X. No Windows, o supplicant é integrado ao sistema operacional como o serviço WLAN AutoConfig ou Wired AutoConfig. No iOS e Android, ele é gerenciado por meio da configuração do perfil de WiFi do dispositivo.
A configuração incorreta do supplicant - particularmente a validação de certificado desativada em implantações PEAP - é uma das fontes mais comuns de falhas de autenticação e de vulnerabilidades de segurança. Padronizar a configuração do supplicant via MDM é um controle operacional crítico.
Authenticator
O dispositivo de rede (ponto de acesso sem fio ou switch gerenciado) que impõe o controle de acesso baseado em porta em uma implantação 802.1X. O Authenticator não toma decisões de autenticação - ele age como um retransmissor entre o Supplicant (usando EAPOL) e o servidor RADIUS (usando RADIUS). Ele bloqueia todo o tráfego não EAP na porta controlada até que o servidor RADIUS emita um Access-Accept.
A configuração do Authenticator - especificamente o IP/hostname do servidor RADIUS, o segredo compartilhado e as configurações de timeout - é uma fonte comum de falhas. Após alterações na infraestrutura, sempre verifique se a configuração do cliente RADIUS do Authenticator corresponde à configuração do cliente NAS do servidor RADIUS.
EAPOL (EAP over LAN)
O protocolo usado para transportar quadros EAP entre o Supplicant e o Authenticator pelo meio cabeado ou sem fio. Os quadros EAPOL são quadros de Camada 2 (tipo Ethernet 0x888E) e não requerem conectividade IP. O Authenticator encapsula os quadros EAPOL em pacotes RADIUS para encaminhamento ao Servidor de Autenticação.
O EAPOL é visível em capturas do Wireshark do lado do cliente. Filtrar quadros EAPOL em uma captura de pacotes sem fio permite que os engenheiros observem a troca EAP e identifiquem em qual etapa a autenticação falha.
RadSec (RADIUS over TLS)
Uma extensão do protocolo RADIUS (RFC 6614) que encapsula pacotes RADIUS em um túnel TLS sobre a porta TCP 2083. O RadSec fornece segurança de transporte para o tráfego RADIUS que atravessa redes não confiáveis (como a internet pública para um servidor RADIUS na nuvem), elimina problemas de fragmentação UDP e remove a dependência de segredos compartilhados para autenticação de pacotes.
O RadSec é o transporte recomendado para implantações de RADIUS na nuvem. Ele resolve dois modos de falha comuns simultaneamente: a fragmentação de MTU que causa falhas no handshake EAP-TLS e a complexidade do gerenciamento de segredos compartilhados em sites distribuídos.
Atribuição Dinâmica de VLAN
Um recurso de autorização RADIUS que permite ao servidor RADIUS instruir o autenticador a colocar um dispositivo autenticado em uma VLAN específica, com base na associação de grupo do usuário ou no tipo de dispositivo. O servidor RADIUS retorna atributos de atribuição de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID) na resposta Access-Accept.
A atribuição dinâmica de VLAN é o mecanismo que força a segmentação de rede em implantações 802.1X. É um controle obrigatório para a conformidade PCI-DSS (isolando o Ambiente de Dados de Portadores de Cartão) e um pilar da arquitetura de rede Zero Trust. Atributos de VLAN configurados incorretamente em políticas RADIUS são uma causa comum de usuários serem alocados no segmento de rede errado após a autenticação.
MAC Authentication Bypass (MAB)
Um mecanismo de autenticação de fallback que permite que dispositivos sem suplicantes 802.1X se autentiquem usando seu endereço MAC tanto como nome de usuário quanto como senha em uma troca RADIUS. Como os endereços MAC podem ser clonados, o MAB oferece garantia mínima de segurança e deve ser usado apenas para dispositivos que genuinamente não conseguem suportar o 802.1X.
O MAB é comumente necessário para dispositivos IoT legados, terminais de PDV mais antigos e impressoras de rede. Os dispositivos autenticados via MAB devem ser colocados em uma VLAN altamente restrita com regras de firewall explícitas. Nunca use o MAB como um atalho de conveniência para dispositivos que poderiam suportar o 802.1X.
NPS (Network Policy Server)
A implementação da Microsoft de um servidor RADIUS, incluída no Windows Server. O NPS suporta PEAP-MSCHAPv2, EAP-TLS e EAP-TTLS, e integra-se nativamente com o Active Directory para validação de credenciais. As falhas de autenticação são registradas no log de eventos de Segurança do Windows como ID de Evento 6273 (falha) e 6272 (sucesso), com códigos de motivo que identificam a causa específica da falha.
O NPS é o servidor RADIUS mais amplamente implantado em ambientes corporativos baseados em Windows. O log de eventos de Segurança no servidor NPS é a principal ferramenta de diagnóstico para falhas de 802.1X nesses ambientes. Certifique-se de que a política de auditoria do NPS esteja habilitada para eventos de sucesso e falha.
Exemplos práticos
Um grupo hoteleiro de 450 quartos com 12 propriedades implantou WPA2-Enterprise com PEAP-MSCHAPv2 em todos os sites, usando um servidor Windows NPS local em cada localidade. Após uma atualização da infraestrutura de rede, a equipe de TI relata que os funcionários em três sites não conseguem se autenticar no SSID corporativo. Os hóspedes na rede do Captive Portal não foram afetados. Os servidores NPS nos sites afetados estão funcionando e o log de eventos de segurança do Windows mostra o Event ID 6273 com o Reason Code 16. Qual é a causa mais provável e como a equipe deve resolvê-la?
O Reason Code 16 no NPS Event ID 6273 indica uma falha de autenticação devido a uma incompatibilidade de credenciais - mas, no contexto de uma interrupção pós-atualização de infraestrutura que afeta vários sites simultaneamente, a causa mais provável não são senhas de usuário incorretas, mas sim uma incompatibilidade de segredo compartilhado RADIUS entre os pontos de acesso recém-configurados ou o controlador sem fio e os servidores NPS.
Passo 1: No servidor NPS de um dos sites afetados, navegue até Clientes e Servidores RADIUS > Clientes RADIUS e verifique o segredo compartilhado configurado para cada AP ou endereço IP do controlador sem fio. Compare isso com a configuração do servidor RADIUS no AP/controlador.
Passo 2: Se os segredos compartilhados coincidirem, verifique se a Diretiva de Rede do NPS está configurada corretamente para permitir PEAP-MSCHAPv2. Navegue até Diretivas > Diretivas de Rede, abra a diretiva relevante e verifique se o Microsoft: Protected EAP (PEAP) está listado como um método de autenticação permitido com o EAP-MSCHAPv2 como o método interno.
Passo 3: Se a diretiva estiver correta, verifique a Diretiva de Solicitação de Conexão do NPS para confirmar se a solicitação está sendo processada localmente (não encaminhada para um servidor RADIUS remoto). Verifique se as condições coincidem com os atributos RADIUS recebidos do novo hardware do AP.
Passo 4: Habilite a depuração de contabilidade RADIUS no AP/controlador e verifique se os pacotes Access-Request estão sendo enviados para o IP correto do servidor NPS e para a porta 1812. Se nenhuma solicitação estiver chegando ao servidor NPS, o problema está na configuração do Autenticador, e não no servidor RADIUS.
Passo 5: Se as solicitações estiverem chegando ao NPS, mas forem rejeitadas com o Reason Code 16, e as credenciais forem confirmadas como corretas, verifique se o controlador de domínio do Active Directory está acessível a partir do servidor NPS. Um problema de DNS ou de conectividade com o DC fará com que o NPS falhe na validação de credenciais com esse código de motivo.
Resolução: Na maioria dos cenários pós-atualização, a causa raiz é uma incompatibilidade de segredo compartilhado introduzida quando o novo hardware do AP foi configurado. Sincronize o segredo compartilhado em todos os clientes RADIUS e servidores NPS. Considere a migração para o RadSec para eliminar completamente o gerenciamento de segredos compartilhados.
Uma grande rede de varejo que opera 85 lojas implantou o EAP-TLS com certificados de cliente gerenciados via Microsoft Intune. Na manhã de uma segunda-feira, o helpdesk de TI recebe uma enxurrada de relatórios dos gerentes das lojas informando que os dispositivos dos funcionários não conseguem se conectar à rede WiFi corporativa. O problema afeta todas as lojas simultaneamente. Os logs do servidor RADIUS mostram respostas do tipo Access-Reject com a mensagem 'TLS Alert: certificate expired'. O próprio servidor RADIUS está operando normalmente e seu próprio certificado é válido por mais 18 meses. O que aconteceu e qual é o caminho de correção imediata?
A mensagem 'TLS Alert: certificate expired' nos logs do servidor RADIUS, combinada com o fato de que a falha ocorre simultaneamente em todas as 85 lojas e o certificado do servidor RADIUS é válido, indica que os certificados de cliente implantados nos dispositivos dos funcionários expiraram. No EAP-TLS, tanto o cliente quanto o servidor apresentam certificados. Se o certificado do cliente expirou, o servidor RADIUS rejeitará o handshake TLS e emitirá um Access-Reject.
Correção Imediata (0 - 2 horas):
Passo 1: Confirme o diagnóstico verificando a data de expiração do certificado em um dispositivo afetado. No Windows, abra o certmgr.msc, navegue até Pessoal > Certificados e verifique a data de expiração do certificado de autenticação WiFi. Se estiver expirado, isso confirma a causa raiz.
Passo 2: No Microsoft Intune, navegue até Dispositivos > Perfis de Configuração e localize o perfil de certificado SCEP ou PKCS usado para autenticação WiFi. Verifique o período de validade do certificado e as configurações de limite de renovação.
Passo 3: Se o perfil de certificado estiver configurado para renovar automaticamente, verifique se os dispositivos conseguiram se conectar ao serviço de gerenciamento do Intune recentemente. Se os dispositivos estavam offline ou sem registro, a renovação automática pode não ter ocorrido.
Passo 4: Force uma renovação de certificado acionando uma sincronização de dispositivo no Intune (Dispositivos > Todos os Dispositivos > Sincronizar). Para dispositivos que não conseguem se conectar ao WiFi, certifique-se de que eles tenham um caminho de conectividade alternativo (dados móveis ou Ethernet com fio) para alcançar o serviço do Intune para a renovação.
Passo 5: Como medida temporária enquanto os certificados estão sendo renovados, considere a criação de um SSID temporário PEAP-MSCHAPv2 para as lojas afetadas para restaurar a capacidade operacional. Isso deve ser tratado como uma ponte temporária, não como uma solução permanente.
Prevenção de Longo Prazo:
Configure os perfis de certificado do Intune para renovar quando restar 20% do tempo de vida do certificado (por exemplo, para um certificado de 1 ano, renovar aproximadamente 73 dias antes da expiração). Implemente alertas SIEM em eventos RADIUS Access-Reject com códigos de motivo de expiração de certificado. Adicione o monitoramento de expiração de certificados à sua revisão mensal de operações de TI.
Questões práticas
Q1. Sua organização opera um estádio de 60.000 assentos com 800 pontos de acesso implantados em áreas de circulação, suítes de hospitalidade e bastidores. Os dispositivos da equipe usam EAP-TLS com certificados gerenciados via Jamf. Durante um grande evento, 15% dos dispositivos da equipe em várias zonas relatam falhas de autenticação. Os logs do servidor RADIUS mostram respostas Access-Reject. Os 85% restantes da equipe estão se autenticando normalmente. Qual é a sua abordagem de diagnóstico e qual é a causa raiz mais provável?
Dica: O padrão de falha parcial (15% dos dispositivos, não todos) é o principal sinal de diagnóstico. Concentre-se no que diferencia os dispositivos que falham dos que têm sucesso - modelo do dispositivo, versão do SO, data de emissão do certificado ou status de registro no Jamf.
Ver resposta modelo
O padrão de falha parcial descarta imediatamente causas em nível de infraestrutura (expiração do certificado do servidor RADIUS, incompatibilidade de segredo compartilhado ou inatividade do servidor afetariam todos os dispositivos). A causa raiz é quase certamente um subconjunto de certificados de cliente que expiraram ou falharam na renovação.
Abordagem de diagnóstico: Extraia os logs do servidor RADIUS e filtre por eventos Access-Reject. Observe as identidades dos dispositivos (CNs dos certificados ou endereços MAC) dos dispositivos com falha. No Jamf, cruze a referência desses dispositivos com o status de implantação do perfil de certificado. Verifique se os dispositivos com falha compartilham uma data comum de emissão de certificado - se todos foram registrados no mesmo lote, podem ter a mesma data de expiração.
Causa raiz mais provável: Um lote de certificados de cliente emitidos ao mesmo tempo expirou. Os dispositivos registrados mais recentemente possuem certificados válidos e estão se autenticando normalmente.
Resolução: No Jamf, identifique os dispositivos afetados e acione um push de renovação de certificado. Certifique-se de que o perfil de certificado esteja configurado com um limite de renovação adequado (20% do tempo de vida do certificado). Para dispositivos que não conseguem alcançar o serviço MDM Jamf via WiFi (porque não conseguem se autenticar), forneça uma conexão temporária de rede Ethernet cabeada ou um SSID PEAP temporário durante o evento. Após o evento, implemente alertas de SIEM para eventos RADIUS Access-Reject com códigos de motivo de expiração de certificado para evitar recorrências.
Q2. Uma rede regional de varejo com 35 lojas está migrando de servidores NPS locais para um serviço de RADIUS em nuvem. Durante o piloto em três lojas, a autenticação EAP-TLS funciona corretamente em duas lojas, mas falha de forma intermitente na terceira. A terceira loja se conecta ao serviço de RADIUS em nuvem por meio de um link de WAN MPLS. As falhas de autenticação não são consistentes - algumas tentativas são bem-sucedidas, outras falham. O provedor de RADIUS em nuvem confirma que o serviço está íntegro e os logs mostram que alguns pacotes Access-Request chegam, mas nenhum Access-Accept correspondente é enviado. Qual é a causa mais provável?
Dica: Falhas intermitentes em um site específico conectado por WAN, combinadas com o provedor de RADIUS em nuvem visualizando alguns pacotes, mas não todos, sugerem fortemente um problema de trânsito de rede em vez de um erro de configuração.
Ver resposta modelo
A combinação de falhas intermitentes em um site conectado via WAN e o provedor de RADIUS em nuvem visualizando sequências incompletas de pacotes é uma assinatura clássica de fragmentação de MTU. As cadeias de certificados EAP-TLS produzem pacotes RADIUS grandes que podem exceder a MTU do link de WAN MPLS. Quando esses pacotes são fragmentados, o servidor RADIUS em nuvem pode receber o primeiro fragmento, mas não os fragmentos subsequentes, fazendo com que o handshake TLS trave e, eventualmente, expire o tempo limite (timeout).
Confirmação de diagnóstico: Realize uma captura do Wireshark na interface WAN na loja afetada. Filtre pelo tráfego UDP na porta 1812. Procure por pacotes IP fragmentados na troca RADIUS. Compare o tamanho dos pacotes nas lojas bem-sucedidas com os da loja com falha.
Opção de resolução 1 (preferencial): Migre o site afetado para RadSec (RADIUS sobre TLS na porta TCP 2083). O TCP lida com fragmentação e retransmissão de forma nativa, eliminando completamente esse modo de falha. A maioria dos provedores de RADIUS em nuvem e fornecedores modernos de AP oferece suporte ao RadSec.
Opção de resolução 2: Reduza a MTU na interface WAN da loja afetada para corresponder à MTU do caminho MPLS, garantindo que os pacotes RADIUS não sejam fragmentados. Esta é uma solução menos elegante, pois afeta todo o tráfego no link de WAN.
Opção de resolução 3: Configure o servidor RADIUS para usar tamanhos de registro TLS menores para reduzir a fragmentação de pacotes. Esta é uma opção de configuração no lado do servidor disponível em algumas implementações de RADIUS.
Recomendação de longo prazo: Migre todos os sites para RadSec como parte da implementação do RADIUS em nuvem. Isso elimina o risco de fragmentação, criptografa o tráfego RADIUS em trânsito e elimina a complexidade do gerenciamento de segredos compartilhados.
Q3. O diretor de TI de um centro de convenções está planejando uma atualização de rede para suportar WPA3-Enterprise com 802.1X para a equipe e um Captive Portal para os participantes dos eventos. O local sedia mais de 200 eventos por ano, com o número de participantes variando de 50 a 5.000. A equipe de TI possui experiência em redes limitada internamente e não possui infraestrutura de PKI. O diretor deseja implementar o 802.1X para a equipe, mas está preocupado com a complexidade operacional. Qual método EAP deve ser recomendado, qual infraestrutura é necessária e quais são os principais riscos operacionais a serem mitigados?
Dica: Considere as restrições operacionais: experiência interna limitada, ausência de PKI existente e a necessidade de uma solução que possa ser mantida de forma confiável. Equilibre os requisitos de segurança com a viabilidade operacional.
Ver resposta modelo
Dadas as restrições operacionais - experiência interna limitada e ausência de PKI existente - o método EAP recomendado para a autenticação da equipe é o PEAP-MSCHAPv2, e não o EAP-TLS. Embora o EAP-TLS ofereça segurança superior, ele exige uma infraestrutura de PKI e uma plataforma de MDM para distribuição de certificados. Sem isso, a implantação do EAP-TLS traz um risco operacional significativo: o gerenciamento de expiração de certificados torna-se um processo manual, e a equipe não possui a experiência necessária para solucionar problemas de cadeia de certificados sob pressão.
O PEAP-MSCHAPv2 integra-se diretamente ao Active Directory (ou Azure AD), exige apenas um certificado no lado do servidor e é operacionalmente gerenciável por uma equipe sem profunda experiência em PKI. O compromisso de segurança é aceitável, desde que a validação do certificado do servidor seja rigorosamente aplicada em todos os dispositivos clientes - este é o controle inegociável que evita a coleta de credenciais por meio de pontos de acesso falsos.
Infraestrutura necessária: Um serviço de RADIUS na nuvem (para evitar o gerenciamento de servidores locais), um certificado de servidor de uma CA pública confiável para o serviço RADIUS, uma solução de MDM (Microsoft Intune ou equivalente) para implantar perfis de WiFi nos dispositivos da equipe, e o Active Directory ou Azure AD como diretório de identidades.
Principais riscos operacionais a serem mitigados:
Validação de certificado desativada nos clientes: Implante todos os perfis de WiFi via MDM com a validação de certificado ativada. Nunca permita a configuração manual de perfis de WiFi nos dispositivos da equipe.
Expiração do certificado do servidor RADIUS: Configure o monitoramento automatizado com alertas de 90 dias. Com um serviço de RADIUS na nuvem, verifique se o provedor gerencia a renovação do certificado - este é um critério de seleção fundamental.
Capacidade durante grandes eventos: Garanta que o serviço RADIUS na nuvem seja dimensionado para a carga máxima de autenticação simultânea. Durante um evento de 5.000 participantes, se os dispositivos da equipe se autenticarem simultaneamente (por exemplo, após uma reinicialização de rede), o serviço RADIUS deve suportar o pico de acessos.
Separação de rede de convidados/equipe: Certifique-se de que a rede de convidados com Captive Portal e a rede da equipe com 802.1X estejam em VLANs separadas, com regras de firewall apropriadas entre elas. Este é um requisito do PCI-DSS se algum dispositivo da rede da equipe processar dados de cartões de pagamento.
Continue a ler esta série
Como revogar o acesso WiFi quando um funcionário sai da empresa
Este guia mostra às equipes de TI e operações de locais físicos como remover o acesso de funcionários ao WiFi quando um colaborador se desliga, sem interromper o restante da força de trabalho. Ele compara 802.1X baseado em certificados, iPSK específico por identidade e desprovisionamento direcionado por SCIM, fornecendo em seguida um roteiro de execução para o mesmo dia, método de teste e modelo de evidência de auditoria.
Planejando uma implantação de WiFi 7 em um ambiente clínico: dispositivos IoMT, interferência e HIPAA
Este guia abrangente explora o planejamento de uma implantação de WiFi 7 em um ambiente clínico, concentrando-se na estratégia de banda de 6 GHz, compatibilidade com dispositivos IoMT legados, obrigações de interferência de RF da IEC 60601-1-2 e segmentação de rede alinhada à HIPAA. Ele fornece conselhos práticos de arquitetura para líderes de TI de saúde protegerem frotas mistas de dispositivos usando a plataforma de RADIUS em nuvem da Purple.
Como Segmentar Redes WiFi de Funcionários e Convidados com Segurança: Melhores Práticas para LANs Corporativas
Este guia fornece aos gerentes de TI e arquitetos de rede um modelo técnico e neutro em relação a fornecedores para proteger LANs corporativas por meio da segmentação adequada do tráfego WiFi de funcionários e convidados. O conteúdo aborda autenticação 802.1X, RADIUS em nuvem, isolamento de VLAN e o gerenciamento do ciclo de vida de credenciais necessário para eliminar senhas compartilhadas e proteger os ativos corporativos.
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 locais. Agende uma chamada de 20 minutos e mostraremos como outros profissionais na sua situação o resolveram.