🏢Active DirectoryPasswordCompliance

Política de contraseñas AD: por qué difieren ANSSI y CIS

Compare los controles ANSSI y CIS atributo por atributo, verifique la política AD y corrija los fallos según una referencia identificada.

Younes AZABARPor Younes AZABAR12 min de lectura
Política de contraseñas AD: por qué difieren ANSSI y CIS

¿Qué es la conformidad de la política de contraseñas AD?

La conformidad de la política de contraseñas AD depende de la regla exacta que se evalúe. Un dominio puede cumplir los criterios numéricos citados para el control de política de contraseñas ANSSI de EtcSec y, aun así, fallar en su control CIS con la misma configuración. Los controles leen atributos parcialmente comunes, pero aplican umbrales distintos y abarcan ajustes diferentes.

La pregunta útil es, por tanto: ¿qué atributo ha fallado, frente a qué referencia documentada y con qué versión del detector? Un resultado etiquetado como ANSSI o CIS debe conducir a esas pruebas. Por sí solo, no puede establecer la conformidad con una publicación completa.

Esta comparación separa los dos predicados de detector documentados en una revisión del recopilador de septiembre de 2026 de las recomendaciones subyacentes. La comparación documental utiliza CIS Microsoft Windows Server 2012 R2 Benchmark v2.2.0, fechado el 28 de abril de 2016, secciones 1.1 y 1.2. Es una edición histórica. El catálogo CIS actual incluye Server 2022 v5.1.0, que no se ha leído para este artículo.

Nuestra guía práctica ANSSI para Active Directory explica por qué un programa de seguridad AD necesita un conjunto definido de documentos complementarios, en lugar de una afirmación de conformidad basada en un único PDF.

En qué difieren los controles ANSSI y CIS

La siguiente tabla distingue las recomendaciones de las fuentes de las condiciones citadas para Detect(). Los valores describen la configuración que satisface las condiciones numéricas citadas, en lugar de las propias expresiones de fallo.

La revisión del recopilador cita ad/compliance/anssi/r1-password-policy.go y ad/compliance/cis/password-policy.go. Los archivos Go completos no estaban disponibles para esta comparación. Por tanto, la tabla permite extraer conclusiones sobre esos fragmentos; no establece las ramas no citadas, la gestión de errores ni la cobertura de datos de recopilación ausentes.

AjusteOrientaciones del documento ANSSIFragmento del detector ANSSICIS histórico 2012 R2 v2.2.0Fragmento del detector CIS
minPwdLengthPG-078 R21: la longitud depende del nivel de seguridad requeridoAl menos 12 caracteresSección 1.1.4: al menos 14 caracteresAl menos 14 caracteres
pwdHistoryLengthLas recomendaciones PG-078 citadas no establecen el umbral de 12 contraseñas del detectorAl menos 12 contraseñasSección 1.1.1: al menos 24 contraseñasAl menos 24 contraseñas
lockoutThresholdPG-078 R10: limitar los intentos de autenticación a lo largo del tiempo; el intervalo fijo del detector es independiente1–10 intentos fallidosSección 1.2.2: 1–10 intentos fallidos1–5 intentos fallidos
maxPwdAgePG-078 R24/R25 distinguen entre cuentas ordinarias y privilegiadasSin prueba de antigüedad en el predicado citadoSección 1.1.2: distinto de cero, como máximo 60 díasDistinto de cero, como máximo 365 días
minPwdAgeAquí no se atribuye ningún umbral numérico correspondienteSin prueba en el predicado citadoSección 1.1.3: al menos 1 díaAl menos 1 día
Complejidad, representada en pwdPropertiesPG-078 R23: implementar reglas de complejidadNo documentada en el fragmentoSección 1.1.5: habilitadaNo documentada en el fragmento

Las fuentes de las columnas documentales son ANSSI-PG-078 y el PDF histórico CIS Server 2012 R2 v2.2.0. Las columnas de los detectores proceden de los predicados citados que se reproducen a continuación. Son umbrales de implementación, no una atribución de cada cifra a ANSSI. Las diferencias de 60/365 días y de 10/5 intentos también muestran por qué una afirmación documental debe ir acompañada de una edición.

La complejidad es una cuestión independiente

Microsoft define pwdProperties como un campo de bits de la política del dominio relativo a la complejidad y las restricciones de almacenamiento. Su indicador DOMAIN_PASSWORD_COMPLEX tiene el valor 1. Examinar la longitud, el historial y la antigüedad no permite establecer el estado de ese indicador.

Por tanto, una evaluación completa debe registrar explícitamente la complejidad. Los fragmentos proporcionados para estos dos controles no muestran ninguna condición de complejidad. Es una limitación de las pruebas de implementación disponibles, no una prueba de que los detectores completos la ignoren. No convierta un campo no documentado en un resultado satisfactorio supuesto.

