El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los pasos que se utilizan para configurar correctamente el servicio de inscripción de dispositivos de red (NDES) de Microsoft y el protocolo simple de inscripción de certificados (SCEP) para la iniciativa "Trae tu propio dispositivo" (BYOD) en Cisco Identity Services Engine (ISE).
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
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.
La información relacionada con los servicios de certificados de Microsoft se proporciona como guía específica para Cisco BYOD. Consulte Microsoft TechNet como la fuente definitiva de la verdad para las configuraciones de servidor relacionadas con Microsoft Certification Authority, Network Device Enrollment Service (NDES) y SCEP.
Una de las ventajas de la implementación de BYOD habilitada para Cisco ISE es la capacidad de los usuarios finales para realizar el registro de dispositivos de autoservicio. Esto elimina la carga administrativa de la TI para distribuir las credenciales de autenticación y habilitar los dispositivos en la red. En el núcleo de la solución BYOD se encuentra el proceso de aprovisionamiento de suplicantes de red, que pretende distribuir los certificados necesarios a los dispositivos propiedad de los empleados. Para cumplir este requisito, se puede configurar una autoridad certificadora de Microsoft (CA) para automatizar el proceso de inscripción de certificados con el SCEP.
SCEP se ha utilizado durante años en entornos de red privada virtual (VPN) para facilitar la inscripción y distribución de certificados a clientes de acceso remoto y routers. La habilitación de la funcionalidad SCEP en un servidor Windows 2008 R2 requiere la instalación de NDES. Durante la instalación de la función NDES, también se instala el servidor Web de Microsoft Internet Information Services (IIS). IIS se utiliza para finalizar las solicitudes de registro HTTP o HTTPS SCEP y las respuestas entre el nodo de políticas de CA e ISE.
La función NDES se puede instalar en una CA actual o en un servidor miembro. En una implementación independiente, el servicio NDES se instala en una CA existente que incluye el servicio Certification Authority y, opcionalmente, el servicio Certification Authority Web Enrollment. En una implementación distribuida, el servicio NDES se instala en un servidor miembro. El servidor NDES distribuido se configura luego para comunicarse con una raíz ascendente o una CA sub-raíz. En esta situación, las modificaciones del Registro descritas en este documento se realizan en el servidor NDES con la plantilla personalizada, donde los certificados residen en la CA ascendente.
Esta sección proporciona una breve descripción general de los escenarios de implementación de CA/NDES que se han probado en el laboratorio de Cisco. Consulte Microsoft TechNet como la fuente definitiva de la verdad para las configuraciones de servidor relacionadas con Microsoft CA, NDES y SCEP.
Cuando ISE se utiliza en un escenario de prueba de concepto (PoC), es común implementar un equipo independiente de Windows 2008 o 2012 que actúe como controlador de dominio de Active Directory (AD), CA raíz y servidor NDES:
Cuando ISE se integra en un entorno de producción actual de Microsoft AD/PKI, es más común ver servicios distribuidos entre varios servidores Windows 2008 o 2012 distintos. Cisco ha probado dos escenarios para implementaciones distribuidas.
Esta imagen ilustra el primer escenario probado para implementaciones distribuidas:
Esta imagen ilustra el segundo escenario probado para implementaciones distribuidas:
Antes de configurar el soporte SCEP para BYOD, asegúrese de que el servidor Windows 2008 R2 NDES tenga instaladas estas revisiones de Microsoft:
Advertencia: Al configurar la CA de Microsoft, es importante comprender que ISE no admite el algoritmo de firma RSASSA-PSS. Cisco recomienda que configure la política de CA para que utilice sha1WithRSAEncryption o sha256WithRSAEncryption en su lugar.
A continuación se incluye una lista de los protocolos y puertos BYOD más importantes:
Nota: Para obtener la última lista de puertos y protocolos requeridos, refiérase a la Guía de Instalación de Hardware de ISE 1.2.
Utilice esta sección para configurar la compatibilidad con NDES y SCEP para BYOD en ISE.
De forma predeterminada, la implementación de Microsoft SCEP (MSCEP) utiliza una contraseña de desafío dinámico para autenticar clientes y terminales durante todo el proceso de inscripción de certificados. Con este requisito de configuración implementado, debe navegar a la GUI web del administrador de MSCEP en el servidor NDES para generar una contraseña a demanda. Debe incluir esta contraseña como parte de la solicitud de registro.
En una implementación de BYOD, el requisito de una contraseña de impugnación es contrario al objetivo de una solución de autoservicio para el usuario. Para eliminar este requisito, debe modificar esta clave de registro en el servidor NDES:
En algunos escenarios de implementación, podría ser preferible restringir las comunicaciones SCEP a una lista seleccionada de nodos ISE conocidos. Esto se puede lograr con la característica de Restricciones de Dominio y Dirección IPv4 en IIS:
Es posible que ISE genere URL que son demasiado largas para el servidor Web IIS. Para evitar este problema, la configuración de IIS predeterminada se puede modificar para permitir URL más largas. Ingrese este comando desde la CLI del servidor NDES:
%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/
security/requestFiltering /requestLimits.maxQueryString:"8192" /commit:apphost
Nota: El tamaño de la cadena de consulta puede variar en función del ISE y la configuración del terminal. Ingrese este comando desde la CLI del servidor NDES con privilegios administrativos.
Los administradores de una CA de Microsoft pueden configurar una o más plantillas que se utilizan para aplicar políticas de aplicación a un conjunto común de certificados. Estas políticas ayudan a identificar para qué función se utilizan el certificado y las claves asociadas. Los valores de las políticas de aplicación se incluyen en el campo Uso de clave extendido (EKU) del certificado. El autenticador analiza los valores en el campo EKU para asegurarse de que el certificado presentado por el cliente pueda ser utilizado para la función deseada. Algunos de los usos más comunes incluyen autenticación de servidor, autenticación de cliente, VPN IPSec y correo electrónico. En términos de ISE, los valores EKU más utilizados incluyen la autenticación de servidor y/o cliente.
Por ejemplo, al navegar a un sitio web de banco seguro, el servidor web que procesa la solicitud se configura con un certificado que tiene una política de aplicación de autenticación del servidor. Cuando el servidor recibe una solicitud HTTPS, envía un certificado de autenticación del servidor al explorador web conectado para la autenticación. El punto importante aquí es que este es un intercambio unidireccional del servidor al cliente. En lo que se refiere a ISE, un uso común para un certificado de autenticación de servidor es el acceso GUI de administración. ISE envía el certificado configurado al explorador conectado y no espera recibir un certificado de vuelta del cliente.
Cuando se trata de servicios como BYOD que utilizan EAP-TLS, se prefiere la autenticación mutua. Para habilitar este intercambio de certificados bidireccional, la plantilla utilizada para generar el certificado de identidad ISE debe poseer una política de aplicación mínima de autenticación del servidor. La plantilla de certificado de servidor Web cumple este requisito. La plantilla de certificado que genera los certificados de terminal debe contener una política de aplicación mínima de autenticación de cliente. La plantilla de certificado de usuario cumple este requisito. Si configura ISE para servicios como el Punto de aplicación de políticas en línea (iPEP), la plantilla utilizada para generar el certificado de identidad del servidor ISE debe contener tanto atributos de autenticación de cliente como de servidor si utiliza ISE versión 1.1.x o anterior. Esto permite que los nodos admin y en línea se autentiquen mutuamente. La validación de EKU para iPEP se eliminó en ISE versión 1.2, lo que hace que este requisito sea menos relevante.
Puede reutilizar las plantillas predeterminadas de Microsoft CA Web Server y User, o puede clonar y crear una nueva plantilla con el proceso que se describe en este documento. En función de estos requisitos de certificado, la configuración de CA y los certificados ISE y de punto final resultantes deben planificarse cuidadosamente para minimizar los cambios de configuración no deseados cuando se instalan en un entorno de producción.
Como se indica en la introducción, SCEP se utiliza ampliamente en entornos VPN IPSec. Como resultado, la instalación de la función NDES configura automáticamente el servidor para utilizar la plantilla IPSec (solicitud sin conexión) para SCEP. Debido a esto, uno de los primeros pasos en la preparación de una CA de Microsoft para BYOD es crear una nueva plantilla con la política de aplicaciones correcta. En una implementación independiente, los servicios Certification Authority y NDES se colocan en el mismo servidor y las plantillas y las modificaciones del registro necesarias se incluyen en el mismo servidor. En una implementación de NDES distribuida, las modificaciones del registro se realizan en el servidor NDES; sin embargo, las plantillas reales se definen en el servidor de CA raíz o subraíz especificado en la instalación del servicio NDES.
Complete estos pasos para configurar la plantilla de certificado:
Nota: El período de validez de la plantilla debe ser menor o igual al período de validez de los certificados raíz e intermedio de la CA.
Nota: Alternativamente, puede habilitar la plantilla a través de la CLI con el comando certutil -SetCAtemplates +ISE-BYOD.
Complete estos pasos para configurar las claves del Registro de Plantillas de Certificado:
En una implementación de BYOD, el terminal no se comunica directamente con el servidor NDES backend. En su lugar, el nodo de política ISE se configura como proxy SCEP y se comunica con el servidor NDES en nombre de los terminales. Los terminales se comunican directamente con ISE. La instancia de IIS en el servidor NDES se puede configurar para soportar vinculaciones HTTP y/o HTTPS para los directorios virtuales SCEP.
Complete estos pasos para configurar ISE como proxy SCEP:
Actualmente, no hay un procedimiento de verificación disponible para esta configuración.
Use esta sección para resolver problemas su configuración.
Esta es una lista de notas importantes que puede utilizar para resolver problemas de su configuración:
Nota: Algunos suplicantes no inicializan un intercambio de certificados de cliente si la EKU incorrecta está presente, como un certificado de cliente con EKU de autenticación de servidor. Por lo tanto, es posible que los errores de autenticación no siempre estén presentes en los registros de ISE.
Esta es una lista de técnicas útiles que se utilizan para resolver problemas de registro del lado del cliente:
Nota: WinHTTP se utiliza para la conexión entre el terminal de Microsoft Windows e ISE. Haga referencia al artículo Mensajes de Error de Microsoft Windows para obtener una lista de códigos de error.
Complete estos pasos para ver el registro de ISE:
Para obtener más información, consulte AD CS: Solución de problemas del artículo del Servicio de inscripción de dispositivos de red de Windows Server.