Active Directory: LDIF, una extracción para gobernarlos a todos

Extraer datos de un Active Directory, el directorio LDAP de Microsoft para sistemas operativos Windows, permite una multitud de controles que son fáciles de implementar, automatizables y, por lo tanto, establecen la defensa principal en la gobernanza de accesos para tus sistemas Windows. El objetivo de este artículo es presentarte la extracción LDIF (Formato de Intercambio de Datos LDAP) desde un AD, cómo se obtiene, así como una serie de controles basados en las recomendaciones de ANSSI.

1 – Extracción LDIF: ¿Qué formato para qué datos? 

LDIF, que significa «LDAP Data Interchange Format» (Formato de Intercambio de Datos LDAP), es un formato estandarizado diseñado para facilitar el intercambio de datos desde un directorio LDAP. No solo representa datos de directorio, sino que también permite acciones en un directorio (agregar, modificar, eliminar datos). La extracción LDIF es un archivo de texto (con la extensión ldif o ldf) y se puede leer o editar con un simple editor de texto.

2 – Cómo Obtener la Extracción LDIF de un Active Directory 

Microsoft ha proporcionado una herramienta de extracción dedicada. Su nombre completo es «Lightweight Directory Access Protocol Data Interchange Format Directory Exchange» (Formato de Intercambio de Datos de Protocolo de Acceso a Directorio Ligero para Intercambio de Formato de Datos), pero es más conocida como LDIFDE. Es una herramienta de línea de comandos utilizada para importar o exportar archivos LDIF. Esta herramienta está disponible en servidores Windows cuando los roles de servidor AD DS (Servicios de Dominio de Active Directory) o AD LDS (Servicios de Directorio Ligero de Active Directory) están instalados en la máquina.

3 – ¿Qué Hacer con Mi Extracción? 

Ahora que tenemos una extracción LDIF adecuada de nuestro AD, es hora de pasar a la parte que nos interesa aquí: ¡los controles! Te ofrecemos 23 controles para realizar en tu extracción para identificar anomalías en tu gobernanza de identidad y acceso, y evitar vulnerabilidades en tu sistema informático.

Control 1: Un Número Significativo de Miembros de Grupos con Privilegios Los grupos con privilegios son grupos de administración y operativos que tienen todos los derechos y privilegios en el dominio o pueden asignarlos. Los siguientes grupos están incluidos: Operadores de Cuenta Administradores Operadores de Respaldo Administradores de Dominio Administradores Empresariales Operadores de Impresión Administradores de Esquema Operadores de Servidor Debería evitarse asignar estos grupos, o hacerlo solo si todas las permisiones son realmente necesarias. Es preferible utilizar grupos personalizados aplicando el principio de menor privilegio.

Control 2: Controladores de Dominio Inconsistentes Un controlador de dominio es un servidor que autentica a un usuario en el dominio y valida su acceso a la red. Es importante que sus atributos de Control de Cuenta de Usuario (UAC) estén configurados correctamente. Por lo tanto, es necesario verificar si el controlador de dominio tiene los atributos SERVER_TRUST_ACCOUNT y TRUSTED_FOR_DELEGATION y ningún otro atributo. Atributos adicionales pueden aplicarse a «Controladores de Dominio Solo Lectura» (RODC).

Control 3: Cuentas con Privilegios sin Preautenticación Kerberos Kerberos es un protocolo de autenticación que permite una autenticación sólida mediante claves secretas. Las cuentas con privilegios (cuentas con todos los derechos o con el potencial para tener todos los derechos en el dominio) no deben tener el atributo «DONT_REQUIRE_PREAUTH».

Control 4: Cuentas con Privilegios con SPN El atributo servicePrincipalName se establece de forma predeterminada en las cuentas de máquina. Este atributo nunca debe establecerse en una cuenta con privilegios, ya que un ataque de «fuerza bruta» podría recuperar la contraseña de la cuenta con privilegios a través del ticket emitido por Kerberos.

Control 5: Cuentas con Privilegios y Contraseñas que Nunca Expiran Los innumerables riesgos asociados con esta anomalía no necesitan enumerarse. El atributo «DONT_EXPIRE» nunca debe establecerse en una cuenta con privilegios. Comprometer todo el dominio podría ser sencillo (por ejemplo, por parte de un ex empleado).

Control 6: Cuentas con Privilegios y Contraseñas Sin Cambiar Durante un Período Determinado Para mitigar los riesgos asociados al robo de contraseñas, es crucial tener rotaciones frecuentes de contraseñas. Esto se aplica a todos los usuarios, pero es aún más crítico para las cuentas con privilegios.

Control 7: Controladores de Dominio con Contraseñas de Cuenta de Equipo Sin Cambiar por Más de 45 Días Por defecto, la rotación de contraseñas ocurre cada 30 días. Si esto no puede lograrse, es importante investigar la causa de manera pronta.

Control 8: Controladores de Dominio Inactivos Un controlador de dominio se conecta típicamente cada 30 días para cambiar su contraseña. La falta de autenticación puede deberse a la desincronización. En tales casos, el controlador de dominio debe reinstalarse o eliminarse.

Control 9: Cuentas con primaryGroupId Menor a 1,000 Este atributo asocia a un usuario con un grupo de manera implícita. Algunas interfaces no muestran esta relación en la lista de miembros del grupo. Por lo tanto, es importante dejar el valor predeterminado: 513 para un usuario, 514 para un invitado y 515 para una computadora.

