Authentification réseau basée sur les certificats

Nous recommandons d’utiliser notre RADIUS-as-a-Service comme contrôleur d’accès réseau (NAC) pour mettre en œuvre une authentification Wi‑Fi, LAN ou VPN basée sur des certificats, car il permet une configuration en un clic. Les certificats SCEPman fonctionnent généralement avec tous les NAC qui prennent en charge l’authentification standard 802.1x basée sur des certificats, toutefois.

Cet article décrit les caractéristiques notables de certains des NAC les plus courants.

RADIUS-as-a-Service

Veuillez vous référer à la documentation RADIUS-as-a-Service pour voir comment utiliser les certificats SCEPman dans RADIUS-as-a-Service.

Cisco ISE

Cela n’est plus nécessaire pour Cisco

• ISE Release 3.2 Patch 8 ou version ultérieure,

• ISE Release 3.3 Patch 5 ou version ultérieure,

• ISE Release 3.4 Patch 2 ou version ultérieure

Cisco ISE ne prend généralement pas en charge HTTP 1.1 mais uniquement HTTP 1.0 pour les requêtes OCSP. Cela nécessite un Application Proxy supplémentaire devant SCEPman. Consultez notre article de dépannage pour ISE pour plus de détails.

Au moins certaines versions de Cisco ISE 3.x nécessitent une extension Extended Key Usage contenant l’Extended Key Usage OCSP Responder afin d’accepter les réponses OCSP, même si elles proviennent d’une AC, pour laquelle cela n’est pas requis par le RFC. Les versions de SCEPman jusqu’à la 1.7 n’ajoutaient pas par défaut une Extended Key Usage à leur certificat d’AC. La version 1.8 vous permet d’ajouter cette extension via un paramètre de configuration. Dans SCEPman 1.9, la valeur par défaut du paramètre de configuration ajoute déjà l’Extended Key Usage. Si vous disposez déjà d’un certificat d’AC sans extension Extended Key Usage et que vous rencontrez des problèmes avec Cisco ISE 3.x, il se peut que vous deviez créer un nouveau certificat SCEPman Root CA avec l’extension Extended Key Usage.

Aruba ClearPass

Microsoft Intune ClearPass Extension

Si vous utilisez Microsoft Intune ClearPass Extension d’Aruba dans ClearPass Policy Manager, vous devez ajouter les ID des appareils au modèle de certificat SCEP dans un certain format. Afin d’assurer la compatibilité avec SCEPman, les attributs SAN ci-dessous sont requis dans l’ ordre:

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

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

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

Les deux premières entrées sont utilisées par ClearPass, tandis que la troisième entrée est utilisée par SCEPman.

Problème OCSP HTTP 1.0

C'est n’est plus nécessaire pour ClearPass 6.9.6 ou version ultérieure.

De manière analogue à Cisco ISE, Aruba ClearPass utilise HTTP 1.0 pour les requêtes OCSP et nécessite donc des étapes de configuration supplémentaires ajoutant un Application Proxy pour fonctionner avec SCEPman.

Microsoft Network Policy Server (NPS)

NPS associe les certificats à des entités d’appareil ou d’utilisateur dans AD (et non dans AAD). Comme il n’existe pas de synchronisation des appareils prête à l’emploi entre AAD et AD, il est généralement impossible d’utiliser NPS avec des certificats d’appareil distribués via Intune avec SCEPman ou toute autre PKI. Les certificats utilisateur peuvent fonctionner pour les utilisateurs synchronisés entre AAD et AD. Les certificats doivent contenir les UPN des utilisateurs, que NPS utilise pour associer aux objets utilisateur AD ayant le même UPN.

Autres

En général, vous devez ajouter le certificat SCEPman Root CA comme AC approuvée dans le NAC.

Il se peut que vous deviez ajouter manuellement l’URL OCSP de SCEPman. Vous pouvez trouver l’URL OCSP dans l’extension Authority Information Access (AIA) de tout certificat client.