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 con éxito el servicio de la inscripción del dispositivo de la red de Microsoft (NDE) y el protocolo simple certificate enrollment (SCEP) para Bring Your Own Device (BYOD) en Cisco identifica el motor de los servicios (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.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.
El relacionado con la información a los servicios de certificados de Microsoft se proporciona como guía específicamente para Cisco BYOD. Refiera al TechNet de Microsoft como la fuente definitiva de verdad para las autoridades de certificación de Microsoft, el servicio de la inscripción del dispositivo de red (NDE), y las Configuraciones del servidor SCEP-relacionadas.
Una de las ventajas de la implementación ISE-habilitada Cisco BYOD es la capacidad de los usuarios finales de realizar el registro del dispositivo del autoservicio. Esto elimina la carga administrativa en el TIC para distribuir los credenciales de autenticación y habilitar los dispositivos en la red. En el corazón de BYOD la solución es el proceso de abastecimiento del supplicant de la red, que intenta distribuir los Certificados indispensables a los dispositivos propiedades de los empleados. Para satisfacer este requisito, un Microsoft Certificate Authority (CA) se puede configurar para automatizar el proceso de la inscripción del certificado con el SCEP.
El SCEP se ha utilizado por los años en los entornos del Red privada virtual (VPN) para facilitar la inscripción del certificado y la distribución a los clientes de acceso remoto y al Routers. La habilitación de las funciones SCEP en un servidor del r2 de Windows 2008 requiere la instalación de los NDE. Durante la instalación del papel NDE, el servidor Web de los Servicios de Internet Information Server de Microsoft (IIS) también está instalado. El IIS se utiliza para terminar el HTTP o los pedidos de inscripción y las respuestas HTTPS SCEP entre nodo de la directiva de CA y ISE.
El papel NDE se puede instalar en CA actual, o puede ser instalado en un servidor miembro. En un despliegue independiente, el servicio NDE está instalado en CA existente que incluye el servicio de las autoridades de certificación y, opcionalmente, el servicio de la inscripción de la red de las autoridades de certificación. En un despliegue distribuido, el servicio NDE está instalado en un servidor miembro. El servidor distribuido NDE entonces se configura para comunicar con una raíz o una sub-raíz por aguas arriba CA. En este escenario, las modificaciones del registro delineadas en este documento se hacen en el servidor NDE con la plantilla personalizada, donde los Certificados residen en la conexión en sentido ascendente CA.
Esta sección proporciona una breve descripción de los escenarios de instrumentación CA/NDES que se han probado en el laboratorio de Cisco. Refiera al TechNet de Microsoft como la fuente definitiva de verdad para Microsoft CA, NDE, y Configuraciones del servidor SCEP-relacionadas.
Cuando el ISE se utiliza en un escenario de la prueba de concepto (PC), es común desplegar Windows autónomo 2008 o 2012 trabaja a máquina que actúa como controlador de dominio del Active Directory (AD), raíz CA, y el servidor NDE:
Cuando el ISE es integrado en un entorno de producción actual de Microsoft AD/PKI, es más común ver los servicios distribuidos a través del múltiplo, de los servidores distintos de Windows 2008 o 2012. Cisco ha probado dos escenarios para las implementaciones distribuidas.
Esta imagen ilustra el primer escenario probado para las implementaciones distribuidas:
Esta imagen ilustra el segundo escenario probado para las implementaciones distribuidas:
Antes de que usted configure el soporte SCEP para BYOD, asegúrese de que el servidor del r2 NDE de Windows 2008 tenga este hotfixes de Microsoft instalado:
Advertencia: Cuando usted configura Microsoft CA, es importante entender que el ISE no soporta el algoritmo de la firma RSASSA-PSS. Cisco recomienda que usted configura la directiva de CA de modo que utilice sha1WithRSAEncryption o sha256WithRSAEncryption en lugar de otro.
Aquí está una lista de puertos y protocolos importantes BYOD:
Nota: Para la última lista de puertos y protocolos requeridos, refiera al guía de instalación del hardware ISE 1.2.
Utilice esta sección para configurar el soporte NDE y SCEP para BYOD en el ISE.
Por abandono, la implementación de Microsoft SCEP (MSCEP) utiliza una contraseña de impugnación dinámica para autenticar los clientes y los puntos finales en el proceso de la inscripción del certificado. Con estos requisitos para la configuración en el lugar, usted debe hojear a la red GUI MSCEP admin en el servidor NDE para generar una contraseña a pedido. Usted debe incluir esta contraseña como parte del pedido de inscripción.
En un despliegue BYOD, el requisito de una contraseña de impugnación derrota el propósito de una solución del autoservicio del usuario. Para quitar este requisito, usted debe modificar esta clave de registro en el servidor NDE:
En algunos escenarios de instrumentación, puede ser que sea preferido para restringir las comunicaciones SCEP a una lista selecta de Nodos sabidos ISE. Esto se puede lograr con la característica de las restricciones del direccionamiento y del dominio del IPv4 en el IIS:
Es posible que el ISE genere los URL que son demasiado largos para el servidor Web IIS. Para evitar este problema, la configuración IIS predeterminada se puede modificar para tener en cuenta URL más largos. Ingrese este comando del servidor CLI NDE:
%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 pudo variar al dependiente sobre la configuración ISE y del punto final. Ingrese este comando del servidor CLI NDE con los privilegios administrativos.
Los administradores de Microsoft CA pueden configurar una o más plantillas que se utilicen para aplicar las directivas de la aplicación a un conjunto común de Certificados. Estas directivas ayudan a identificar para qué función se utilizan el certificado y las claves asociadas. Los valores de directiva de la aplicación se contienen en el campo dominante extendido del uso (EKU) del certificado. El authenticator analiza los valores en el campo del EKU para asegurarse de que el certificado presentado por el cliente se puede utilizar para la función prevista. Algunas de las aplicaciones mas comunes incluyen la autenticación de servidor, la autenticación de cliente, el IPSec VPN, y el correo electrónico. En términos de ISE, los valores generalmente usados del EKU incluyen el servidor y/o la autenticación de cliente.
Cuando usted hojea a un sitio web seguro del banco, por ejemplo, configuran al servidor Web que procesa la petición con un certificado que tenga una directiva de la aplicación de la autenticación de servidor. Cuando el servidor recibe una petición HTTPS, envía un Certificado de autenticación de servidor al buscador Web de conexión para la autenticación. El punto importante aquí es que esto es un intercambio unidireccional del servidor al cliente. Pues se relaciona con el ISE, un de uso común para un Certificado de autenticación de servidor es acceso a GUI admin. El ISE envía el certificado configurado al navegador conectado y no lo espera recibir un certificado detrás del cliente.
Cuando se trata de los servicios tales como BYOD que utilicen el EAP-TLS, se prefiere la autenticación recíproca. Para habilitar este intercambio bidireccional del certificado, la plantilla usada para generar el certificado de identidad ISE debe poseer una directiva mínima de la aplicación de la autenticación de servidor. El Certificate Template plantilla de certificado del servidor Web satisface este requisito. El Certificate Template plantilla de certificado que genera los Certificados del punto final debe contener una directiva mínima de la aplicación de la autenticación de cliente. La plantilla del Certificado de usuario satisface este requisito. Si usted configura el ISE para los servicios tales como punta en línea de la aplicación de políticas (iPEP), la plantilla usada para generar el certificado de identidad del servidor ISE debe contener ambos atributos de la autenticación de cliente y servidor si usted utiliza la versión 1.1.x o anterior ISE. Esto permite que el admin y los Nodos en línea se autentiquen mutuamente. La validación del EKU para el iPEP fue quitada en la versión 1.2 ISE, que hace este requisito menos relevante.
Usted puede reutilizar el servidor Web y las plantillas del usuario predeterminados de Microsoft CA, o usted puede reproducir y crear una nueva plantilla con el proceso que se delinea en este documento. Basado sobre estos requisitos del certificado, la configuración de CA y el ISE resultante y los Certificados del punto final se deben planear cuidadosamente para minimizar cualquier cambio de configuración no deseada cuando está instalada en un entorno de producción.
Como se apunta en la introducción, el SCEP es ampliamente utilizado en los entornos del IPSec VPN. Como consecuencia, la instalación del papel NDE configura automáticamente el servidor para utilizar la plantilla del IPSec (petición offline) para el SCEP. Debido a esto, uno de los primeros pasos en la preparación de Microsoft CA para BYOD es construir una nueva plantilla con la directiva correcta de la aplicación. En un despliegue independiente, colocan a las autoridades de certificación y a los servicios NDE en el mismo servidor, y las plantillas y las modificaciones requeridas del registro se contienen al mismo servidor. En un despliegue distribuido NDE, las modificaciones del registro se hacen en el servidor NDE; sin embargo, las plantillas reales se definen en el servidor de CA de la raíz o de la sub-raíz especificadas en la instalación del servicio NDE.
Complete estos pasos para configurar el Certificate Template plantilla de certificado:
Nota: El período de validez de la plantilla debe ser inferior o igual el período de validez de los Certificados de la raíz y del intermedio de CA.
Nota: Alternativamente, usted puede habilitar la plantilla vía el CLI con el certutil - comando de SetCAtemplates +ISE-BYOD.
Complete estos pasos para configurar las claves de registro del Certificate Template plantilla de certificado:
En un despliegue BYOD, el punto final no comunica directamente con el servidor backend NDE. En lugar, el nodo de la directiva ISE se configura como proxy SCEP y comunica con el servidor NDE en nombre de los puntos finales. Los puntos finales comunican directamente con el ISE. El caso IIS en el servidor NDE se puede configurar para soportar los atascamientos HTTP y/o HTTPS para los directorios virtuales SCEP.
Complete estos pasos para configurar el 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.
Aquí está una lista de NOTAS IMPORTANTES que usted pueda utilizar para resolver problemas su configuración:
Nota: Algunos suplicantes no inicializan un intercambio del certificado del cliente si el EKU incorrecto está presente, por ejemplo un certificado del cliente con el EKU de la autenticación de servidor. Por lo tanto, las fallas de autenticación no pudieron siempre estar presentes en los registros ISE.
Aquí está una lista de técnicas útiles que se utilicen para resolver problemas los problemas del registro del client cara:
Nota: WinHTTP se utiliza para la conexión entre el punto final de Microsoft Windows y el ISE. Refiérase al artículo de los mensajes de error de Microsoft Windows para una lista de códigos de error.
Complete estos pasos para ver el registro ISE:
Para más información, refiera al AD CS: Resolver problemas el artículo del Servidor Windows del servicio de la inscripción del dispositivo de red.