--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Module 6: Implementing AD CS

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Implementacion y diseo 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 aplicacin 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 aade 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 aade 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 disearse 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 conexin 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.

Ubicacin 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 aadir la CRL

Aqu aadimos la ubicacin y los nombres que tendra las CRL

Si la ubicacin 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 aadir 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 aadir el online responder para que se meta en los detalles de los certificados.

Aadimos 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 pestaa 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

Aadimos 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 pestaa 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