Implementação de Certificados WiFi no Microsoft Intune via SCEP e PKCS

A implementação de certificados WiFi do Intune utiliza três perfis: um certificado de raiz confiável, um certificado de cliente SCEP ou PKCS e um perfil WiFi 802.1X configurado para EAP-TLS. Implemente-os nessa ordem, todos atribuídos ao mesmo grupo do Microsoft Entra ID. O SCEP cria a chave privada no dispositivo, enquanto o PKCS a cria de forma centralizada. Para WiFi em Windows, iOS e Android, escolha SCEP.

O que faz realmente a implementação de certificados WiFi do Intune?

O Intune fornece a cada dispositivo gerido o seu próprio certificado de identidade e as definições de WiFi para o apresentar. O dispositivo junta-se depois à rede dos seus colaboradores sem que ninguém precise de introduzir uma palavra-passe.

O mecanismo é o IEEE 802.1X, o padrão para controlo de acesso à rede baseado em portas. No âmbito do 802.1X, o ponto de acesso mantém o dispositivo fora da rede até que um servidor de autenticação o aprove. Esse servidor é um servidor RADIUS, o serviço que os seus pontos de acesso consultam antes de permitirem a entrada de um dispositivo.

O método de autenticação é o EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido na RFC 5216. Ambas as partes provam a sua identidade com certificados:

• O dispositivo apresenta um certificado de cliente.
• O servidor RADIUS apresenta um certificado de servidor.
• Cada uma das partes verifica se o certificado da outra encadeia numa autoridade de certificação (CA) em que confia.

Nenhuma palavra-passe é digitada, armazenada ou exposta a phishing.

Isto ganha mais importância a cada ano. A Microsoft documenta que o Windows Defender Credential Guard bloqueia o início de sessão único para métodos 802.1X baseados em palavra-passe, tais como o PEAP-MSCHAPv2. O PEAP (Protected EAP) envia uma palavra-passe dentro de um túnel encriptado. O Credential Guard está ativo por predefinição nas compilações recentes do Windows 11 Enterprise, e a Microsoft recomenda a autenticação baseada em certificados como alternativa.

O Intune disponibiliza WiFi baseado em certificados através de três perfis de configuração:

• Perfil de certificado confiável. Instala a sua CA de raiz e qualquer CA intermédia. O dispositivo pode então confiar na sua própria cadeia de certificados e no seu servidor RADIUS.
• Perfil de certificado SCEP ou PKCS. Emite para cada dispositivo um certificado de cliente exclusivo.
• Perfil WiFi. Define o SSID (o nome da rede transmitida), o tipo de segurança e o método EAP. Também especifica o certificado a apresentar e o servidor em que deve confiar.

Para os operadores do local, esta é a vertente da rede destinada aos colaboradores. Os portáteis, leitores portáteis e tablets da equipa em Hotéis, Comércio e Saúde precisam de aceder a sistemas aos quais os convidados, clientes e pacientes nunca devem ter acesso. O seu Guest WiFi mantém o seu Captive Portal, a página de início de sessão que os visitantes veem. Os dispositivos dos colaboradores autenticam-se de forma silenciosa num SSID e numa VLAN separados, um segmento de rede isolado logicamente.

SCEP ou PKCS: qual o perfil de certificado que deve utilizar?

Ambos os perfis deixam um certificado de cliente no dispositivo. A diferença reside no local onde a chave privada é criada.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) faz com que o dispositivo gere o seu próprio par de chaves. O dispositivo envia um pedido de assinatura de certificado através de um servidor Network Device Enrolment Service (NDES) ou através do Microsoft Cloud PKI. A CA assina o pedido e devolve o certificado. A chave privada nunca sai do dispositivo. Em Windows, o perfil SCEP pode colocar essa chave no Trusted Platform Module (TPM), o chip de segurança de hardware.

Os perfis PKCS utilizam o Certificate Connector for Microsoft Intune para solicitar o certificado à sua CA. O par de chaves é criado fora do dispositivo. O Intune entrega depois o certificado e a chave privada ao dispositivo de forma encriptada. Evita a execução do NDES, mas a chave privada já existiu em algum local fora do dispositivo.

Um terceiro tipo, certificados importados PKCS, entrega certificados que já possui. A sua função habitual é a encriptação de e-mail S/MIME, onde as chaves são mantidas em custódia. É a ferramenta errada para WiFi.

	SCEP via NDES e AD CS	SCEP via Microsoft Cloud PKI	PKCS via conetor e AD CS
