MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Solución definitiva a la expiración anticipada de contraseñas en Active Directory

Solución definitiva a la expiración anticipada de contraseñas en Active Directory

Windows Server

¿Tus usuarios reciben avisos de “Su contraseña expirará en 0 días” aun cuando configuraste un vencimiento de 365 días en la Default Domain Policy? Tranquilo: no es un bug de Windows Server, sino la acción silenciosa de una política de contraseñas alternativa que está tomando el control.

Índice

Cómo se evalúa realmente la edad de la contraseña en Active Directory

En el pensamiento clásico de las Group Policy Objects, asumimos que la GPO más vinculada —por ejemplo, la Default Domain Policy— dicta la configuración final. Sin embargo, la Password Policy es la gran excepción a la regla:

  • Los parámetros de contraseña (minPasswordAge, maxPasswordAge, complejidad, historial, etc.) no se procesan como una “directiva de equipo” convencional.
  • Cuando una contraseña se cambia, el DC consulta atributos del objeto dominio en lugar de una lista de GPO.
  • Esto implica que herramientas como gpresult /R o el visor de Resultant Set of Policy muestran la GPO aplicada, pero no prueban que sea la efectiva.

El villano inesperado: Fine‑Grained Password Policies (FGPP)

Desde Windows Server 2008 existe la opción de crear Password Settings Objects (PSO), más conocidas como Fine‑Grained Password Policies. Su prioridad vence a la política de dominio para usuarios o grupos concretos, incluso si nunca has abierto la consola de Password Policy a nivel de dominio.

# Enumerar todas las PSO
Get-ADFineGrainedPasswordPolicy -Filter *

Ver la política resultante de un usuario
Get-ADUserResultantPasswordPolicy <usuario>

En entornos grandes, un ingeniero de directorio o un software de terceros (p. ej. herramientas de auditoría) puede haber generado un PSO “temporal” de 30 o 42 días para un grupo de prueba y, años después, nadie recuerda su existencia. El resultado: cada vez que esos usuarios cambian la contraseña, el DC usa el valor de MaxPasswordAge del PSO, no el de la política de dominio.

Ruta rápida de diagnóstico

PasoComandoQué debes ver
Confirmar política de dominioGet-ADDefaultDomainPasswordPolicyMaxPasswordAge = 365 d
Mostrar valor efectivonet accounts /domain“Maximum password age  365 days”
Listar PSO existentesGet-ADFineGrainedPasswordPolicy -Filter *¿Aparece alguna? Ver columna MaxPasswordAge
Política de un usuarioGet-ADUserResultantPasswordPolicy juanpDebe coincidir con la de MaxPasswordAge=365 d
Atributo de uniónEn ADSI Edit, ver msDS-ResultantPSOVacío = usa política de dominio

Corregir la prioridad o eliminar el PSO

Cada PSO posee dos atributos fundamentales:

  • Precedence (msDS-PasswordSettingsPrecedence): entero positivo; el menor valor gana. Si dos PSO se aplican al mismo usuario, la de menor precedencia es la efectiva.
  • AppliesTo: lista de usuarios o grupos de seguridad que heredan la configuración.

Para resolver el conflicto, tienes tres opciones:

  1. Ajustar MaxPasswordAge en el PSO a 365 días (o al número deseado).
  2. Aumentar la precedencia numérica para que la política de dominio venza.
  3. Eliminar el PSO si ya no tiene sentido.
# Ejemplo: elevar precedencia para que pierda prioridad
Set-ADFineGrainedPasswordPolicy "PSO_Temporario" -Precedence 999

Ejemplo: borrar PSO
Remove-ADFineGrainedPasswordPolicy "PSO_Deprecado"

¿Y los valores de registro en el DC?

Quizá encuentres consejos antiguos que mencionan HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge. Esa clave solo regula la caché segura del canal de equipo (Secure Channel) y no afecta a la expiración de contraseñas de usuario. No pierdas tiempo depurando allí.

Por qué gpresult no es la herramienta adecuada

Aunque gpresult /R muestre “Password Policy – Maximum Password Age = 365 days” bajo la sección Computer Settings, esto refleja que la GPO se ha descargado, no que se aplicará. El componente de LSASS responsable de la seguridad de cuentas consulta directamente los valores guardados en el objeto de dominio (maxPwdAge) o en PSO, ignorando la “resultante de GPO”.

¿Puede una política local anular la de dominio?

No. Las Local Security Policies modifican exclusivamente cuentas locales (SAM database) de ese equipo. Los usuarios de dominio continúan sometidos a la política que dicta el DC que valida sus credenciales.

Buenas prácticas para prevenir futuros sobresaltos

  • Inventario regular de PSO. Programa un script que exporte la lista de PSO y sus atributos críticos, enviándolos por correo a tu equipo de IT cada mes.
  • Auditoría de cambios en Password Policy. Habilita el registro de eventos de Directorio AD (evento 4739) y configura alertas cuando maxPwdAge o minPwdAge cambien.
  • Estandariza la precedencia. Utiliza rangos claros (p. ej. 1‑100 para producción, 900‑999 para pruebas) y documenta al crear una nueva PSO.
  • Procedimiento de cambio. No permitas modificaciones directas en ADAC sin ticket y revisión entre pares.

Receta de recuperación paso a paso

Si ya estás en crisis porque la empresa entera deberá cambiar contraseñas mañana, sigue este guion mínimo:

  1. Identifica el PSO culpable. Usa Get-ADFineGrainedPasswordPolicy y ordena por MaxPasswordAge. El de 30 o 42 días será tu principal sospechoso.
  2. Confirma los usuarios afectados. Get-ADUser -Filter * | ? { (Get-ADUserResultantPasswordPolicy $).Name -eq 'PSOCorto' }
  3. Evalúa el impacto de cambiarlo. Un ajuste de MaxPasswordAge no invalida contraseñas ya expiradas; necesitarás restablecer los flags de expiración (pdbLastSet = 0 o -Clear uPwdReset).
  4. Actualiza la política. Set-ADFineGrainedPasswordPolicy 'PSO_Corto' -MaxPasswordAge 365.00:00:00
  5. Reinicia Netlogon en todos los DC o espera replicación AD (depende del SLA). Después, fuerza gpupdate /force en clientes críticos.

Preguntas frecuentes

¿Cuánto tarda en hacerse efectiva la nueva edad de contraseña?

En el mismo momento en que el DC recibe la replicación del cambio. Las sesiones abiertas no obligan al usuario a cerrar; la nueva fecha se recalcula en el siguiente inicio de sesión o al cambiar contraseña.

¿Puedo combinar varias PSO para un mismo usuario?

Sí, pero solo una será la efectiva: la de menor valor en Precedence. Evita solapamientos salvo que sea estrictamente necesario.

¿Qué sucede si elimino todas las PSO?

Todos los usuarios y grupos volverán a heredar la contraseña del dominio. Útil como “botón nuclear” para restablecer la coherencia, pero documenta antes de borrarlas.

Conclusión

La expiración inesperada de contraseñas en 40 días suele ser un síntoma claro de una Fine‑Grained Password Policy olvidada. Armado con los cmdlets de ActiveDirectory y un enfoque sistemático —auditar la política de dominio, localizar PSO, verificar precedencia y limpieza— volverás a un ciclo de 365 días en menos tiempo del que lleva resetear 500 contraseñas manualmente.

Windows Server
Índice