Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les étapes qui sont utilisées afin de configurer correctement le service d'inscription de périphériques réseau Microsoft (NDES) et le protocole SCEP (Simple Certificate Enrollment Protocol) pour Bring Your Own Device (BYOD) sur Cisco Identity Services Engine (ISE).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Les informations relatives aux services de certificats Microsoft sont fournies comme guide spécifique pour le BYOD de Cisco. Reportez-vous à Microsoft TechNet en tant que source définitive de vérité pour les configurations de serveur liées à Microsoft, NDES (Network Device Enrollment Service) et SCEP.
L'un des avantages de la mise en oeuvre du BYOD Cisco ISE est la capacité des utilisateurs finaux à effectuer l'enregistrement des périphériques en libre-service. Cela élimine la charge administrative pesant sur le service informatique pour distribuer les informations d'identification d'authentification et activer les périphériques sur le réseau. Au coeur de la solution BYOD se trouve le processus de provisionnement des supplicants réseau, qui vise à distribuer les certificats requis aux périphériques appartenant aux employés. Afin de répondre à cette exigence, une autorité de certification Microsoft (CA) peut être configurée afin d'automatiser le processus d'inscription de certificat avec le SCEP.
SCEP est utilisé depuis des années dans des environnements de réseaux privés virtuels (VPN) afin de faciliter l'inscription et la distribution de certificats aux clients et routeurs d'accès à distance. L'activation de la fonctionnalité SCEP sur un serveur Windows 2008 R2 nécessite l'installation de NDES. Lors de l'installation du rôle NDES, le serveur Web Microsoft Internet Information Services (IIS) est également installé. IIS est utilisé afin de mettre fin aux demandes d'enregistrement SCEP HTTP ou HTTPS et aux réponses entre le noeud de stratégie CA et ISE.
Le rôle NDES peut être installé sur une autorité de certification actuelle ou sur un serveur membre. Dans un déploiement autonome, le service NDES est installé sur une autorité de certification existante qui inclut le service Autorité de certification et, éventuellement, le service d'inscription Web de l'autorité de certification. Dans un déploiement distribué, le service NDES est installé sur un serveur membre. Le serveur NDES distribué est ensuite configuré afin de communiquer avec une autorité de certification racine ou sous-racine en amont. Dans ce scénario, les modifications de Registre décrites dans ce document sont effectuées sur le serveur NDES avec le modèle personnalisé, où les certificats résident sur l'autorité de certification en amont.
Cette section présente brièvement les scénarios de déploiement CA/NDES qui ont été testés dans les travaux pratiques Cisco. Reportez-vous à Microsoft TechNet en tant que source définitive de vérité pour les configurations de serveurs liées à Microsoft CA, NDES et SCEP.
Lorsque ISE est utilisé dans un scénario PoC (Proof of of Concept), il est courant de déployer une machine Windows 2008 ou 2012 autonome qui agit en tant que contrôleur de domaine Active Directory (AD), autorité de certification racine et serveur NDES :
Lorsque l'ISE est intégré dans un environnement de production Microsoft AD/PKI actuel, il est plus courant de voir des services distribués sur plusieurs serveurs Windows 2008 ou 2012 distincts. Cisco a testé deux scénarios pour les déploiements distribués.
Cette image illustre le premier scénario testé pour les déploiements distribués :
Cette image illustre le deuxième scénario testé pour les déploiements distribués :
Avant de configurer la prise en charge SCEP pour le BYOD, assurez-vous que les correctifs Microsoft suivants sont installés sur le serveur NDES Windows 2008 R2 :
Avertissement : Lorsque vous configurez l'autorité de certification Microsoft, il est important de comprendre que l'ISE ne prend pas en charge l'algorithme de signature RSASSA-PSS. Cisco vous recommande de configurer la stratégie CA de sorte qu'elle utilise plutôt sha1WithRSAEncryption ou sha256WithRSAEncryption.
Voici une liste des principaux ports et protocoles BYOD :
Note: Pour obtenir la dernière liste des ports et des protocoles requis, reportez-vous au Guide d'installation matérielle ISE 1.2.
Utilisez cette section afin de configurer la prise en charge NDES et SCEP pour le BYOD sur ISE.
Par défaut, la mise en oeuvre de Microsoft SCEP (MSCEP) utilise un mot de passe de confirmation dynamique afin d'authentifier les clients et les points de terminaison tout au long du processus d'inscription des certificats. Avec cette configuration requise en place, vous devez accéder à l'interface utilisateur graphique Web de l'administrateur MSCEP sur le serveur NDES afin de générer un mot de passe à la demande. Vous devez inclure ce mot de passe dans la demande d'enregistrement.
Dans un déploiement BYOD, l'exigence d'un mot de passe d'interrogation est contraire à l'objectif d'une solution en libre-service utilisateur. Pour supprimer cette condition, vous devez modifier cette clé de Registre sur le serveur NDES :
Dans certains scénarios de déploiement, il peut être préférable de limiter les communications SCEP à une liste de noeuds ISE connus. Pour ce faire, vous pouvez utiliser la fonction IPv4 Address and Domain Restrictions dans IIS :
Il est possible pour ISE de générer des URL trop longues pour le serveur Web IIS. Afin d'éviter ce problème, la configuration IIS par défaut peut être modifiée pour autoriser des URL plus longues. Entrez cette commande à partir de l'interface de ligne de commande du serveur NDES :
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/
security/requestFiltering /requestLimits.maxQueryString:"8192" /commit:apphost
Note: La taille de la chaîne de requête peut varier en fonction de la configuration ISE et des points de terminaison. Entrez cette commande à partir de l'interface de ligne de commande du serveur NDES avec des privilèges d'administration.
Les administrateurs d'une autorité de certification Microsoft peuvent configurer un ou plusieurs modèles utilisés afin d'appliquer des stratégies d'application à un ensemble commun de certificats. Ces stratégies permettent d'identifier pour quelle fonction le certificat et les clés associées sont utilisés. Les valeurs de stratégie d'application sont contenues dans le champ Utilisation de clé étendue (EKU) du certificat. L'authentificateur analyse les valeurs du champ EKU afin de s'assurer que le certificat présenté par le client peut être utilisé pour la fonction prévue. Parmi les utilisations les plus courantes figurent l'authentification du serveur, l'authentification du client, le VPN IPSec et la messagerie électronique. En termes d'ISE, les valeurs EKU les plus couramment utilisées incluent l'authentification serveur et/ou client.
Lorsque vous accédez à un site Web de banque sécurisé, par exemple, le serveur Web qui traite la demande est configuré avec un certificat qui a une stratégie d'application d'authentification du serveur. Lorsque le serveur reçoit une demande HTTPS, il envoie un certificat d'authentification de serveur au navigateur Web de connexion pour authentification. L'important ici est qu'il s'agit d'un échange unidirectionnel entre le serveur et le client. En ce qui concerne ISE, l'accès à l'interface utilisateur graphique d'administration est une utilisation courante pour un certificat d'authentification de serveur. ISE envoie le certificat configuré au navigateur connecté et ne s'attend pas à recevoir de nouveau un certificat du client.
En ce qui concerne les services tels que le BYOD qui utilisent EAP-TLS, l'authentification mutuelle est préférable. Afin d'activer cet échange de certificats bidirectionnel, le modèle utilisé pour générer le certificat d'identité ISE doit posséder une stratégie d'application minimale d'authentification du serveur. Le modèle de certificat du serveur Web répond à cette condition. Le modèle de certificat qui génère les certificats de point de terminaison doit contenir une stratégie d'application minimale d'authentification client. Le modèle de certificat utilisateur satisfait à cette condition. Si vous configurez ISE pour des services tels que iPEP (Inline Policy Enforcement Point), le modèle utilisé pour générer le certificat d'identité de serveur ISE doit contenir des attributs d'authentification client et serveur si vous utilisez ISE version 1.1.x ou antérieure. Cela permet aux noeuds d'administration et en ligne de s'authentifier mutuellement. La validation EKU pour iPEP a été supprimée dans ISE version 1.2, ce qui rend cette exigence moins pertinente.
Vous pouvez réutiliser les modèles Microsoft CA Web Server et User par défaut, ou cloner et créer un nouveau modèle avec le processus décrit dans ce document. En fonction de ces exigences de certificat, la configuration de l'autorité de certification et les certificats ISE et terminaux résultants doivent être soigneusement planifiés afin de minimiser toute modification de configuration indésirable lors de son installation dans un environnement de production.
Comme indiqué dans l'introduction, SCEP est largement utilisé dans les environnements VPN IPSec. Par conséquent, l'installation du rôle NDES configure automatiquement le serveur pour utiliser le modèle IPSec (Offline Request) pour SCEP. C'est pourquoi l'une des premières étapes de la préparation d'une autorité de certification Microsoft pour le BYOD consiste à créer un nouveau modèle avec la politique d'application appropriée. Dans un déploiement autonome, les services de l'autorité de certification et de NDES sont regroupés sur le même serveur et les modèles et les modifications de Registre requises sont contenus sur le même serveur. Dans un déploiement NDES distribué, les modifications du Registre sont effectuées sur le serveur NDES ; cependant, les modèles réels sont définis sur le serveur AC racine ou sous-racine spécifié dans l'installation du service NDES.
Complétez ces étapes afin de configurer le modèle de certificat :
Note: La période de validité du modèle doit être inférieure ou égale à la période de validité des certificats racine et intermédiaire de l'autorité de certification.
Note: Vous pouvez également activer le modèle via l'interface de ligne de commande à l'aide de la commande certutil -SetCAtemplates +ISE-BYOD.
Complétez ces étapes afin de configurer les clés de Registre du modèle de certificat :
Dans un déploiement BYOD, le terminal ne communique pas directement avec le serveur NDES principal. Au lieu de cela, le noeud de stratégie ISE est configuré en tant que proxy SCEP et communique avec le serveur NDES au nom des points d'extrémité. Les terminaux communiquent directement avec l'ISE. L'instance IIS sur le serveur NDES peut être configurée afin de prendre en charge les liaisons HTTP et/ou HTTPS pour les répertoires virtuels SCEP.
Complétez ces étapes afin de configurer ISE en tant que proxy SCEP :
Aucune procédure de vérification n'est disponible pour cette configuration.
Utilisez cette section afin de dépanner votre configuration.
Voici une liste de remarques importantes que vous pouvez utiliser afin de dépanner votre configuration :
Note: Certains demandeurs n'initialisent pas un échange de certificat client si l'EKU erroné est présent, par exemple un certificat client avec l'EKU de l'authentification du serveur. Par conséquent, les échecs d'authentification peuvent ne pas toujours être présents dans les journaux ISE.
Voici une liste des techniques utiles utilisées pour résoudre les problèmes de journalisation côté client :
Note: WinHTTP est utilisé pour la connexion entre le point de terminaison Microsoft Windows et ISE. Reportez-vous à l'article Messages d'erreur Microsoft Windows pour obtenir une liste de codes d'erreur.
Complétez ces étapes afin d'afficher le journal ISE :
Pour plus d'informations, référez-vous à AD CS : Dépannage de l'article Windows Server du service d'inscription de périphérique réseau.