Onde a chave privada é criada	No dispositivo	No dispositivo	Fora do dispositivo, depois entregue
Autoridade de certificação	A sua CA empresarial do Active Directory Certificate Services (AD CS)	CAs alojadas pela Microsoft, ou a sua própria raiz	A sua CA empresarial do AD CS
Servidores locais que executa	CA, servidor NDES, Certificate Connector	Nenhum	CA, Certificate Connector
Componente voltado para a internet	URL do NDES, publicado através do proxy de aplicações do Microsoft Entra ID	Nenhum: a Microsoft aloja o ponto de extremidade SCEP	Nenhum: o conetor liga-se apenas para o exterior
Licença extra	Nenhuma além do Windows Server	Add-on Cloud PKI ou Microsoft Intune Suite	Nenhuma além do Windows Server
Esforço de configuração	Mais elevado: CA, NDES, conetor e publicação de proxy	Mais baixo: CAs criadas no centro de administração do Intune	Médio: CA e conetor, sem NDES
A quem se adequa	Ambientes com AD CS que pretendem manter as chaves no dispositivo	Ambientes cloud-first sem PKI local	Ambientes com AD CS que não podem publicar um ponto de extremidade NDES

Para WiFi, escolha SCEP a menos que não consiga satisfazer as suas necessidades de infraestrutura. Uma chave que nunca sai do dispositivo não pode ser copiada de um servidor nem intercetada em trânsito. Escolha o Microsoft Cloud PKI se não tiver uma PKI local e não quiser construir uma. Escolha PKCS se executar o AD CS, mas não puder publicar um ponto de extremidade NDES para a internet.

O que precisa antes de implementar certificados WiFi com o Intune?

Confirme cada item antes de criar um único perfil. A maioria das implementações mal-sucedidas deve-se a uma lacuna nesta lista.

• Licenciamento. Cada pessoa precisa de uma licença do Intune. O Intune está incluído no Microsoft 365 E3, E5 e Business Premium, e no Enterprise Mobility + Security E3 e E5.
• Dispositivos registados. Os dispositivos Windows estão associados ao Microsoft Entra ID, frequentemente através do Windows Autopilot. Os dispositivos iOS e iPadOS são registados através do registo automatizado de dispositivos do Apple Business Manager. Os dispositivos Android utilizam o Android Enterprise. A Microsoft descontinuou a gestão de administradores de dispositivos para equipamentos com Google Mobile Services, por isso planeie utilizar o Android Enterprise.
• Uma autoridade de certificação (CA). Isto significa uma CA empresarial AD CS, Microsoft Cloud PKI ou uma CA de terceiros suportada pelo Intune.
• Um modelo de certificado. No AD CS, publique um modelo com a utilização expandida de chave "Autenticação do Cliente".
• Infraestrutura de conectores. O SCEP no AD CS necessita de um servidor NDES e do Certificate Connector for Microsoft Intune. O PKCS precisa apenas do conector.
• Um servidor RADIUS que suporte EAP-TLS. O seu certificado de servidor deve estar associado a uma raiz que irá implementar. Registe o nome exato desse certificado, pois o perfil de WiFi irá necessitar dele.
• Revogação acessível. O seu servidor RADIUS deve conseguir aceder à lista de revogação de certificados (CRL) ou a um reponder OCSP (Online Certificate Status Protocol). Se não conseguir, a autenticação falha.
• SSIDs empresariais. Os seus pontos de acesso devem transmitir um SSID WPA2-Enterprise ou WPA3-Enterprise apontado para o seu servidor RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet suportam todos 802.1X.
• Grupos do Entra ID. Crie um grupo piloto e um grupo de produção. Decida agora se vão conter pessoas ou dispositivos.
• Uma rede de arranque (bootstrap). Um dispositivo precisa de acesso à internet para recolher o seu certificado antes de se poder associar ao SSID 802.1X. Forneça acesso por cabo, dados móveis ou um SSID de integração isolado. Os operadores de Comboios que fornecem tablets à equipa a bordo devem configurá-los no depósito, antes de os tablets entrarem em circulação.

Como configurar certificados WiFi SCEP ou PKCS no Intune?

A documentação do Intune da Microsoft contém os passos detalhados para cada plataforma. A sequência e as decisões abaixo são o que determina o sucesso. Crie um conjunto de perfis por plataforma: Windows, iOS/iPadOS e Android Enterprise.

