Despliegue de Directivas de Autenticación y Silos de Directivas de Autenticación

Las Directivas de Autenticación son políticas que permiten restringir el acceso a recursos a determinados usuarios y servicios. Por su parte, los silos permiten reunir varias cuentas en un mismo repositorio, facilitando la tierización* de un entorno. Tanto las directivas de autenticación como los silos pueden afectar a 3 tipos de cuentas:

• Cuentas de usuario

• Cuentas de servicio (MSA)

• Cuentas de equipo

En el caso de las cuentas de usuario, estas pasan a tener como base las restricciones de las Cuentas Protegidas (Protected Users):

• No se permite usar NTLM.

• Se bloquean RC4 y DES en la autenticación de Kerberos.

• No se permite la delegación de Kerberos, con o sin restricciones.

A mayores de esta base, también podemos personalizar:

1. El tiempo de vigencia de los tickets de Kerberos.

2. Si permitimos NTLM en determinados escenarios.

3. Las máquinas en las que se pueden obtener los tickets de Kerberos.

Las directivas de autenticación hacen un uso avanzado de Kerberos, utilizando algunas tecnologías poco comunes como:

• FAST Armoring: Un blindaje extra en los tickets, el cual protege mejor el PAC de Kerberos, donde se describen los permisos y usos de la cuenta autenticada.

• Autenticación Compuesta (Compound Authentication): Se genera un PAC conjunto para usuario y máquina. De esta forma, se puede atar la autenticación del usuario a un dispositivo específico.

Este último punto es la clave de las directivas de autenticación. Las cuentas de usuario que traten de autenticarse, no podrán hacerlo si no es en alguno de los dispositivos permitidos. El propio servicio de Kerberos Key Distribution Center (KDC) bloqueará la autenticación y reportará un evento de error si percibe algún intento de autenticación así. Sólo hay dos casos en los que la política de autenticación no obligará a cumplir un doble factor:

1. Si la cuenta a autenticar es el builtin Administrator (S-1-5-21-<dominio>-500). A esta cuenta no le afectan las políticas de autenticación. En cualquier caso, es posible deshabilitar esta cuenta si ya disponemos de otras con permisos de Domain Admins.

2. Si la cuenta a autenticar es de equipo. Los equipos no pueden verificar si se autentican desde determinado equipo porque… son ellos mismos.

Hay que tener en cuenta que las delegaciones y membresías en AD se suelen hacer a nivel de usuarios y servicios y no de máquinas. Además, los equipos renuevan sus claves de forma automática usando un gran número de caracteres para evitar ataques de fuerza bruta. Dicho esto, se podría conseguir la clave AES256 de un equipo accediendo a su memoria, aunque ya se trata de un compromiso avanzado de la máquina.

Modelo de tier o nivelación

Cuando decimos “tierización”, modelo de tier o nivelación, hablamos de un sistema de segregación por niveles de las entidades de un dominio. Cada uno de estos niveles supone un rango superior o inferior en los privilegios y gestión del dominio. Los modelos de tier pueden tener tantos niveles como se consideren oportunos. Uno bastante simple podría ser:

• Tier 0: Domain Controllers y Domain Admins

• Tier 1: Servidores y operadores.

• Tier 2: Equipos cliente y usuarios sin privilegios.

Bien hecha, esta segregación impediría los conocidos como “movimientos laterales”. Un usuario de Tier 2 no podría acceder a un servidor de Tier 1 ni tampoco podríamos usar una cuenta de Domain Admin para acceder a un servidor de Tier 1, por ejemplo. Conseguir un modelo así 100% funcional requiere de múltiples configuraciones, entre las que están las mencionadas directivas de autenticación.

Configurar directivas de autenticación y silos

Las directivas de autenticación y los silos requieren del cumplimiento de los siguientes pre-requisitos:

1. Dominio con Nivel funcional WS2012R2 o superior.

2. En todas las máquinas, habilitar “Future Encryption Types” en la directiva de seguridad “Configure Encryption Types Allowed for Kerberos”.

3. Habilitar la directiva “Support Dynamic Access Control and Kerberos armoring” tanto para KDC en Controladores de Dominio como para todos los clientes Kerberos.

Una vez cumplidos con estos pre-requisitos, tendremos que reiniciar tanto Controladores de Dominio como el resto de máquinas a las que les aplicamos estas GPOs. Por su parte, las directivas de autenticación y los silos se crean en Active Directory: Administrative Center.

A partir de aquí, si nunca habéis configurado directivas de autenticación y silos, recomiendo encarecidamente que sigáis los pasos exactos que describiré más adelante o en el vídeo, pues nos podemos encontrar con errores de configuración y comportamientos erráticos debido a varios motivos:

• Una cuenta sólo puede tener asignado una directiva de autenticación o un silo. No se puede tener más de uno ni tampoco de puede asignar ambos: o directiva o silo. Además, tras asignarlo debemos “confirmarlo”.

• A la cuenta builtin de administrador no le afectan ni silos ni directivas de autenticación.

• El modo de auditoría no funciona con los silos, sólo con las directivas de autenticación. Para que aparezcan eventos relativos a silos, se debe habilitar el modo forzado. Además, el modo forzado debemos configurarlo después de crear la directiva.

• Es necesario reiniciar los clientes Kerberos para que empiecen a surtir efecto las directivas de autenticación.

• Aunque se pueden usar directivas de autenticación sin silos, estas requieren de una configuración equipo a equipo. Es mejor usar los silos para agrupar varios usuarios, servicios y equipos.

Pasos a seguir:

1. Crear directiva de autenticación. Le ponemos un nombre, la marcamos forzada y la guardamos sin más.

2. Crear silo. Añadimos cuentas de equipo, usuario y MSA. Importante: la primera vez, deja una cuenta de emergencia miembro de Domain Admins fuera del silo. De configurar mal el silo, podríamos perder el acceso total al dominio. Mismamente la cuenta ‘administrator’ builtin es válida, ya que no le afectan las directivas de autenticación.

3. Elegimos una directiva de autenticación, la que creamos en el primer paso.

4. Guardar el silo, pero volvemos a entrar en él para poner el modo enforced y hacer más configuraciones.

5. Confirmamos las cuentas elegidas. Esto requiere de usar el comando Set-ADAccountAuthenticationPolicySilo o de confirmarla en AD: Administrative Center (salvo las MSA que no se pueden en interfaz gráfica).

6. Acceder a revisar el silo y ver que todas las cuentas están confirmadas con el tick verde.

7. Volver a la directiva de autenticación, comprobar que el silo está confirmado y modificar las condiciones para obtener tickets de usuario y servicio: (User.AuthenticationSilo Equals "Nombre_Silo").

8. Reiniciamos las máquinas que forman parte del silo.

Una vez configurado todo esto, podemos probar a iniciar sesión en una máquina de dentro del silo con un usuario del silo. Debiera ser posible. En cambio, si tratamos de iniciar sesión con el mismo usuario en una máquina que no está en el silo, la autenticación debiera fallar.

Y no sólo fallará esto, sino que los ataques pass the hash, pass the key y pass the certificate quedarán totalmente bloqueados para ese usuario. En un próximo contenido mostraremos cómo se bloquean en tiempo real.