lunes, 8 de julio de 2013

Certificate Services en Windows Server 2012 r2 Parte 3

Seguimos hablando de Certificate Services en Windows Server 2012 R2, después del éxito mundial de los artículos uno y dos

Cuando hablábamos de organizaciones con diferentes sedes y la posibilidad de implementar una estructura compleja PKI basada en distintas CA subordinadas halábamos de rendimiento. Al publicar los servicios de Certificate Services dentro de Active Directory estamos extendiendo el esquema AD por ejemplo las propiedades del usuario, con información acerca de sus certificados. Esta información se va a almacenar también en el catálogo global (leíste la seria de artículos sobre FSMO y catálogo global?).También debemos estar en comunicación rápida con una entidad emisora de certificados para comprobar la validez de los certificados. Tenemos que tener en cuenta esto para calcular el aumento de datos en la replicación entre controladores de dominio, y debemos pensar en establecer distintas CA asociadas a Sitios de Active Directory.

Los equipos que intenta inscribirse en el servicio de Certificate Services para adquirir, renovar o validar un certificado emplean una función denominada DsGetSiteName.
DWORD DsGetSiteName(
  _In_   LPCTSTR ComputerName,
  _Out_  LPTSTR *SiteName
);
Esta función no es nueva, está presente desde  Windows Server 2000 (Normal, antes no existía el concepto de Site) pero es en Windows Server 2012 y los clientes Windows 8 cuando entra en escena para los servicios de Certificate Services. Recordar brevemente que es un Site dentro de Active Directory, es un conjunto de servidores y clientes conectados por un enlace de alta velocidad. Por ejemplo, es una empresa con dos sedes, se debería configurar un Site para cada sede, a nivel de Active Directory (independientemente de la tecnología subyacente de Networking para conectarlas) para optimizar la replicación. El cliente Windows 8 utilizará esta función para saber en que Site se encuentra. A bajo nivel lo que está haciendo es acceder al atributo de Active Directory msPKI-Site-Name que debe estar informado en los atributos del servidor con el role de Certificate Services. Por defecto al instalar Certificate Services no se completa este atributo en el servidor. Podemos hacer una prueba. Ejecutamos Certutil.exe -setcasites para comprobar el atributo de nuestra CA. Nos informa que está en estado Empty, es decir, no hemos configurado el atributo. Volvemos a ejecutar el mismo comando, y al no disponer de varios Sites en esta demo, configura el valor de msPKI para nuestra CA con el valor del Site por defecto de Active Directory.


En el caso de disponer de una infraestructura algo más avanzada, con varios Site Active Directory, el comando para identificar nuestra CA dentro del Site que le corresponde sería: certutil -setcasites -f -config "nombre de la CA" nombre del site.

Una vez que el cliente conoce la ubicación del Site de la entidad emisora de certificados, emplea otra función denominada DsQuerySitesByCost para calcular el coste de acceso a la CA.

DWORD DsQuerySitesByCost(
  _In_   HANDLE hDS,
  _In_   LPTSTR pwszFromSite,
  _In_   LPTSTR *rgwszToSites,
  _In_   DWORD cToSites,
  _In_   DWORD dwFlags,
  _Out_  PDS_SITE_COST_INFO *prgSiteInfo
);
En caso de no haber configurado el atributo msPKI de la entidad emisora de certificados dentro del Site, automáticamente se le proporcionará un valor alto al coste de enlace Active Directory. Típico ejemplo de ubicar una entidad emisora de certificados subordinada para delegación, se mueve el servidor miembro con Certificate Services al Site que le corresponde, pero no se informa de este valor. Los clientes al preguntar el coste del enlace obtendrán el mismo valor para una CA instalada en un Site, por ejemplo local, que para una  CA instalada en un Site a miles de kilómetros. Esto proporcionaría balanceo de carga ya que se comunicará con ambas CA indistintamente. Importante configurar estos parámetros para proporcionar rendimiento.
Podemos comprobar el coste de enlace contra varias entidades emisoras de certificados mediante el comando : certutil.exe -ping "ca1, ca2"

Otra de las funciones que trae bajo el brazo Certificate Services en Windows Server 2012 es la de poder renovar certificados de clientes con la misma clave. Esto agilizada enormemente la administración de certificados. Es posible generar nuevos certificados basados en la misma clave gracias al uso de plantillas predefinidas.

Para no aburriros más con estos conceptos, vamos a seguir configurando nuestra implementación de Certificate Services. Vamos a configurar el componente Web Enrollment para poder solicitar certificados desde el interface Web ( Recuerda https://servidor/certsrv). Para ello debemos configurar el acceso HTTPS. Por defecto se comunica mediante HTTP, por lo que debemos generar un certificado para nuestro servidor http. Lo primero que haremos será entrar al complemento de administración de Certificate Services.


Expandimos la parte de plantillas.


Botón derecho, administrar. En la documentación indica que si no aparece la opción administrar, carguemos el complemento de certificados desde una MMC. Mi recomendación es que dejéis tiempo al sistema, si acabáis de instalar Certificate Services para que se genere toda la estructura y replique con Active Directory. Esta recomendación es extensible para todos los procedimientos que detallamos en el blog. A veces las cosas necesitan su tiempo.


Nos situamos sobre servidor Web y hacemos botón derecho duplicar plantilla ( vivan las traducciones ).


En la pestaña general le vamos a proporcionar un nombre de certificado.


En la pestaña de seguridad le vamos a dar permisos tanto a los usuarios como al equipo que ejecuta Certificate Services para inscribirse. Para ello aparte del grupo de usuarios, debemos seleccionar una cuenta de equipo e indicar el nombre del servidor.



Ahora vamos a configurar las opciones relativas a la identificación del objeto dentro de Active Directory y el uso de DNS.


Una vez definida la plantilla, volvemos a la raíz del complemento de administración de Certificate Services y nos posicionamos sobre Plantillas, botón derecho, y creamos uno.


Ya que tenemos la plantilla para nuestro certificado, vamos a instalarlo. Para ello, en el servidor que tiene instalada la función de Web Enrollment ejecutamos MMC y añadimos el complemento Certificados para el equipo local.


Desplegamos el árbol de certificados y colocándonos sobre Personal hacemos botón derecho, todas la tareas, solicitar un nuevo certificado.


Seleccionamos la directiva de inscripción basada en Active Directory.


Una vez inscrito el certificado para nuestro servidor, es hora de acceder a Internet Information Services y configurar en la rama del sitio por defecto las opciones de bindings o enlaces.


Añadimos un enlace hacia HTTPS o modificamos el actual y configuramos el certificado emitido.


Podemos probar a acceder al servidor CA mediante HTTPS.


Con esto ya tenemos habilitado el acceso mediante HTTPS a nuestro servidor de inscripción web. El proceso para proporcionar comunicación HTTPS a cualquier servidor web de nuestra organización sería el mismo.

Con esto es suficiente por hoy. Como siempre, espero que os guste. Intentaré seguir con los servicios de Certificate Services en Windows Server 2012 y desplegar mas funciones que hagan uso de el.

Gracias por leerme !!!















Google +