---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Module 6: Implementing AD CS ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Implementacion y diseño de PKI: Los certificados difitales son fundamentales para muchos servicios en un entorno microsoft:

- Cifrado de archivos y volumenes: EFS y Bitlocker - Proteccion de conexiones: VPN y DirectAccess - Servicios Web seguros: SSL - AD FS: Servcios de federacion. - AD RMS: Rights Managent Services

Cuando necesitamos certificados digitales tenemos 2 opciones:

- Autoridad certificadora publica: hace todo el trabajo por nosotros y suele ser reconocida internacionalmente. El coste puede ser importante.

- Autoridad certificadora privada: nosotros nos encargamos de todas la tareas: recepcion de solicitudes, emision de certificados, generacion de CRL, control de caducidad de certificados, gestion de plantillas, …

Certificados SSL: SSL = Secure Socket Layer Se utiliza para autenticar al servidor web y proteger el intercambio de informacion con el cliente. Solo garantiza la autenticidad de la identidad del servidor. Para proteger la informacion se usa un esquema de cifrado hibrido:

1. El usuario se conecta al servidor web via https:// 2. El servidor web envia al usuario su clave publica. 3. El usuario valida que la clave publica es correcta y que el servidor es quien dice ser. La comprobacion la hace

contra una CRL (Certificate Revocation List). 4. El usuario genera una clave de cifrado simetrica. Protege esta clave simetrica con la clave publica del

servidor y se la envia al servidor. 5. El servidor usa su clave privada para descifrar la clave simetrica. 6. A partir de aquí, las comunicaciones entre servidor y usuario van cifradas con la clave simetrica.

Este proceso se denomina SSL Handshake. Los certificados pueden tener diferentes propositos. En cada caso, el certificado es como un formulario que incluye diferentes datos. Por ejemplo, ne el caso de SSL:

- Autoridad certificadora - Fecha de emision y fecha de caducidad. - Fingerprint o clave publica - Clave privada. - URL: no existe este campo en otros tipos de certificado como los de usuario o EFS. Por ejemplo,

www.adatum.com

Los campos que se incluyen en este certificado se recogen en la plantilla de certificado (certificate template). Ademas, los certificados tienen diferentes formatos, aunque el estandar actual es el X.509 Certificados para firmas difitales: Se utilizan para:

- Garantizar la integridad del contenido - Autenticar al emisor.

Antes del envio, el emisor genera un digest (resumen) del contenido usando algoritmos como MD5 o SHA-1 (128 o 256 bits). Cifra este resument con su clave privada. Esto es lo que se denomina firma digital. Envia el contenido junto con la firma. El destinatario descifra la firma con la clave publica del emisor. Si lo consigue, es por que la firma fue cifrada con la clave publica del emisor y de esta forma garantizamos que es quien dice ser. Por su parte, el destinatario calcula el digest o hash del contenido y lo compara con el que le ha enviado el emisor. Si son iguales, el contenido no se ha modificado por el camino. Necesitamos:

- Un certificado para el emisor - Una aplicación que soporte certificados: word, GPG (GNU Privacy Guard)…

GPG es la version open source de PGP (Pretty Good Privacy) Vamos a instalar la CA Root enterprise en LON-DC1 Instalamos estos 2 roles

Configuramos la CA por defecto en modo entrerprise

Vamos a pedir un certificado para un usuario

Certificados disponibles con la configuracion por defecto

Pedimos el de usuario

Solo se pueden desrevocar certificados cuando los revocamos como hold certificate Cifrar archivos EFS sigue el siguiente proceso:

1. Si un usuario quiere cifrar un archivo o carpeta, se genera una clave de cifrado simetrico. Para una misma longitud de clave, un algoritmo simetrico es entre 100 y 1000 veces mas eficiente que uno asimetrico

2. Se usa la clave publica del usuario para cifrar la clave simetrica. 3. La clave simetrica cifrada se añade al encabezado del archivo. 4. Si el usuario quiere acceder al archivo, usa su clave privada para descifrar la clave simetrica. Despues usa la

clave simetrica para descifrar el archivo. Para compartir el archivo con otro usuario, o para crear un DRA (data recovery agent), el proceso es igual:

