Autenticación de red basada en certificados

Recomendamos usar nuestro RADIUS como servicio como controlador de acceso a la red (NAC) para implementar autenticación WiFi, LAN o VPN basada en certificados, ya que permite una configuración con un solo clic. Sin embargo, los certificados de SCEPman generalmente funcionan con todos los NAC que admiten autenticación estándar basada en certificados 802.1x.

Este artículo describe características notables de algunos de los NAC más comunes.

RADIUS como servicio

Consulte la documentación de RADIUS como servicioarrow-up-right para ver cómo usar certificados de SCEPman en RADIUS como servicio.

Cisco ISE

circle-info

Esto ya no es necesario para Cisco

  • ISE Release 3.2 Patch 8 o posterior,

  • ISE Release 3.3 Patch 5 o posterior,

  • ISE Release 3.4 Patch 2 o posterior

Cisco ISE normalmente no admite HTTP 1.1, sino solo HTTP 1.0 para solicitudes OCSP. Esto requiere un Application Proxy adicional delante de SCEPman. Consulte nuestro artículo de solución de problemas para ISE para obtener más detalles.

Al menos algunas versiones de Cisco ISE 3.x requieren una extensión de Uso Ampliado de Clave que contenga el Uso Ampliado de Clave del Respondedor OCSP para aceptar respuestas OCSP, incluso si provienen de una CA, donde no es necesario según la RFC. Las versiones de SCEPman hasta la 1.7 no añadían por defecto un Uso Ampliado de Clave a su certificado de CA. La versión 1.8 le permite añadir esta extensión mediante un ajuste de configuración. En SCEPman 1.9, el valor predeterminado del ajuste de configuración ya añade el Uso Ampliado de Clave. Si ya tiene un certificado de CA sin una extensión de Uso Ampliado de Clave y tiene problemas con Cisco ISE 3.x, es posible que deba crear un nuevo certificado SCEPman Root CA con la extensión de Uso Ampliado de Clave.

Aruba ClearPass

Microsoft Intune ClearPass Extension

En caso de que esté usando la Microsoft Intune ClearPass Extensionarrow-up-right de Aruba dentro de ClearPass Policy Manager, debe agregar los identificadores de dispositivo al plantilla de certificado SCEP en un formato determinado. Para garantizar la compatibilidad con SCEPman, se requieren los atributos SAN siguientes en el orden:

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

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

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

circle-info

Las dos primeras entradas son usadas por ClearPass, mientras que la tercera entrada es usada por SCEPman.

Problema de OCSP HTTP 1.0

circle-info

Implementar Application Insights ya no es necesario para ClearPass 6.9.6 o posterior.

De forma análoga a Cisco ISE, Aruba ClearPass usa HTTP 1.0 para solicitudes OCSP y, por lo tanto, requiere pasos de configuración adicionales que agregan un Application Proxy para funcionar con SCEPman.

Microsoft Network Policy Server (NPS)

NPS asigna certificados a entidades de dispositivo o usuario en AD (no en AAD). Como no hay sincronización de dispositivos integrada entre AAD y AD, por lo general no es posible usar NPS con certificados de dispositivo distribuidos mediante Intune con SCEPman o cualquier otra PKI. Los certificados de usuario pueden funcionar para usuarios sincronizados entre AAD y AD. Los certificados deben contener los UPN de los usuarios, que NPS usa para asignar a objetos de usuario de AD con el mismo UPN.

Otros

En general, debe agregar el certificado SCEPman Root CA como una CA de confianza en el NAC.

Posiblemente, deba agregar manualmente la URL OCSP de SCEPman. Puede encontrar la URL OCSP en la extensión Authority Information Access (AIA) de cualquier certificado de cliente.

Última actualización

¿Te fue útil?