Passo 1: implementar o perfil de certificado de raiz confiável

Exporte o seu certificado CA de raiz como um ficheiro .cer. Crie um perfil de certificado confiável que o contenha. Cada perfil de certificado confiável contém um certificado, por isso crie perfis separados para a raiz e para cada CA intermédia.

No Windows, envie a raiz para o repositório de raiz do computador e as intermédias para o repositório intermédio. Se uma CA diferente assinou o certificado do seu servidor RADIUS, implemente também essa raiz. Sem ela, os dispositivos não conseguem validar o servidor.

Passo 2: implementar o perfil de certificado SCEP ou PKCS

Comece pelo tipo de certificado, pois este condiciona tudo o resto.

• Os certificados de dispositivo adequam-se a dispositivos partilhados, quiosques e portáteis que se devem ligar no ecrã de início de sessão do Windows. Utilize um nome de assunto construído a partir do identificador do dispositivo, como CN={{AAD_Device_ID}}.
• Os certificados baseados na pessoa adequam-se a telemóveis e computadores portáteis atribuídos a um membro da equipa. Utilize CN={{UserPrincipalName}} no assunto. Adicione o mesmo valor como um nome alternativo do assunto, porque muitos servidores RADIUS leem a identidade a partir daí.

Em seguida, defina os restantes campos:

• Utilização da chave: assinatura digital e cifragem de chaves.
• Utilização expandida da chave: Autenticação do Cliente, OID 1.3.6.1.5.5.7.3.2.
• Tamanho da chave: 2048 bits no mínimo.
• Validade: não superior ao permitido pelo seu modelo de CA.
• Limite de renovação: o valor predefinido da Microsoft é 20% do tempo de vida restante do certificado.
• Certificado de raiz: selecione o perfil de certificado de confiança do passo 1.
• Armazenamento de chaves no Windows: escolha a opção TPM para chaves suportadas por hardware.

Para SCEP, introduza o URL do NDES externo ou o seu URI SCEP de Cloud PKI. Para PKCS, introduza o nome da CA e o nome do modelo.

Se utilizar o Microsoft NPS (Network Policy Server) com identidades híbridas, leia o artigo KB5014754 da Microsoft sobre o mapeamento forte de certificados. A Microsoft documenta um URI de nome alternativo do assunto que transporta o identificador de segurança no local exatamente para este caso.

Passo 3: implementar o perfil de WiFi 802.1X

Crie um perfil de WiFi empresarial com estas definições:

• Introduza o SSID exatamente como os seus pontos de acesso o transmitem.
• Defina o tipo de segurança para WPA2-Enterprise, ou WPA3-Enterprise onde os seus pontos de acesso e a plataforma o suportem.
• Defina o tipo de EAP para EAP-TLS.
• Introduza nomes de servidores de certificados que correspondam ao nome no seu certificado de servidor RADIUS. Isto impede que os dispositivos entreguem a sua identidade a um ponto de acesso não autorizado.
• Selecione o perfil do passo 1 como o certificado de raiz para validação do servidor.
• Selecione o perfil do passo 2 como o certificado de autenticação do cliente.

O que difere no Windows, iOS e Android?

• O Windows liga-se com um certificado de dispositivo antes de qualquer pessoa iniciar sessão. Um certificado baseado na pessoa liga-se apenas após o início de sessão, o que interrompe o primeiro início de sessão em portáteis partilhados.
• O iOS e iPadOS confiam no servidor RADIUS ao corresponder aos nomes dos servidores de certificados que introduzir. Uma divergência produz uma falha de confiança e não uma regressão silenciosa.
• O Android Enterprise requer um nome de domínio de servidor RADIUS e um certificado de raiz para validação. As versões recentes do Android removeram a opção de ignorar a validação do servidor.

O que acontece quando um novo dispositivo é inscrito?

Esta é a sequência de implementação de certificados num dispositivo recém-inscrito:

1. O dispositivo inscreve-se e fica no seu grupo do Microsoft Entra ID atribuído.
2. O Intune entrega os perfis intermédios e de raiz de confiança.
3. O dispositivo solicita o seu certificado de cliente. No SCEP, gera um par de chaves e envia um pedido de assinatura com um desafio de utilização única. O conector valida esse desafio com o Intune antes de a CA emitir qualquer elemento. No PKCS, o conector solicita o certificado e o Intune entrega-o.
4. O dispositivo comunica o certificado instalado ao Intune.
5. O perfil de WiFi, que depende de ambos os perfis de certificado, é aplicado.
6. O dispositivo apresenta o seu certificado ao SSID. O RADIUS valida a cadeia, verifica a revogação e aceita o dispositivo. Pode depois atribuir uma VLAN através de atributos RADIUS.
7. O Intune renova o certificado quando este atinge o limite de renovação. O Intune revoga-o quando desativa ou limpa o dispositivo, desde que o conector tenha direitos de revogação na CA.