1. Se cifra la clave simetrica con la clave publica del otro usuario o el DRA. 2. Se añade la clave simetrica cifrada al encabezado del archivo

PKI: PKI= Public Key Infraestructure Componentes de una PKI:

- Certification authority: Gestiona y emite certificados y plantillas de certificados. - Certificados - Plantillas de certificados - CRL: Lista en la que aparecen los certificados revocados. Puede accederse a esa lista por diferentes medios:

almacenada en la particion configuracion del AD, via web, almacenada en una carpeta compartida - CDP: (CRL Distribution Point) guarda y publica las localizaciones de las CRLs - Online responder: La funcionalidad de comprobar la validez de certificados puede sacarse de la CA para

descargala en el trabajo, o para que esta funcionalidad se accesible desde el exterior sin comprometer la seguridad de la CA. Esta funcionalidad se llama online responder. OCSP (Online Certificate Status Protocol).

- AIA: (Authorization information Access). Permite a los usuarios encontrar autoridades certificadoras y certificados de CAs actualizados.

- HSM (Hardware Security Module): hardware especifico que se encarga de hacer las operaciones criptograficas.

Plantillas de Certificados y versiones Las version 1 son las que vienen preinstaladas y no se pueden modificar

Servicios de rol de AD CS en Windows Server 2012 R2 :

- CA: Gestiona certificados y platillas de certificados. Es el componente central y no es opcional. - Online Responder: Ejecuta el protocolo OCSP y puede estar instalado en una maquina diferente a la CA. - CA Web Enrollment: Servicio de rol de AD CS que se utiliza para entregar certificados a usuario y equipos

que no pertenecel al dominio, o no estan conectado a la red de la CA. Si se instala solo, no permite que los usuario pidan ceritifados Se compone de 2 servicios:

o Certificate enrollment web services (CES): esta disponible desde windows server 2008 R2 y permite: � Solicitar e instalar certificados � Revocar certificados � Descargar el certificado de una Root CA � Enrollment entre bosques y a traves de AD FS.

o Certificate Enrollment Policy Web Service (CEP): disponible desde windows server 2008 r2 y permite que los usuarios y equipos obtengan politicas de enrollment sin estar conectados a la red o sin pertenecer al dominio. Una politica de enrollment nos permite indicar que plantillas van a estar disponibles para que usuarios y por que medio.

- Network Device Enrollment Service (NDES): Servicio que permite que dispositivos de red (switches, routers, puntos de acceso, …) puedan solicitar certificados.

Vamos a instalar la CA en LON-DC2 como subordinada

Al solicitar un certitifado podemos a que entidad se lo pedimos

Esto es la AIA Authorization information Access

Cadena de confianza

La autoridad certificadora raiz valida a la autoridad certificadora subordinada. La CA raiz tiene un certificado autofimado en el que tenemos que confiar (Trusted root certification authorities). Si es enterprise, esta CA raiz sera confiable para todos los usuarios y maquinas del DA. Este certificado se almacena en la particion de configuracion del directorio activo Como vemos aqui

Esta almacenada en la particion de configuracion por que es enterprise y se distribuye en el DA tambien esta el AIA

En la particion de configuracion del AD tenemos otros 2 contenedores:

- AIA: indica cuales son las CAs (Raiz o no) disponibles en la red.

- CPD: Indica donde estan los puntos de distribucion de CRLs. Por defecto, cada CA tiene la CRL de los certificados revocados emitidos por ella.

La pKI suele diseñarse para que la CA root emita certificados para validar las CAs subordinadas, pero no certificados para usuarios o equipos. Una vez que la CA subordinada ha recibido su certificado de la CA raiz, podemos apagar la CA raiz. Esto implica que deja de estar disponible su CRL. Si reiniciamos la CA subordinada, no podra comprobar si su certificado sigue siendo valido y no se reiniciara. Aunque en la particion de configuracion del AD aparecen los CDP, cada certificado emitido incluye en sus detalles la localizacion de la CRL donde comprobar si esta revocado o no. Si queremos guardar las CRLs en localizaciones alternativas, por ejemplo, para que accedan usuarios desde fuera de la red, o usuarios que no pertenecen al dominio, esto debe hacerse ANTES de emitir los certificados Si instalamos una CA subordinada, al usar el asistente todos los valores se definiran por defecto. Si necesitamos cambiar algun parametro antes de desplegarla, tenemos que usar el archivo CAPolicy.inf Este archivo no esta instalado por defecto y lo tendriamos que guadar en C:\Windows\ antes de empezar a desplegar la CA subordinada http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx Administracion y seguridad de CAs: A la hora de administrar autoridades certificadoras, hay varias tareas que se pueden llevar a cabo:

