Autenticação de Rede baseada em Certificado

Recomendamos usar nosso RADIUS-as-a-Service como Controlador de Acesso à Rede (NAC) para implementar autenticação por certificado em WiFi, LAN ou VPN, pois permite uma configuração com um clique. Os certificados do SCEPman geralmente funcionam com todos os NACs que suportam autenticação baseada em certificado 802.1x padrão, no entanto.

Este artigo descreve características notáveis de alguns dos NACs mais comuns.

RADIUS-as-a-Service

Consulte o documentação do RADIUS-as-a-Servicearrow-up-right para ver como usar certificados SCEPman no RADIUS-as-a-Service.

Cisco ISE

circle-info

Isto não é mais necessário para o

  • Cisco ISE Release 3.2 Patch 8 ou posterior,

  • Cisco ISE Release 3.3 Patch 5 ou posterior,

  • Cisco ISE Release 3.4 Patch 2 ou posterior

O Cisco ISE comumente não suporta HTTP 1.1, apenas HTTP 1.0 para requisições OCSP. Isso requer um Proxy de Aplicação adicional na frente do SCEPman. Consulte nosso Artigo de Resolução de Problemas para ISE para detalhes.

Ao menos algumas versões do Cisco ISE 3.x exigem uma extensão Extended Key Usage contendo o OCSP Responder Extended Key Usage para aceitar respostas OCSP, mesmo que venham de uma CA, onde isso não é exigido pelo RFC. Versões do SCEPman até a 1.7 não adicionavam um Extended Key Usage por padrão ao seu certificado CA. A versão 1.8 permite que você adicione essa extensão através de uma configuração. No SCEPman 1.9, o padrão da configuração já adiciona o Extended Key Usage. Se você já possui um certificado CA sem a extensão Extended Key Usage e tem problemas com o Cisco ISE 3.x, pode ser necessário criar um novo certificado Root CA do SCEPman com a extensão Extended Key Usage.

Aruba ClearPass

Extensão ClearPass para Microsoft Intune

Caso você esteja usando o Extensão ClearPass para Microsoft Intunearrow-up-right da Aruba dentro do ClearPass Policy Manager, é necessário adicionar os IDs dos dispositivos ao modelo de certificado SCEP em um determinado formato. Para garantir compatibilidade com o SCEPman, os atributos SAN abaixo são exigidos na seguinte ordem:

  • (URI) Valor: DeviceId:{{DeviceId}}

  • (URI) Valor: AAD_Device_ID:{{AAD_Device_ID}}

  • (URI) Valor: IntuneDeviceId://{{DeviceId}}

circle-info

As duas primeiras entradas são usadas pelo ClearPass, enquanto a terceira entrada é usada pelo SCEPman.

Problema OCSP HTTP 1.0

circle-info

Isto é não mais necessário para o ClearPass 6.9.6 ou posterior.

Analogamente ao Cisco ISE, o Aruba ClearPass usa HTTP 1.0 para requisições OCSP e, portanto, requer passos de configuração extras adicionando um Proxy de Aplicação para funcionar com o SCEPman.

Microsoft Network Policy Server (NPS)

O NPS mapeia certificados para entidades de dispositivo ou usuário no AD (não no AAD). Como não existe sincronização de dispositivos pronta entre AAD e AD, geralmente não é possível usar o NPS com certificados de dispositivo distribuídos via Intune com o SCEPman ou qualquer outra PKI. Certificados de usuário podem funcionar para usuários sincronizados entre AAD e AD. Os certificados devem conter os UPNs dos usuários, que o NPS usa para mapear para objetos de usuário do AD com o mesmo UPN.

Outros

De modo geral, você deve adicionar o certificado Root CA do SCEPman como uma CA confiável no NAC.

Possivelmente, você terá que adicionar manualmente a URL OCSP do SCEPman. Você pode encontrar a URL OCSP na extensão Authority Information Access (AIA) de qualquer certificado de cliente.

Last updated

Was this helpful?