Contraseñas en AD: longitud, FGPP y listas de bloqueo

La mayoría de los compromisos de Active Directory que empiezan por una contraseña no implican descifrar nada ingenioso. Empiezan con un password spraying contra una directiva que admite Welcome1!, con una cuenta de servicio cuya contraseña se estableció en 2014 o con un hash descifrado sin conexión porque ocho caracteres y un símbolo obligatorio dan un espacio de búsqueda minúsculo. En muchos entornos, la directiva de dominio predeterminada sigue reflejando recomendaciones de hace dos décadas: contraseñas cortas, reglas de complejidad, caducidad a los 90 días y nada que compruebe si una contraseña ya figura en un corpus de filtraciones.

Esta guía reconstruye la directiva a partir de la evidencia actual. Explica qué dice hoy NIST SP 800-63B, cómo medir la calidad de las contraseñas que ya tiene, cómo superponer directivas de contraseñas específicas para administradores y cuentas de servicio, cómo añadir comprobaciones de contraseñas prohibidas y filtradas en el momento del cambio y cómo retirar con seguridad la rotación forzada.

Qué dicen realmente las recomendaciones actuales

NIST SP 800-63B Revisión 4 (publicada en su versión final en 2025) es la referencia que aceptan la mayoría de los auditores. Los puntos que importan para AD:

• Longitud antes que complejidad. Mínimo de 15 caracteres cuando la contraseña es el único factor y de 8 cuando forma parte de una MFA. Permita al menos 64 caracteres.
• Sin reglas de composición. Los verificadores no deben exigir combinaciones de tipos de caracteres; empujan a los usuarios hacia sustituciones predecibles.
• Sin rotación periódica. Cambie las contraseñas solo ante indicios de compromiso.
• Las listas de bloqueo son obligatorias. Compruebe las contraseñas nuevas contra palabras filtradas conocidas, de diccionario y propias del contexto (nombre de la empresa, nombres de productos).
• Limite los intentos de adivinación en línea en lugar de confiar en la complejidad.

Las líneas base de seguridad de Microsoft eliminaron la caducidad de contraseñas en 2019 por el mismo motivo. Puede que su regulador o su aseguradora de ciberriesgos sigan exigiendo la rotación; documente los controles compensatorios que se describen a continuación y negocie a partir de ellos.

Medir: qué aplica hoy el dominio

Get-ADDefaultDomainPasswordPolicy

Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, LockoutThreshold, AppliesTo

# Cuentas que eluden por completo la directiva
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)' | Select-Object SamAccountName   # PASSWD_NOTREQD
Get-ADUser -Filter 'PasswordNeverExpires -eq $true -and Enabled -eq $true' -Properties PasswordLastSet |
  Sort-Object PasswordLastSet | Select-Object SamAccountName, PasswordLastSet
Get-ADUser -Filter 'AllowReversiblePasswordEncryption -eq $true' | Select-Object SamAccountName

Las cuentas con PASSWD_NOTREQD pueden tener una contraseña vacía con independencia de la directiva; borre la marca con Set-ADUser -PasswordNotRequired $false después de confirmar que cada una tiene una contraseña real. El cifrado reversible almacena una contraseña recuperable y el recuento debe ser cero.

Auditar: la calidad de las contraseñas existentes

La directiva solo se aplica en el siguiente cambio, así que necesita saber qué hay ya. El cmdlet Test-PasswordQuality del módulo DSInternals compara los hashes NT con una lista de hashes filtrados (por ejemplo, la descarga NTLM de Have I Been Pwned) e informa de contraseñas vacías, duplicadas, predeterminadas y débiles. Funciona replicando hashes desde un DC, lo que convierte la propia ejecución en una operación de Tier 0: ejecútelo desde una estación de trabajo de acceso privilegiado con una concesión de replicación limitada en el tiempo, mantenga cifrado el resultado y retire los derechos después. Herramientas comerciales como Specops Password Auditor ofrecen el mismo informe de solo lectura.

Céntrese en tres hallazgos:

