Autenticação de rede baseada em certificados

Recomendamos utilizar o nosso RADIUS-as-a-Service como Network Access Controller (NAC) para implementar autenticação baseada em certificado para WiFi, LAN ou VPN, pois permite uma configuração com um clique. No entanto, os certificados SCEPman geralmente funcionam com todos os NACs que suportam autenticação padrão baseada em certificado 802.1x.

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

RADIUS-as-a-Service

Consulte a documentação do RADIUS-as-a-Service para ver como utilizar certificados SCEPman no RADIUS-as-a-Service.

Cisco ISE

Isto já não é necessário para Cisco

• ISE Release 3.2 Patch 8 ou posterior,

• ISE Release 3.3 Patch 5 ou posterior,

• ISE Release 3.4 Patch 2 ou posterior

O Cisco ISE normalmente não suporta HTTP 1.1, apenas HTTP 1.0, para pedidos OCSP. Isto requer um Application Proxy adicional à frente do SCEPman. Consulte o nosso Artigo de Resolução de Problemas para ISE para mais detalhes.

Pelo menos algumas versões do Cisco ISE 3.x exigem uma extensão Extended Key Usage que contenha o OCSP Responder Extended Key Usage para aceitar respostas OCSP, mesmo que estas venham de uma CA, onde tal não é exigido pela RFC. As versões do SCEPman até à 1.7 não adicionavam por defeito um Extended Key Usage ao seu certificado de CA. A versão 1.8 permite adicionar esta extensão através de uma definição de configuração. No SCEPman 1.9, o valor predefinido da definição de configuração já adiciona o Extended Key Usage. Se já tiver um certificado de CA sem uma extensão Extended Key Usage e tiver problemas com o Cisco ISE 3.x, poderá ser necessário criar um novo certificado SCEPman Root CA com a extensão Extended Key Usage.

Aruba ClearPass

Microsoft Intune ClearPass Extension

No caso de estar a utilizar a Microsoft Intune ClearPass Extension da Aruba no ClearPass Policy Manager, é necessário adicionar os IDs dos dispositivos ao modelo de certificado SCEP num formato específico. Para garantir a compatibilidade com o SCEPman, os atributos SAN abaixo são necessários na seguinte ordem:

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

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

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

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

Problema de OCSP HTTP 1.0

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

Analogamente ao Cisco ISE, o Aruba ClearPass utiliza HTTP 1.0 para pedidos OCSP e, por isso, requer etapas de configuração adicionais que adicionem um Application Proxy para funcionar com o SCEPman.

Microsoft Network Policy Server (NPS)

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

Outros

Em geral, tem de adicionar o certificado SCEPman Root CA como uma CA fidedigna no NAC.

Possivelmente, terá de adicionar manualmente o URL OCSP do SCEPman. Pode encontrar o URL OCSP na extensão Authority Information Access (AIA) de qualquer certificado de cliente.