- Gestionar y emitir certificados - Administrar plantillas - Crear backups - Gestionar claves - Permitir enrollment

Es importante controlar que usuarios pueden llevar a cabo estas tareas. En las CAs tenemos una serie de roles predifinidos para estas tareas.

Para que a un usuario se le entregue un certificado necesitamos 2 condiciones:

- Enrollee en la CA: debe estar autorizado a pedir certificados.

- En la plantilla del certificado, el usuario debe estar autorizado a pedirla (enroll)

En casos extremos, cuando la infraestructura PKI es critica y en organizaciones muy grandes, podria ser necesaria la separacion de roles administrativos. Esta separacion de roles implica que un mismo usuario no puede realizar a la vez 2 tareas. Por ejemplo, un mismo usuario no podria aprobar peticiones y revocaciones, y al mismo tiempo, hacer copia de seguridad de una CA. Para ejecutar esta separcion de roles, es IMPRESCINDIBLE que antes no haya ningun usuario que tenga mas de 1 rol, de lo contrario, perderia todos los roles. Si queremos ejecutarlo: Certutil setreg ca\rolesseparationenabled 1

Para crear un backup del CA Creamos la carpeta primero

Y ya tenemos la base de datos y la clave privada

Configuracion de CRLs y online Responder: La CRL (Certificate Revocation List) debe estar disponible para todos los usuarios, incluso si la CA no esta activa La CA solo es necesario que este activa cuando se van a emitir o a revocar certificados. La tarea diaria de comprobar la validez de certificados depende de la CRL. La localizacion de esta CRL esta incluida en los detalles de cada certificado. Esta localizacion se denomina DCP (CRL Distribution Point) Por defecto, cuando la CA es enterprise, tiene configurado como CDP el propio directorio activo (la particion de configuracion). Este CDP solo estara disponible para usuarios y equipos que pertenezcan al dominio y que tengan conexión con la red interna. Es posible que queramos definir otra localizacion para la CRL, de forma que podamos hacerla accesible desde fuera de la red. Para esto tenemos otras opciones:

- Servidor web (habitual) - Servidor de archivos (Carpeta)

Al configurar estas localizaciones alternaticas, solo apareceran en los detalles de los certificados emitidos desde ese momento. Ubicación de las CRL La que tiene el simbolo + es la delta se publica cada 4 horas La otra es la completa y se publica cada 2 dias

Cuando revocamos un certificado podemos publicar instantaneamente la revocacion

Podemos elegir la que nos interese

Ejercicio 1: Configurar un CDP para la autoridad certificadora adatum-LON-DC1-CA de forma que la CRL completa y la delta esten en una carpeta compartida accesible via web Creamos la carpeta donde van a estar la CRL y luego publicarla via web

Ahora le damos permisos a la maquina que va a modificar el contenido de la carpeta

Ahora vamos a añadir la CRL

Aquí añadimos la ubicación y los nombres que tendra las CRL Si la ubicación es en red hay que poner file://

Ahora elegimos que se va a publicar

Si no aparecen directamente publicamos a mano

Ahora vamos a publicar la carpeta via web Nos vamos al IIS

Ahora vamos a publicar la direccion de donde tienen que descargar la CRL

Si ponemos el serverdnsname no hace falta poner el nombre de la maquina

Y marcando los 3 checks ya estaria configurado

Ahora si pedimos un certificado y miramos los detalles vemos que aparece la lista que hemos creado

