Authentification réseau basée sur certificat

Nous recommandons d'utiliser notre RADIUS-en-tant-que-service comme contrôleur d'accès réseau (NAC) pour mettre en œuvre une authentification WiFi, 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-en-tant-que-service

Veuillez vous référer à la documentation RADIUS-en-tant-que-service pour voir comment utiliser les certificats SCEPman dans RADIUS-en-tant-que-service.

Cisco ISE

Ceci n'est plus requis pour Cisco

• ISE Release 3.2 Patch 8 ou ultérieur,

• ISE Release 3.3 Patch 5 ou ultérieur,

• ISE Release 3.4 Patch 2 ou ultérieur

Cisco ISE ne prend généralement pas en charge HTTP 1.1 mais uniquement HTTP 1.0 pour les requêtes OCSP. Ceci nécessite un proxy d'application supplémentaire devant SCEPman. Référez-vous à notre article de dépannage pour ISE pour les détails.

Au moins certaines versions de Cisco ISE 3.x exigent une extension Extended Key Usage contenant l'Extended Key Usage du répondant OCSP afin d'accepter les réponses OCSP, même si elles proviennent d'une CA, où cela n'est pas requis selon la RFC. Les versions de SCEPman jusqu'à la 1.7 n'ajoutaient pas par défaut une extension Extended Key Usage à son certificat d'autorité. 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 avez déjà un certificat de CA sans extension Extended Key Usage et que vous rencontrez des problèmes avec Cisco ISE 3.x, vous devrez peut-être créer un nouveau certificat Root CA SCEPman avec l'extension Extended Key Usage.

Aruba ClearPass

Extension Microsoft Intune ClearPass

Dans le cas où vous utilisez Aruba Extension Microsoft Intune ClearPass au sein du ClearPass Policy Manager, vous devez ajouter les identifiants d'appareil au modèle de certificat SCEP dans un certain format. Pour 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

Ceci est n'est plus requis pour ClearPass 6.9.6 ou ultérieur.

De façon 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 proxy d'application pour fonctionner avec SCEPman.

Microsoft Network Policy Server (NPS)

NPS associe les certificats à des entités d'appareil ou d'utilisateur dans AD (pas AAD). Comme il n'existe pas de synchronisation d'appareils prête à l'emploi entre AAD et AD, il n'est généralement pas possible 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 mapper aux objets utilisateur AD ayant le même UPN.

Autres

Généralement, vous devez ajouter le certificat Root CA de SCEPman en tant qu'autorité de confiance dans le NAC.

Il est possible 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.