Política de contraseñas por grupo en Active Directory (PSO)

La directiva de contraseñas del dominio de Active Directory es una sola: se define en la política de grupo del dominio y se aplica por igual a todos los usuarios. Eso es un problema en cuanto aparecen necesidades distintas. Los administradores deberían usar contraseñas mucho más largas que el resto, las cuentas de servicio no pueden caducar cada 42 días sin romper aplicaciones, y a un grupo de usuarios con poca experiencia quizá le convenga un bloqueo de cuenta más tolerante.

Para eso existen las políticas de contraseña específicas (fine-grained password policies, FGPP), también llamadas objetos de configuración de contraseña o PSO (Password Settings Objects). Permiten aplicar reglas distintas a usuarios o grupos concretos dentro del mismo dominio. En esta guía verás cuándo conviene usarlas, qué requisitos tienen, cómo crearlas con PowerShell y cómo comprobar qué política recibe realmente cada usuario.

Qué es una PSO y en qué se diferencia de la directiva del dominio

La directiva de contraseñas de dominio se configura en la GPO del dominio (normalmente Default Domain Policy) y establece longitud mínima, complejidad, historial, caducidad y bloqueo de cuenta para todos. Una PSO es un objeto de Active Directory, guardado en el contenedor Password Settings Container dentro de System, que define esos mismos parámetros pero se asigna a quien tú elijas. Microsoft introdujo esta función en Windows Server 2008 y, según su documentación, un usuario o grupo con una PSO asignada la usa en lugar de la política del dominio.

Hay tres limitaciones que conviene conocer desde el principio:

Se asignan a usuarios y a grupos de seguridad globales, no a unidades organizativas. Si quieres que una OU entera reciba una PSO, la solución habitual es crear un grupo global (a veces llamado «grupo sombra») que contenga a los usuarios de esa OU y asignar la PSO al grupo.
Solo afectan a contraseñas y bloqueo de cuenta. La política Kerberos (duración de tickets, por ejemplo) sigue definiéndose únicamente a nivel de dominio.
Requieren un nivel funcional de dominio mínimo de Windows Server 2008. Si tu dominio está en un nivel anterior, primero hay que elevarlo. Tienes el procedimiento en la guía para elevar el nivel funcional del bosque y del dominio.

Cuándo tiene sentido crear una PSO

Caso	Qué se suele hacer
Cuentas con privilegios (administradores del dominio)	Longitud mínima mayor, historial largo y bloqueo más estricto
Cuentas de servicio	Contraseña muy larga y compleja, sin caducidad periódica, con rotación controlada por otro proceso
Usuarios de kiosco o puestos compartidos	Umbral de bloqueo más permisivo si hay errores frecuentes al escribir
Colectivos con requisitos de cumplimiento distintos	Reglas propias sin cambiar la política del resto de la empresa

Antes de crear nada, conviene decidir qué política quieres. Los criterios actuales se han alejado de la caducidad obligatoria cada pocas semanas: las líneas base de seguridad de Microsoft dejaron de recomendar la expiración periódica a partir de 2019, y las guías de identidad digital del NIST (SP 800-63B) priorizan contraseñas largas, la comprobación contra listas de claves conocidas y el cambio solo cuando hay indicios de compromiso. Una PSO es la herramienta para aplicar esa política a quien corresponda sin cambiar el criterio del resto del dominio de golpe.

Qué parámetros se pueden definir

Parámetro de New-ADFineGrainedPasswordPolicy	Qué controla
`-Precedence`	Prioridad cuando varias PSO afectan al mismo usuario (el número menor gana)
`-MinPasswordLength`	Longitud mínima
`-PasswordHistoryCount`	Cuántas contraseñas anteriores se recuerdan
`-ComplexityEnabled`	Exige complejidad
`-ReversibleEncryptionEnabled`	Almacenamiento reversible (debe estar en `$false` salvo que una aplicación lo exija)
`-MinPasswordAge` / `-MaxPasswordAge`	Edad mínima y máxima de la contraseña
`-LockoutThreshold`	Intentos fallidos antes de bloquear la cuenta
`-LockoutObservationWindow`	Ventana en la que se cuentan los intentos fallidos
`-LockoutDuration`	Cuánto dura el bloqueo (0 = hasta que un administrador lo desbloquee)
`-ProtectedFromAccidentalDeletion`	Protege el objeto de borrados accidentales

Una nota sobre la longitud: la interfaz clásica de la directiva de dominio limita la longitud mínima a un máximo bajo, mientras que una PSO admite valores muy superiores (hasta 255 caracteres), lo que resulta práctico para frases de contraseña en cuentas privilegiadas.

Crear una PSO con PowerShell, paso a paso

Necesitas el módulo ActiveDirectory (viene con las herramientas RSAT de Active Directory) y una cuenta con permisos para crear objetos en el contenedor de PSO; por defecto, los administradores del dominio. Este ejemplo crea una política para administradores: 16 caracteres, historial de 24, bloqueo tras 5 intentos fallidos durante 30 minutos.