Online Responder: La tarea que mas recursos consume en un CA es la validacion de certificados, comprobar si un certificado sigue siendo valido o ha sido revocado. Para descargar de esta tarea a las CAs, podemos instalar y configurar un Online Responder, que implementa el protocolo OCSP (Online Certificate Status Protocol). Esta maquina con el online responder tambien tiene que estar autenticada, por lo que sera necesario darle un certificado de OCSP. Configuracion de OCSP (online responder):

Le cambiamos el nombre

Le damos permisos de enroll a la maquina que va hacer el online responder

ahora publicamos la plantilla que hemos creado

Y ya estaria disponible para generar certificados

Ahora vamos a configurar el rol de online responder

Y ya nos aparece la consola

Vamos a configurar el online responder

Aquí elegimos para quien vamos a resolver

Como ya hemos creado la plantilla ya nos aparece para solicitar el certificado necesario para online responder

Aquí podemos elegir el orden de comprovacion de CRLs o añadir mas

Por seguridad no se pone LDAP por que este servidor no deberia acceder por directorio activo a la CA

Ahora vamos al IIS y vemos que se ha creado el sitio para OCSP

Ahora tenemos que añadir el online responder para que se meta en los detalles de los certificados.

Añadimos una nueva

Y marcamos los 2 checks

Ejercicio2: Configurar el online responder de LON-DC1 de forma que atienda peticiones para adatum-LON-DC2-CA. Activamos la plantilla para ocsp en LON-DC2

Y nos vamos al Online responder en LON-DC1

Y ya nos aparece

Hay que esperar bastante hasta que se pone en verde

Tambien podemos recrear la configuracion hasta que replique pero eligiendo el certificado a mano

Pedimos el certificado para lon-dc1 de ocsp y se lo asignamos a mano

Y ahora si nos aparece en verde

Plantillas de certificados: Un certificado digital contiene el par de claves e informacion sobre el usuario, el equipo o el servicio que hace uso de ese certificado:

- Email del usuario - URL de un servidor web - Nombre de usuario - …

La informacion que contiene el certificado depende de su tipo y de su “proposito”. La plantilla actua a modo de formulario para recoger la informacion necesaria para elaborar el certificado. Ademas de esta informacion, la plantilla tambien incluye muchos otros parametros:

- DACL en la que se indican los usuarios y los permisos sobre esa plantilla - Modo de publicacion del certificado - Periodos de valided - Formas de renovacion de ese certificado - Si se almacena la clave privada en el AD para fines de recuperacion (KRA: Key Recovery Agent).

Plantilla para firmar scrips de powershell

Cuando marcamos esta casilla al modificar una plantilla

Se esta publicando la clave publica en el AD para que todos los usuarios tengan acceso a ella y con fines de recuperacion

En la pestaña Resquest handling podemos elegir el proposito de la plantilla

Aquí podemos definir la plantilla a la que vamos a sustituir por que la hemos actualizado

Aquí podemos definir el numero de usos del certificado

Autoenrollment: Cuando tenemos CAs Enterprise, podemos aprovechar las facilidades del AD para distribuir certificados a usuarios y equipos. De esta forma, los usuarios no tendran que pedir el certificado que necesitan usando el snap-in certificates en una mmc. Este proceso se conoce como autoenrollment. Autoenrollment se configura mediante GPOs.

Como es un certificado de usuario nos vamos a configuracion de usuario. En equipo estan las mismas politicas

Tenemos que activar 2 politicas

Estas opciones se utilizarian para usar certificados no emitidos por nosotros o por la CA integrada en DA menos las 3 ultimas

Asi podriamos importar un certificado por GPO

Aplicamos la GPO y actualizamos politicas en el cliente si se aplica la GPO automaticamente apareceran los certificados que tengan permisos de autoenrollment Vamos a firmar un script Primero ponemos la politica de ejecucion en solo firmados Set-ExecutionPolicy -ExecutionPolicy AllSigned Si intentamos ejecutar el script nos da error por que no esta firmado

Vamos a firmar el script Necesitamos la huella del certificado en una variable $Certificado=Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert

Con este comando firmamos el script Set-AuthenticodeSignature -Certificate $Certificado -FilePath C:\miscrip.ps1

Y ahora ya nos deja ejecutar el script