Control 10: Cuentas Miembros del Grupo DnsAdmins Se recomienda no usar el grupo DnsAdmins. Este grupo permite la ejecución de código a través del servicio DNS, generalmente alojado en el controlador de dominio.

Control 11: Alto Número de Cuentas Activas no Utilizadas Una cuenta inactiva es aquella que no ha iniciado sesión en el dominio durante un cierto período. Puede ser una cuenta poco utilizada (o cuyo propietario está de licencia) o una cuenta obsoleta (asociada a un antiguo empleado). La categorización eficiente de cuentas inactivas es importante para desactivar cuentas obsoletas, reduciendo la superficie de ataque y la carga de trabajo durante las revisiones de derechos.

Control 12: Delegación No Restringida de Autenticación La propiedad «TRUSTED_FOR_DELGATION» solo debe estar presente en controladores de dominio. Si otra cuenta tiene este atributo, podría autenticarse en un servicio Kerberos con la identidad de otra cuenta que se autenticó en la primera cuenta.

Control 13: Cuentas Sin Preautenticación Kerberos El atributo «DONT_REQUIRE_PREAUTH» no debe estar presente en una cuenta.

Control 14: Cuentas de Usuario con Cifrado Kerberos Débil Kerberos puede utilizar el algoritmo de cifrado DES para emitir tickets. Sin embargo, este algoritmo se considera obsoleto, por lo que el atributo «USE_DES_KEY_ONLY» debe eliminarse de las cuentas en el AD.

Control 15: Cuentas con Contraseñas que Nunca Expiran Un segundo control sobre la expiración de contraseñas, pero esta vez el criterio se aplica a todos los usuarios en el AD, no solo a las cuentas con privilegios.

Control 16: Versión Incorrecta de Active Directory En ciertas versiones de Active Directory, los grupos Key Admins y Enterprise Key Admins tienen Entradas de Control de Acceso (ACE) excesivamente permisivas. Las versiones de Windows Server 1709 corrigen este problema, por lo que es importante realizar la actualización. Verifique el valor «ActiveDirectoryUpdate» en el archivo LDIF. Si la versión es 15, se recomienda realizar la actualización.

Control 17: El Grupo «Pre-Windows 2000 Compatible Access» Contiene «Anonymous» Este grupo solo debe contener «Usuarios Autenticados» (S-1-5-11) y no «Anonymous» (S-1-5-7). De lo contrario, es posible la enumeración anónima de ciertos elementos desde el controlador de dominio.

Control 18: Contraseña de la Cuenta krbtgt Sin Cambiar por Más de un Año Comprometer la cuenta «krbtgt» permitiría a un atacante falsificar tickets Kerberos y autenticarse con derechos de Administrador en todo el dominio. Control 19: Cuenta con primaryGroupID Modificado Anteriormente, recomendamos prohibir primaryGroupIDs menores a 1,000 (excluyendo el valor predeterminado). Ahora aconsejamos no modificar esta propiedad, que implica membresía implícita en un grupo. La declaración explícita a través de la propiedad «MemberOf» es preferible.

Control 19: Cuentas con primaryGroupID modificado. Antes recomendábamos prohibir primaryGroupIDs inferiores a 1.000 (excluyendo el valor por defecto). Ahora desaconsejamos modificar esta propiedad, que implica la pertenencia implícita al grupo. Es preferible la declaración explícita a través de la propiedad «MemberOf».

Control 20: Cuentas o Grupos Miembros de «Pre-Windows 2000 Compatible Access» Mismas explicaciones que en el Control 17, pero en esta ocasión ampliamos el alcance del control para evitar que Anonymous sea miembro de este grupo a través de un intermediario.

Control 21: Cuentas Privilegiadas que no son Miembros del Grupo «Protected Users» El grupo «Protected Users» establece barreras para los usuarios miembros: Forzar la autenticación Kerberos Reducir la vida útil de los tickets Kerberos Imponer el uso de algoritmos de cifrado fuertes (por ejemplo, AES) Desactivar el almacenamiento en caché de contraseñas en estaciones de trabajo Prohibir cualquier forma de delegación

Control 22: Cuentas con Almacenamiento Reversible de Contraseñas Si se establece el atributo «ENCRYPTED_TEXT_PASSWORD_ALLOWED» en una cuenta, la contraseña de esa cuenta puede recuperarse en texto plano.

Control 23: Cuentas o Grupos con Historial de SID El atributo sIDHistory debe estar vacío para todos los usuarios y grupos en el dominio. Si está poblado, genera registros que llenan los registros de eventos y puede ser explotado por un atacante para obtener derechos no autorizados sobre recursos.

Conclusion 

Acabamos de enumerar algunos controles que se pueden ejecutar fácilmente para tener una visión general de la conformidad de su Active Directory con las mejores prácticas de ANSSI. Además, estos controles se pueden automatizar fácilmente utilizando scripts de PowerShell. Una vez que los controles estén en su lugar, las anomalías deben informarse de manera clara para que puedan gestionarse rápidamente. WALLIX ofrece un enfoque «One Shot» para llevar a cabo estos controles y obtener una visión general de las acciones iniciales o para integrar estos controles en una política más amplia de gobierno de identidad y acceso que abarque todo el sistema de TI. Todo esto se puede ver desde una interfaz web para obtener informes precisos y claros.