Casos en los que los resultados divergen

Estos ejemplos son configuraciones hipotéticas evaluadas con los predicados numéricos citados. No son resultados de un entorno de cliente ni de una ejecución real del recopilador. Para estos ejemplos, se supone que las duraciones se expresan en días, que la ausencia de caducidad se representa como maxPwdAge == 0 y que los demás campos contienen valores válidos. Estas suposiciones coinciden con las comparaciones citadas; no se ha verificado la conversión de los valores del directorio por parte del recopilador.

EjemploLongitud mínimaHistorialUmbral de bloqueoAntigüedad máximaAntigüedad mínimaFragmento ANSSIFragmento CIS
Longitud inferior al mínimo CIS12245365 días1 díaCumpleFalla en longitud
Historial inferior al mínimo CIS14125365 días1 díaCumpleFalla en historial
Más intentos fallidos permitidos142410365 días1 díaCumpleFalla en el umbral de bloqueo
Política predeterminada sin caducidad14245Sin caducidad1 díaCumpleFalla en antigüedad máxima
Cambios inmediatos de contraseña14245365 días0 díasCumpleFalla en antigüedad mínima
Base numérica común14245365 días1 díaCumpleCumple

Cada fila aísla una razón del desacuerdo. Una política real puede incumplir varias condiciones a la vez, por lo que conviene conservar todos los atributos que fallan en lugar de informar solo del primero encontrado. Así, el plan de corrección es específico: un fallo de historial requiere cambiar el historial, mientras que un fallo de antigüedad requiere una decisión explícita sobre la caducidad.

¿Puede ocurrir lo contrario?

Para estos predicados citados con las mismas entradas válidas, cumplir las condiciones numéricas CIS implica cumplir las condiciones numéricas ANSSI. Una longitud mínima de 14 también cumple 12; un historial de 24 cumple 12; un umbral de bloqueo entre 1 y 5 también está entre 1 y 10. Las condiciones de antigüedad exclusivas de CIS añaden requisitos sin flexibilizar los compartidos.

Por tanto, no hay ningún ejemplo demostrado de cumplimiento CIS e incumplimiento ANSSI para este par de fragmentos. Si una auditoría informa de esa combinación, compare los valores recopilados, la versión del detector y todos los detalles del hallazgo antes de explicarlo como una diferencia entre normas. Las entradas, implementaciones o ámbitos de auditoría diferentes requieren sus propias pruebas.

La última fila tampoco establece la conformidad completa con el benchmark. Solo indica que estas cinco entradas numéricas satisfacen las expresiones citadas. La complejidad sigue siendo una verificación independiente, y un benchmark completo contiene controles adicionales.

Detección: leer la política de contraseñas predeterminada del dominio

Utilice el módulo PowerShell de Active Directory para recopilar la política predeterminada del dominio. Sustituya el dominio del ejemplo por el dominio que se esté revisando:

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' |
    Select-Object DistinguishedName, MinPasswordLength, PasswordHistoryCount,
        LockoutThreshold, MaxPasswordAge, MinPasswordAge, ComplexityEnabled

Es una única canalización de solo lectura basada en la documentación de Microsoft de Get-ADDefaultDomainPasswordPolicy. No se ha ejecutado contra un dominio real para este artículo.

Lea la salida como prueba de un dominio y un momento de recopilación concretos. Conserve el nombre distintivo junto con los valores, para que una revisión posterior pueda determinar si los dos resultados de auditoría describen realmente la misma política. No compare un ajuste GPO recordado con un resultado reciente del recopilador suponiendo que tienen entradas idénticas.

MinPasswordLength es un número de caracteres. PasswordHistoryCount corresponde al número de contraseñas conservadas; la página del esquema pwdHistoryLength de Microsoft documenta el atributo del directorio. Las propiedades de antigüedad son duraciones, mientras que la longitud, el historial y el umbral de bloqueo son cantidades. Mantenga explícitas esas unidades al transferir pruebas a una hoja de auditoría.

El comando devuelve la política predeterminada del dominio. No establece la política efectiva de todos los usuarios cuando se aplican políticas de contraseñas específicas. Microsoft documenta una consulta independiente de la política de contraseñas resultante para usuarios; no amplíe un resultado predeterminado del dominio a una afirmación de conformidad cuenta por cuenta.

Remediación y hardening: corregir el atributo que falla según una referencia identificada

Decida primero qué referencia y qué edición rigen el cambio. Documente el resultado requerido y después modifique los atributos que no lo cumplan. Un ajuste que elimina un hallazgo puede dejar otro intacto, como muestra la tabla de ejemplos.