Como verificar se os certificados WiFi do Intune estão a funcionar?

Testar com um piloto de 10 a 20 dispositivos por plataforma antes de alargar as atribuições. Verificar em quatro locais.

1. Estado do perfil do Intune. Cada um dos três perfis deve reportar Sucesso para todos os dispositivos do piloto. Um estado de Pendente, Erro ou Não aplicável em qualquer um deles bloqueia o perfil WiFi.
2. O próprio dispositivo. No Windows, abrir o repositório de certificados pessoais e confirmar a finalidade de Autenticação do Cliente e a sua CA emissora. No iOS e Android, confirmar que o certificado e o perfil WiFi aparecem no perfil de gestão e nas credenciais do perfil de trabalho.
3. Registos RADIUS. Procurar autenticações EAP-TLS bem-sucedidas com o nome de assunto esperado. No NPS, o ID de evento 6272 regista o acesso concedido e o 6273 regista o acesso negado, com um código de motivo.
4. Registos do conector e NDES. O Certificate Connector escreve no registo de eventos do Windows. Os pedidos NDES aparecem nos registos do IIS.

Depois, testar a revogação intencionalmente. Desativar um dispositivo piloto no Intune e confirmar que o certificado é exibido como revogado na CA. Publicar a CRL e confirmar que o RADIUS nega a autenticação seguinte.

O que corre mal com os perfis WiFi do Intune e como resolver?

O perfil WiFi apresenta Erro ou Não aplicável

Os certificados chegaram, mas o perfil WiFi falhou. A causa habitual é o direcionamento para grupos mistos. Por exemplo, o perfil SCEP é atribuído a um grupo de pessoas, enquanto o perfil WiFi é direcionado para um grupo de dispositivos. O Intune não consegue resolver a dependência. A solução consiste em atribuir os três perfis ao mesmo grupo, ou pelo menos ao mesmo tipo de grupo.

O certificado SCEP nunca chega

Os registos do IIS NDES mostram respostas HTTP 403 ou 500. Verificar se a conta de serviço do conector tem permissões de Leitura e Inscrição no modelo de certificado. Verificar se a sua firewall, proxy inverso ou proxy de aplicação não está a remover cadeias de consulta SCEP, tais como operation=GetCACaps. Em seguida, confirmar se o URL externo do NDES é resolvido a partir de fora da sua rede.

O dispositivo tem um certificado, mas o RADIUS rejeita-o

Analisar quatro causas por ordem:

1. Os nomes dos servidores de certificados no perfil WiFi não coincidem com o certificado do servidor RADIUS.
2. O servidor RADIUS não confia na CA que emitiu o certificado do cliente.
3. O servidor RADIUS não consegue transferir uma CRL atual.
4. A aplicação do mapeamento forte do NPS ao abrigo do KB5014754 rejeita certificados sem um mapeamento forte.

O código de motivo do NPS indica a causa correta.

As verificações de revogação causam uma interrupção de serviço

Se o ponto de distribuição CRL ficar offline ou a CRL expirar, os servidores RADIUS estritos rejeitam todos os certificados. Publique as CRLs num local HTTP altamente disponível que o seu servidor RADIUS consiga alcançar. Monitorize a hora da próxima atualização da CRL.

Os dispositivos continuam a ligar-se à rede antiga

Um perfil PEAP ou uma chave pré-partilhada legada ainda presente no dispositivo tem prioridade. Remova o perfil antigo através do Intune assim que o novo reportar sucesso e, em seguida, desative o SSID antigo.

Como funciona o WiFi baseado em certificados do Intune num local real?

Os dois cenários abaixo são exemplos práticos baseados no comportamento documentado pela Microsoft. Descrevem tipos de locais e não implementações específicas com nome.

Um grupo de 12 hotéis a desativar uma palavra-passe de funcionários partilhada