New-ADFineGrainedPasswordPolicy -Name "PSO-Administradores" `
    -Precedence 10 `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MinPasswordAge "1.00:00:00" `
    -MaxPasswordAge "90.00:00:00" `
    -LockoutThreshold 5 `
    -LockoutObservationWindow "00:30:00" `
    -LockoutDuration "00:30:00" `
    -ProtectedFromAccidentalDeletion $true

Los intervalos de tiempo se escriben como días.horas:minutos:segundos. Un detalle que provoca errores: la duración del bloqueo no puede ser menor que la ventana de observación, y la edad mínima no puede superar a la máxima. Los valores de arriba son un ejemplo, no una recomendación universal; ajústalos a la política de seguridad de tu organización.

La política todavía no afecta a nadie. Para asignarla a un grupo existente:

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Administradores" -Subjects "Admins. del dominio"

El nombre del grupo depende del idioma del sistema («Domain Admins» en inglés, «Admins. del dominio» en español). Puedes asignar la PSO a varios sujetos separándolos con comas, o a un usuario concreto. Si lo prefieres, también puedes crear y editar PSO con el Centro de administración de Active Directory: en el árbol, dominio, System, Password Settings Container, y desde ahí Nuevo y Configuración de contraseña.

Cómo decide Windows qué política aplica

Cuando un usuario podría recibir varias políticas, el orden es este:

Si el usuario tiene una PSO asignada directamente, gana esa. Si tiene varias directas, prevalece la de menor valor de precedencia.
Si no, se consideran las PSO asignadas a los grupos de los que es miembro, y gana la de menor precedencia.
Si no hay ninguna PSO que le afecte, se aplica la directiva de contraseñas del dominio.

Por eso conviene dar a cada PSO un valor de precedencia distinto y dejar huecos entre ellos (10, 20, 30…) para poder intercalar políticas futuras. Dos PSO con la misma precedencia que afecten al mismo usuario son una fuente de confusión; evítalo.

Comprobar qué política recibe un usuario

Esta es la comprobación más importante y la que menos se hace. Para ver la política efectiva de un usuario:

Get-ADUserResultantPasswordPolicy -Identity "jperez"

Si devuelve un objeto, ese es el PSO que se le aplica. Si no devuelve nada, el usuario está bajo la política del dominio, que puedes consultar con Get-ADDefaultDomainPasswordPolicy. El Centro de administración de Active Directory ofrece lo mismo con el botón derecho en un usuario y la opción «Ver configuración de contraseña resultante».

Para auditar todas las políticas y sus destinatarios:

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

Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-Administradores"

Modificar, retirar y errores frecuentes

Para cambiar un valor se usa Set-ADFineGrainedPasswordPolicy. Para quitar a alguien de una PSO, Remove-ADFineGrainedPasswordPolicySubject, y para eliminarla del todo, Remove-ADFineGrainedPasswordPolicy (si la protegiste contra borrado accidental, primero hay que desactivar esa protección, igual que ocurre con una unidad organizativa protegida; la guía para eliminar una unidad organizativa protegida explica el mecanismo).

«Se aplicó la PSO pero no hace efecto». Comprueba que el usuario es miembro directo del grupo al que asignaste la PSO (no des por hecho que la pertenencia anidada se evalúa como esperas) y verifica el resultado con Get-ADUserResultantPasswordPolicy. Recuerda que el cambio de contraseña ya hecho no se revalida: la nueva política se exige en el siguiente cambio.
«No puedo asignarla a una OU». Es una limitación de diseño: usa un grupo global como intermediario.
Error al crear la PSO. Verifica el nivel funcional del dominio y que tu cuenta tenga permiso sobre el contenedor Password Settings Container. Si necesitas inspeccionar atributos del objeto, el editor de atributos de Active Directory muestra, por ejemplo, la precedencia y los sujetos de la PSO.
Cuentas de servicio que dejan de funcionar. Si una PSO nueva activa la caducidad, la cuenta de servicio puede quedar con la contraseña vencida. Planifica la rotación antes de aplicar la política.
Bloqueos inesperados. Un umbral de bloqueo muy bajo en una PSO amplia puede generar bloqueos masivos por aplicaciones con credenciales antiguas. Prueba primero con un grupo piloto.

Relación con la política de complejidad del dominio

Si solo necesitas cambiar la complejidad o la longitud para todo el dominio, no hace falta una PSO: se configura en la política de grupo del dominio, como se explica en la guía de configuración de la complejidad de la contraseña en Active Directory. Las PSO se reservan para excepciones y colectivos con necesidades distintas. Un buen criterio: mantén una política de dominio razonable para la mayoría y crea PSO solo para los grupos que de verdad lo necesiten; cuantas más PSO haya, más difícil es razonar sobre qué recibe cada persona.

Buenas prácticas antes de llevarlo a producción

Documenta cada PSO (nombre, motivo, precedencia, destinatarios y responsable).
Prueba con un grupo piloto y verifica con Get-ADUserResultantPasswordPolicy.
Comunica el cambio a los usuarios afectados: la nueva exigencia se nota en el siguiente cambio de contraseña.
Revisa los eventos de bloqueo de cuenta durante los primeros días.
Revisa periódicamente la lista de PSO y sus destinatarios.

Puedes ampliar los conceptos en la documentación de Microsoft sobre el Centro de administración de Active Directory, que incluye la sección de políticas de contraseña específicas, y en la lista oficial de cmdlets *-ADFineGrainedPasswordPolicy* del módulo ActiveDirectory.

Resumen

Una PSO aplica reglas de contraseña y bloqueo distintas a usuarios o grupos concretos, sin cambiar la política del dominio.
Se asigna a usuarios y grupos globales, no a OU, y exige nivel funcional de dominio Windows Server 2008 o superior.
Con varias PSO, gana la asignada directamente al usuario y, después, la de menor precedencia.
Crea con New-ADFineGrainedPasswordPolicy, asigna con Add-ADFineGrainedPasswordPolicySubject y verifica con Get-ADUserResultantPasswordPolicy.
Prueba con un grupo piloto y planifica la rotación de cuentas de servicio antes de activar caducidad.