Para un ejemplo que satisfaga ambos predicados numéricos citados y los criterios numéricos de la tabla histórica, utilice una longitud de 14, un historial de 24, un umbral de bloqueo de 5, una antigüedad máxima de 60 días y una mínima de 1 día. El valor de 60 días procede de la sección histórica CIS 1.1.2; la elección más estricta de 5 intentos procede del fragmento del detector CIS. Habilite la complejidad para el criterio de complejidad independiente del documento citado. Es un ejemplo comparativo, no una recomendación de adoptar hoy un benchmark histórico.

El siguiente ejemplo de configuración utiliza parámetros documentados por Microsoft para Set-ADDefaultDomainPasswordPolicy:

Set-ADDefaultDomainPasswordPolicy -Identity 'example.com' `
    -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 5 `
    -MaxPasswordAge '60.00:00:00' -MinPasswordAge '1.00:00:00' `
    -ComplexityEnabled $true -WhatIf

-WhatIf muestra una vista previa de la operación propuesta sin aplicarla. Este ejemplo se ha contrastado con la documentación; no se ha ejecutado en un dominio real. Un administrador debe probar el cambio previsto, aplicarlo mediante el proceso de gestión de políticas de la organización y repetir la consulta de solo lectura anterior. Una vista previa no es un resultado de corrección satisfactorio.

Decidir deliberadamente la caducidad

ANSSI-PG-078 R24 desaconseja la caducidad predeterminada para cuentas no sensibles cuando las contraseñas robustas y los sistemas de apoyo lo permiten; R25 mantiene la caducidad para cuentas privilegiadas. El texto anterior favorece la autenticación de dos factores para esas cuentas y trata la caducidad cuando se utiliza autenticación solo con contraseña. Esa distinción entre cuentas no puede establecerse mediante un único valor de antigüedad para todo el dominio. La ausencia de un hallazgo de antigüedad del detector ANSSI no valida toda la política de caducidad.

Si la referencia elegida exige una antigüedad máxima distinta de cero, mantenga ese requisito o documente la excepción mediante su proceso de auditoría. Eliminar un hallazgo del panel y justificar una excepción son resultados diferentes; registre cuál ha logrado.

Verificar el cambio y la exposición restante

Conserve la salida de la política antes y después, la edición de la referencia y la razón de cada atributo modificado. Vuelva a ejecutar ambos controles sobre la misma recopilación reciente y revise individualmente los hallazgos restantes. Si la configuración ha cambiado pero el hallazgo no, concilie el momento de recopilación y los valores informados antes de hacer otro cambio de política.

La conformidad de la política de contraseñas también necesita un contexto operativo. Nuestro artículo sobre password spraying explica cómo unos pocos intentos repartidos entre muchas cuentas pueden evitar bloqueos evidentes por cuenta, y por qué la mitigación combina controles de contraseñas, autenticación más sólida y monitorización correlacionada. Superar un control de umbral de bloqueo no debe utilizarse como prueba de que se ha eliminado el spraying.

Cómo detecta EtcSec estos problemas

El catálogo del sitio contiene tanto ANSSI_R1_PASSWORD_POLICY como CIS_PASSWORD_POLICY. La revisión del recopilador proporciona las siguientes condiciones de fallo para sus respectivas implementaciones de Detect():

ANSSI_R1_PASSWORD_POLICY
ad/compliance/anssi/r1-password-policy.go
minPwdLength < 12 OR pwdHistoryLength < 12
OR lockoutThreshold == 0 OR lockoutThreshold > 10

CIS_PASSWORD_POLICY
ad/compliance/cis/password-policy.go
minPwdLength < 14 OR pwdHistoryLength < 24
OR maxPwdAge > 365 OR maxPwdAge == 0
OR minPwdAge < 1 OR lockoutThreshold > 5 OR lockoutThreshold == 0

Los umbrales de antigüedad anteriores se expresan en días para esta comparación, de acuerdo con el ejemplo maxAge=120j de la revisión (línea 127). Los fragmentos no establecen cómo el recopilador convierte los intervalos LDAP sin procesar ni cómo representa las políticas sin caducidad. Explican por qué la misma política puede producir hallazgos diferentes y por qué cada hallazgo debe identificar el atributo que falla.

La prueba de implementación es la revisión del recopilador en docs/research/ad/2026-09-13-ad-catalogue-gap-diff.md, líneas 123 y 124 respectivamente. Esas líneas citan los archivos Go identificados; los números de línea del código Go no estaban disponibles. Los archivos fuente completos no estaban disponibles en esta revisión. La cobertura de complejidad, el comportamiento ante datos ausentes y cualquier otra rama no citada siguen sin verificarse. Estos hallazgos son señales útiles de configuración; sus nombres no convierten un predicado parcial en una evaluación ANSSI o CIS completa.

Referencias primarias

Explore las páginas de identidad que apoyan este tema