1. Contraseñas compartidas entre la cuenta de administración y la cuenta estándar de una misma persona.
2. Contraseñas filtradas en cualquier cuenta privilegiada o de servicio.
3. Hashes duplicados entre cuentas de servicio, que revelan credenciales reutilizadas que un solo descifrado por Kerberoasting desbloquearía.

Fuerce de inmediato el restablecimiento en los casos privilegiados y filtrados; no espere a la nueva directiva.

Aplicar: la línea base del dominio

La directiva de contraseñas del dominio se lee del GPO vinculado a la raíz del dominio, normalmente la Default Domain Policy, en Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy. Los GPO de directiva de contraseñas vinculados a OU no afectan a las cuentas del dominio.

El Editor de directivas de grupo limita la longitud mínima a 14. Las versiones más recientes de Windows añaden Relax minimum password length limits y Minimum password length audit en el mismo nodo, que permiten valores superiores; todos los DC y clientes que validan la directiva deben admitirlo, así que pruébelo antes de confiar en ello. Las PSO nunca tuvieron ese límite y son la vía más sencilla para llegar a 15 o más.

Para el bloqueo de cuentas, la línea base de seguridad de Windows usa un umbral de 10 intentos no válidos con 15 minutos de duración y de restablecimiento del contador. Es suficiente para frenar el spraying sin permitir que un atacante bloquee a toda la empresa.

Aplicar: directivas de contraseñas específicas

Las PSO requieren un nivel funcional de dominio Windows Server 2008 o superior y se almacenan en CN=Password Settings Container,CN=System,DC=.... Cree un conjunto pequeño y deliberado:

New-ADFineGrainedPasswordPolicy -Name "PSO-AllUsers-15" -Precedence 100 `
    -MinPasswordLength 15 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "1.00:00:00" `
    -LockoutThreshold 10 -LockoutDuration "00:15:00" -LockoutObservationWindow "00:15:00" `
    -ReversibleEncryptionEnabled $false

New-ADFineGrainedPasswordPolicy -Name "PSO-Admins-20" -Precedence 10 `
    -MinPasswordLength 20 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "1.00:00:00" `
    -LockoutThreshold 10 -LockoutDuration "00:15:00" -LockoutObservationWindow "00:15:00" `
    -ReversibleEncryptionEnabled $false

New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts-30" -Precedence 5 `
    -MinPasswordLength 30 -ComplexityEnabled $false -PasswordHistoryCount 24 `
    -MaxPasswordAge "365.00:00:00" -MinPasswordAge "0.00:00:00" `
    -LockoutThreshold 0 -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject "PSO-AllUsers-15"        -Subjects "PSO-Scope-AllUsers"
Add-ADFineGrainedPasswordPolicySubject "PSO-Admins-20"          -Subjects "PSO-Scope-Admins"
Add-ADFineGrainedPasswordPolicySubject "PSO-ServiceAccounts-30" -Subjects "PSO-Scope-ServiceAccounts"

Notas de diseño:

• Las PSO se aplican solo a usuarios y a grupos de seguridad globales, no a OU. Use grupos sombra mantenidos por script si piensa en términos de OU.
• Gana la precedencia más baja; una PSO vinculada directamente a un usuario prevalece sobre las PSO vinculadas a grupos, sea cual sea su precedencia. Deje margen entre los valores de precedencia.
• La PSO de cuentas de servicio deshabilita el bloqueo porque una cuenta de servicio bloqueada es una interrupción que un atacante puede provocar a voluntad; lo compensa con la longitud y debería afectar a cada vez menos cuentas a medida que pasen a gMSA.
• La antigüedad máxima de 365 días es un valor provisional. Cuando los controles compensatorios descritos más abajo estén activos, desactive Enforce maximum password age en cada PSO desde el Centro de administración de Active Directory.

Para las cuentas privilegiadas, combine la longitud con una autenticación más fuerte en lugar de más rotación: tarjeta inteligente o Windows Hello para empresas respaldado por FIDO2, pertenencia a Protected Users y directivas y silos de autenticación. Con un nivel funcional de dominio Windows Server 2016, las cuentas configuradas con Smart card is required for interactive logon pueden renovar automáticamente su secreto NTLM cuando msDS-ExpirePasswordsOnSmartCardOnlyAccounts está habilitado en el dominio.