Y si entramos al archivo vemos la firma digital

Asi comprobamos la firma Get-AuthenticodeSignature .\miscrip.ps1

Modificamos el contenido del archivo cambiando una letra y volvemos a comprobar Como se ve hay una diferencia en el hash

Enrollment Agent: En algunos escenarios puede ser necesario disponer de un usuario que pueda solicitar certificados de parte de otros usuarios o equipos Este tipo de usuario se denomina Enrollment Agent. Como es un riesgo importante, suele usarse el Enrollment Agent Restricted, donde tenemos definidas plantillas y los usuario y equipos de parte de los que puede pedir un certificado. Por ejemplo, podemos restringir el enrollment agent para que solo pueda pedir certificados para el grupo de logistica del tipo Basic EFS. Para que un usuario sea enrollment agent, debe tener un certificado del tipo enrollment agent. Duplicamos la plantilla de enrollment agent y la renombramos

Añadimos a sistemas1 para que pueda pedir el certifado

Y la publicamos

Ahora vamos al usuario sistemas1 y pedimos el certificado

Ahora para restringir el uso

Desde esta pestaña elegimos los enrollagents que plantillas pueden solicitar y para quien Ahora mismo el usuario sistemas1 podria perdir el certificado de basic EFS para los usuarios que esten en el grupo Grupo_Sistemas

Para pedir en nombre de otro usuario

Key Recovery Agent: Igual que en el certificado EFS creamos DRAs (data recovey agents) para recuperar archivos, en el caso de que se pierda un certificado de usuario, en la CAs podemos configurar KRAs (Key Recovery Agents) que podran recuperar claves privadas en caso de que se pierda un certificado. Para poder recuperar claves privadas, estas claves privadas deben estar almacenadas (archivadas) en el directorio activo. Para que una clave privada se almacene en AD, debe definirse asi en su plantilla de certificado Vamos a almacenar una plantilla en el DA Nosotros vamos a usar la de Basic EFS la subimos de version para poder modificarla

Le cambiamos el nombre OJO con el check de publish certificate in active directory no estamos almacenando la clave privada sino la publica

Este check activa el almacenamiento en el DA de la clave Privada

Ahora configurar la plantilla para que sustituya la anterior para que no se entregen mas sin almacenar en el DA

Por ejemplo, para que los certificados de code signing guarden sus claves privadas en el AD, la plantilla code signing debe tener activado en “request Handling” el archivado de claves Para que un usuario o un grupo pueda trabajar como KRA, debe tener asigando un certificado de KRA (Key Recovery Agent). Vamos a duplicar la plantilla de Key Recovery Agent y le cambiamos el nombre No publicamos la clave publica por que no hace falta ya que solo la va a usar el usuario que digamos en nuestro caso Sistemas1

Le damos permisos de enroll

Desde la consola podriamos renovar todos los certificados que ya estaban emitidos con la nueva plantilla

Ahora publicamos las 2 plantillas que hemos creado

Ahora vamos a pedir el certificado de KRA con sistemas1

Al ser un certificado Critico tenemos que aprobarlo en la CA Primero hay que definir los usuario que seran KRA

Aquí le estamos dando el certificado de equipo donde se van a poder recuperar las claves y no en cualquier maquina Tendriamos que darle un certificado computer a la maquina que queramos permitir utilizar para recuperar claves

Ahora ya podemos aprobar el certificado que solicito el usuario

Ahora vamos a dar permiso al usuario para ser KRA ya que acabamos de emitir su certificado

Y ya estaria configurado el usuario sistemas1 para recuperar certificados en LON-DC1 Tarda un rato en poner valid en todos se tiene que replicar

Vamos a probar la recuperacion pedimos el certificado con la plantilla que tiene habilitada la publicacion en DA

Lo eliminamos para simular la perdida Nos vamos a la CA y buscamos el numero de serie del certificado borrado/perdido

Comando para recuperar la key certutil -getkey 4900000016d745b20c53b9735d000000000016 outputblob y despues certutil –recoverkey outputblob sistemas2.pfx BLOB: Binary Large OBject Ahora ya tendriamos el fichero y lo podriamos importar en la maquina donde estaba