Situação. Um grupo de 12 hotéis, cada um com cerca de 200 quartos, opera um SSID de funcionários com uma chave pré-partilhada. A chave é partilhada por 840 dispositivos: PCs da receção, iPhones da governança e dispositivos móveis Android no serviço de restauração. A rede está ligada ao ambiente de dados de titulares de cartões. O requisito 2.3.2 da PCI DSS v4.0 exige, portanto, que a chave seja alterada sempre que alguém que a conhece sai da empresa. Com a rotatividade de pessoal de contacto com o cliente, cada rotação deixa dispositivos inoperacionais até que alguém volte a introduzir a chave.

O que foi feito. A equipa implementa SCEP através de NDES, publicado com o proxy de aplicações do Microsoft Entra ID. Os PCs da receção recebem certificados de dispositivo para que se liguem no ecrã de início de sessão. Os telefones recebem certificados baseados no utilizador. É realizado um piloto com 20 dispositivos num hotel durante duas semanas. Depois disso, um hotel muda a cada semana, com o SSID antigo a funcionar em paralelo.

Resultado mensurável. Após 12 semanas, todos os 840 dispositivos autenticam-se com EAP-TLS e o SSID de chave pré-partilhada é desligado. O número de chaves partilhadas a rodar cai de uma em 12 locais para zero. O acesso de um ex-colaborador termina agora quando o seu dispositivo é desativado e a CRL é republicada, e não na rotação de chave seguinte.

Uma cadeia de retalho de 150 lojas com dispositivos móveis partilhados

Situação. Cada loja opera quatro dispositivos móveis Android partilhados e dois portáteis de back-office Windows, num total de 900 dispositivos. Os dispositivos móveis passam de mão em mão entre os funcionários a cada turno, pelo que os certificados baseados no utilizador não fazem sentido. O serviço RADIUS em nuvem da cadeia não consegue alcançar uma CRL publicada apenas na rede interna.

O que foi feito. A cadeia regista os dispositivos móveis como dispositivos dedicados Android Enterprise e emite certificados de dispositivo através de SCEP. Um perfil de WiFi por plataforma atende a todas as lojas, porque o SSID é idêntico em todo o lado. A CRL é movida para um ponto de distribuição HTTP acessível pela internet.

Resultado mensurável. Nenhum dispositivo móvel partilhado contém uma palavra-passe de WiFi. Os funcionários da loja deixam de pedir a chave após cada alteração. Um dispositivo móvel perdido é bloqueado ao ser desativado no Intune, e o seu certificado falha na autenticação seguinte assim que a CRL for atualizada.

Quanto custa a implementação de certificados WiFi com o Intune e qual é o retorno?

Quanto custa

• Licenças. A maioria dos parques informáticos já possui o Intune através do Microsoft 365 ou Enterprise Mobility + Security, pelo que não há novos custos por utilizador.
• Servidores. AD CS, NDES e NPS são funções do Windows Server que não exigem uma licença separada para além do Windows Server.
• Cloud PKI. A Microsoft Cloud PKI é um suplemento pago, também incluído no Microsoft Intune Suite. Pondere o seu custo face à criação e manutenção de uma CA e NDES no local.
• Esforço. O trabalho centra-se no design da PKI, na publicação do NDES e no projeto-piloto. Os três perfis demoram horas, não semanas.

O que obtém em troca

• Sem chaves WiFi partilhadas. Isto elimina a rotação de chaves que o requisito 2.3.2 do PCI-DSS impõe às redes sem fios ligadas ao ambiente de dados de titulares de cartões.
• Acesso de ex-colaboradores que pode revogar. Desativar um dispositivo no Intune pode revogar o seu certificado, pelo que o acesso WiFi segue o seu processo de gestão de entradas, mobilidade e saídas (JML).
• Compatibilidade com Credential Guard. O EAP-TLS continua a funcionar nos casos em que o Windows bloqueia o início de sessão único 802.1X baseado em palavra-passe.
• Nenhuma credencial para phishing. Um certificado associado a um TPM não pode ser introduzido numa página de início de sessão falsa.
• Sem expiração de palavra-passe. Os certificados são renovados automaticamente antes de expirarem, eliminando as redefinições de palavra-passe como causa de pedidos de suporte para WiFi.

Planeie o tratamento do GDPR desde o início. Os assuntos de certificado que contêm o nome de utilizador de um colaborador constituem dados pessoais nos seus registos RADIUS. Defina um período de retenção e restrinja o acesso a esses registos.