Aplicar: comprobación de contraseñas prohibidas y filtradas

La lista de bloqueo es el control que sustituye a la complejidad y a la rotación. Opciones:

• Microsoft Entra Password Protection para AD DS. Un agente de DC (una DLL de filtro de contraseñas) y un servicio proxy aplican la lista global de contraseñas prohibidas de Microsoft y su lista personalizada en cada cambio de contraseña local. Requiere licencias de Entra ID P1 o P2 para la aplicación en local y reiniciar el DC para instalar el agente. Empiece en modo Audit, revise qué cambios se habrían rechazado y, después, pase a Enforce.
• Lithnet Password Protection (código abierto) o filtros comerciales como Specops Password Policy, que pueden comprobar contra una copia local de hashes filtrados sin conectividad con la nube.

Elija lo que elija, se ejecuta como filtro de contraseñas dentro de LSASS en todos los DC, así que trate su instalación, sus actualizaciones y su almacén de configuración como cambios de Tier 0.

# Entra Password Protection: confirmar que todos los DC ejecutan el agente y han notificado recientemente
Get-AzureADPasswordProtectionDCAgent | Format-Table ServerFQDN, HeartbeatUTC

Retirar la rotación forzada con seguridad

Elimine la caducidad solo cuando se cumpla todo lo siguiente: la lista de bloqueo está en modo de aplicación, la longitud mínima es de 14 o más, la MFA cubre el acceso remoto y las aplicaciones en la nube, y dispone de un proceso para forzar restablecimientos ante indicios de compromiso (fuentes de filtraciones, alertas de inicios de sesión de riesgo, respuesta a incidentes). Después, establezca Maximum password age en 0 en el GPO del dominio y desactive Enforce maximum password age en las PSO de usuarios y administradores. La caducidad se calcula a partir de pwdLastSet y de la directiva efectiva, así que los avisos de caducidad pendientes desaparecen de inmediato; no cambia nada más.

Verificar

# Directiva efectiva para cuentas representativas
"jdoe","adm-jdoe","svc_legacyapp" | ForEach-Object {
    $pso = Get-ADUserResultantPasswordPolicy -Identity $_
    [pscustomobject]@{ User = $_; PSO = $pso.Name; MinLength = $pso.MinPasswordLength }
}

# No quedan marcas que eludan la directiva
(Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=32)').Count

Para un usuario sin PSO, Get-ADUserResultantPasswordPolicy no devuelve nada, lo que significa que se aplica la directiva del dominio. Pruebe un cambio con una contraseña que sepa que está prohibida, como el nombre de la empresa seguido del año, y confirme que se rechaza. Repita la auditoría de calidad de contraseñas cada trimestre y haga seguimiento del número de hashes filtrados y compartidos como métrica.

Qué se rompe

• Las contraseñas cortas existentes siguen funcionando. Una longitud mínima mayor no se comprueba contra las contraseñas actuales; los usuarios solo quedan sujetos a ella la próxima vez que cambien la contraseña. En cambio, los portales de restablecimiento de autoservicio y los restablecimientos por script que generan contraseñas cortas fallan de inmediato.
• Las aplicaciones que validan las contraseñas por su cuenta (algunas VPN, sistemas de RR. HH. que sincronizan contraseñas) pueden rechazar longitudes superiores a 14 o 16 caracteres.
• Quitar el bloqueo a las cuentas de servicio hace posible la adivinación en línea contra ellas; solo es aceptable con más de 30 caracteres aleatorios y supervisión de los errores 4625 y 4771.
• Las DLL de filtro de contraseñas en los DC pueden bloquear todos los cambios de contraseña si el agente falla gravemente; despliéguelas primero en un solo DC y tenga un plan de reversión.
• Eliminar la rotación puede entrar en conflicto con un control de cumplimiento escrito hasta que se actualice el documento de la directiva.

Lecturas relacionadas: el tema Contraseñas y cuentas de servicio, la guía principal sobre hardening de cuentas de servicio y hardening de Kerberos, donde la longitud de la contraseña determina directamente cuánto tarda un ataque sin conexión contra un ticket de servicio.