A Purple executa WiFi para colaboradores e WiFi para convidados lado a lado em mais de 80 000 locais ativos (dados da Purple). A plataforma é independente de hardware, suportando Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. A Purple possui a certificação ISO 27001. As nossas Identity-Based Networks funcionam com Microsoft Entra ID, Okta e Google Workspace, para que o acesso da equipa siga a mesma fonte de identidade que o seu parque do Intune. No lado dos visitantes, a funcionalidade de Análise de WiFi gera relatórios sobre ligações de convidados separadamente do tráfego dos colaboradores.

Perguntas frequentes

Precisa de licenças extra para implementar certificados WiFi através do Intune?

Não, não para SCEP através de NDES nem para PKCS. O Intune está incluído no Microsoft 365 E3, E5 e Business Premium, e no Enterprise Mobility + Security E3 e E5. O Active Directory Certificate Services e o NDES são funções do Windows Server, pelo que apenas necessitam do seu licenciamento existente do Windows Server. A exceção é a Microsoft Cloud PKI, um suplemento pago também incluído no Microsoft Intune Suite. Inclua-a no orçamento apenas se pretender evitar a execução de uma CA no local.

O WiFi baseado em certificados do Intune funcionará com os seus pontos de acesso existentes?

Sim, desde que os seus pontos de acesso consigam transmitir um SSID WPA2-Enterprise ou WPA3-Enterprise. O EAP-TLS é executado entre o dispositivo e o servidor RADIUS, e o ponto de acesso apenas o retransmite ao abrigo da norma IEEE 802.1X. A Purple é independente de hardware e funciona em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Mantém o hardware que já possui e altera apenas as definições de segurança do SSID.

Pode migrar de PEAP ou de uma palavra-passe partilhada para EAP-TLS sem tempo de inatividade?

Sim. Execute o novo SSID 802.1X em paralelo com o antigo, ou configure o seu servidor RADIUS para aceitar tanto PEAP como EAP-TLS durante a transição. Implante os três perfis do Intune primeiro num grupo piloto. Confirme as autenticações EAP-TLS bem-sucedidas nos seus registos RADIUS e, em seguida, alargue a atribuição em fases. Remova o perfil de WiFi antigo apenas após o novo reportar êxito e, depois, desative o SSID antigo.

Deve escolher SCEP ou PKCS para o WiFi dos colaboradores?

Escolha SCEP. Com o SCEP, o dispositivo gera a sua própria chave privada, que nunca o abandona, e o Windows pode armazenar essa chave no TPM. O PKCS cria a chave fora do dispositivo e entrega-a. Isso elimina o servidor NDES, mas alarga os locais onde a chave esteve presente. Escolha PKCS apenas quando utilizar os Active Directory Certificate Services e não puder publicar o NDES, ou utilize o Microsoft Cloud PKI para SCEP sem NDES.

Ainda precisa de um servidor NDES?

Apenas para SCEP com uma CA local dos Active Directory Certificate Services. O Microsoft Cloud PKI fornece um ponto de extremidade SCEP alojado, pelo que não necessita de executar qualquer servidor NDES, conector ou CA local. Os perfis PKCS também evitam o NDES, porque o Certificate Connector for Microsoft Intune solicita certificados à sua CA através de ligações de saída. As autoridades de certificação de terceiros suportadas pelo Intune também podem emitir certificados SCEP sem NDES.

Com que rapidez termina o acesso ao WiFi quando alguém sai da empresa?

Tão rápido quanto o seu fluxo de revogação permitir. Quando desativa ou limpa um dispositivo no Intune, o Certificate Connector pode revogar o respetivo certificado na sua CA. O acesso termina quando o seu servidor RADIUS detetar essa revogação, através de uma CRL atualizada ou de uma verificação OCSP. Reduza o intervalo de publicação da CRL, ou utilize OCSP, se a remoção no próprio momento for crítica. Desativar a conta por si só pode não impedir um certificado válido, a menos que o RADIUS também verifique o diretório.

O WiFi baseado em certificados ajuda na conformidade com o PCI-DSS e GDPR?

Sim. O requisito 2.3.2 do PCI-DSS v4.0 exige que as chaves sem fios em redes ligadas ao ambiente de dados do titular do cartão sejam alteradas sempre que alguém que as conheça saia da empresa. Certificados individuais por dispositivo significam que não existe uma chave partilhada para rodar. Quanto ao GDPR, trate os assuntos de certificado que contenham o nome de início de sessão de um colaborador como dados pessoais. Defina um período de retenção para os registos RADIUS, restrinja o acesso aos mesmos e registe o processamento.