MENU
  1. Inicio
  2. Microsoft 365
  3. Caducidad selectiva de contraseñas en Microsoft Entra ID híbrido con FGPP

Caducidad selectiva de contraseñas en Microsoft Entra ID híbrido con FGPP

Microsoft 365

¿Necesitas que solo un subconjunto de usuarios cambie su contraseña cada 180 días aunque trabajes en un entorno híbrido con Microsoft Entra ID, Active Directory on‑premises, Azure AD Connect y dispositivos gestionados por Intune? Este artículo explica paso a paso cómo lograrlo sin sacrificar experiencia de usuario ni romper la sincronización de identidades.

Índice

Panorama de restricciones de la plataforma

Antes de diseñar cualquier solución conviene recordar cómo funcionan las políticas de expiración según el origen de la cuenta.

Ubicación de la cuenta¿Se puede caducar por grupo?Comentarios clave
Entra ID (solo‑cloud)No. La caducidad es de inquilino; únicamente se permiten excepciones individuales mediante DisablePasswordExpiration.La granularidad es “todo el inquilino” salvo excepciones manuales usuario a usuario.
Entra ID sincronizadaNo. Al habilitar EnforceCloudPasswordPolicyForPasswordSyncedUsers, la expiración cloud se aplica a todos los objetos sincronizados.Si se deja deshabilitado (valor predeterminado) Entra ID respeta el atributo pwdLastSet que llega desde AD.
Active Directory on‑premSí. Las Fine‑Grained Password Policies (FGPP) permiten asignar valores de expiración distintos a grupos específicos.Al sincronizar con PHS/PTA, Entra ID aplica el mismo vencimiento que define pwdLastSet.

Fine‑Grained Password Policies en detalle

Qué son las FGPP

Introducidas en Windows Server 2008, las FGPP son objetos de directorio (Password Settings Objects, PSO) almacenados en el contenedor CN=Password Settings Container,CN=System. Un PSO incluye atributos como máxima y mínima edad, historial, longitud y complejidad. A diferencia de la Default Domain Policy, la FGPP se enlaza directamente a usuarios o a grupos, lo que ofrece la granularidad que el escenario híbrido requiere.

Configuración paso a paso

El procedimiento estándar consta de tres fases: crear un grupo de seguridad, definir el PSO y enlazarlo al grupo.

# 1. Crear el grupo
New-ADGroup -Name "Pwd180DayUsers" -GroupScope Global -Path "OU=Groups,DC=contoso,DC=com"

2. Definir el PSO
New-ADFineGrainedPasswordPolicy `
  -Name "FGPP‑180Days" `
  -Precedence 10 `
  -MaxPasswordAge (New-TimeSpan -Days 180) `
  -MinPasswordAge (New-TimeSpan -Days 1) `
  -PasswordHistoryCount 24 `
  -MinPasswordLength 14 `
  -PasswordComplexityEnabled $true

3. Vincular PSO al grupo
Add-ADFineGrainedPasswordPolicySubject `
  -Identity "FGPP‑180Days" `
  -Subjects "CN=Pwd180DayUsers,OU=Groups,DC=contoso,DC=com"

💡 Sugerencia: Establece la precedence en un número bajo para asegurarte de que, si en el futuro surge otra FGPP, la de 180 días siga teniendo prioridad.

Comprobación y validación

Get-ADUserResultantPasswordPolicy -Identity juan.garcia

El cmdlet muestra la política efectiva. Si el usuario está en el grupo Pwd180DayUsers, verás el MaxPasswordAge = 180.00:00:00.

Flujo de expiración en entornos híbridos

Cuando sincronizas con Password Hash Sync (PHS) el atributo pwdLastSet se copia a Entra ID cada 30 minutos (por defecto). El servicio cloud recalcula la fecha de expiración y la compara en cada autenticación. El flujo simplificado es el siguiente:

  1. El usuario Juan actualiza su contraseña el 1 de enero.
  2. AD establece pwdLastSet=2025‑01‑01 00:00:00Z.
  3. Azure AD Connect envía el hash y el timestamp en la siguiente sincronización.
  4. A partir del 30 de junio (día 180) Entra ID marca la cuenta como “contraseña expirada”.
  5. El próximo inicio de sesión en Microsoft 365 muestra el pop‑up de cambio de contraseña.
  6. Si el usuario cambia la contraseña en ese momento, ocurre password write‑back hacia AD y comienza un nuevo ciclo.

📌 Importante: No existe un banner anticipado integrado en M365 para cuentas PHS. Si necesitas avisar con antelación, implementa un script que consulte pwdLastSet y envíe recordatorios por correo.

Automatización y monitorización

A continuación se muestra un fragmento de script que lista usuarios cuya contraseña expira en los próximos 14 días y genera un CSV para notificación:

# Parámetros
$DaysAhead = 14
$FGPPName  = "FGPP‑180Days"
$Today     = Get-Date

Obtiene fecha máxima de contraseña
$MaxAge = (Get-ADFineGrainedPasswordPolicy $FGPPName).MaxPasswordAge

Obtiene usuarios del grupo
$Users = Get-ADGroupMember -Identity "Pwd180DayUsers" -Recursive | Where-Object { $_.objectClass -eq 'user' }

$Report = foreach ($User in $Users) {
    $U = Get-ADUser $User -Properties DisplayName,pwdLastSet,mail
    $ExpiryDate = $U.pwdLastSet + $MaxAge
    if ($ExpiryDate -le $Today.AddDays($DaysAhead)) {
        [PSCustomObject]@{
            User        = $U.DisplayName
            Email       = $U.mail
            ExpiryDate  = $ExpiryDate
        }
    }
}

$Report | Export-Csv ".\PwdExpiryReport.csv" -NoTypeInformation

Programa el script en Task Scheduler cada mañana y envía el CSV a tu equipo de soporte o a un runbook de Azure Automation que dispare correos dirigidos.

Alternativas en la nube

Escenario¿Cuándo usarlo?VentajasInconvenientes
Convertir usuarios a solo‑cloud y fijar caducidad de 180 días
Excepción individual con DisablePasswordExpiration		Cuando planeas retirar AD on‑prem y la cantidad de excepciones es bajaGestión puramente cloud; elimina la dependencia de DCs localesNo hay caducidad por grupo; se requieren scripts o Graph API para marcar excepciones una a una
Azure AD Domain Services (AAD DS) con políticas personalizadasSi ya utilizas AAD DS para máquinas virtuales legacyPermite FGPP gestionables desde la nubeNo influye en el login de Microsoft 365; pensado para SMB y LDAP dentro de IaaS

Errores frecuentes y resolución

  • La contraseña expira antes de 180 días: Verifica si otra FGPP con precedence menor está pisando la configuración.
  • El usuario no recibe aviso de expiración: Recuerda que con PHS no hay banner; usa scripts o Security Defaults.
  • Se habilitó EnforceCloudPasswordPolicyForPasswordSyncedUsers por error: Desactívalo y fuerza un full sync para restaurar la autoridad a AD.
  • Diferencias de hora tras un restore del DC: Comprueba la replicación de pwdLastSet y la sincronización de tiempo en todos los controladores.
  • Password write‑back falla: Asegúrate de que los Azure AD Connect Sync Rules de SSPR están habilitados y que la cuenta del agente tiene permisos de restablecimiento.
  • Ping de latencia elevado en AAD Connect: Divide el scope en múltiples staging servers o ajusta el intervalo de pull a 15 min en lugar de 30 min solo para críticos.

Mejores prácticas y consideraciones adicionales

  • Longitud mínima de 14 caracteres: Con FGPP puedes reforzar la longitud incluso si el dominio aún soporta 8+3.
  • Historial de 24: Evita que los usuarios roten entre las mismas 3 contraseñas cada semestre.
  • Habilita SSPR con MFA: Los permisos de password write‑back ya están incluidos en Microsoft 365 Business Premium.
  • Documenta los PSO: Añade una descripción clara y guarda evidencias en tu sistema ITSM.
  • Monitoriza con Entra ID Audit Logs: Crea alertas cuando un usuario cambie contraseña fuera de la ventana esperada, posible señal de compromiso.
  • Revisión semestral: Audita los miembros del grupo Pwd180DayUsers y elimina cuentas inactivas.
  • Política coherente de bloqueo de cuenta: Alinea los valores de account lockout en la misma FGPP para evitar que Password Spray genere falsos positivos.

Preguntas frecuentes

¿Puedo ver cuántos días le quedan a cada usuario desde el portal de Entra ID? No de forma nativa. El atributo pwdLastSet no se expone en la UI, pero sí a través de Azure AD Graph o Microsoft Graph beta. ¿Qué pasa si uso Pass‑Through Authentication en vez de PHS? El flujo de expiración es idéntico: Entra ID consulta pwdLastSet antes de derivar la autenticación al agente PTA. ¿Influye esta configuración en Windows Hello for Business sin PIN reset? No. La caducidad de contraseña no obliga a cambiar el PIN, pero al vencerse la clave el usuario deberá autenticarse con su nueva contraseña antes de desbloquear. ¿Cómo gestiono las cuentas de servicio que nunca deben expirar? Mantenlas en un grupo separado y aplícales un PSO con MaxPasswordAge=0 (no expira) o marca userAccountControl = 66048 en el atributo on‑prem. ¿Existe límite de PSO por dominio? Técnicamente 1.000, pero Microsoft recomienda no superar 100 para facilitar el troubleshooting.

Conclusión

La única vía oficialmente admitida para aplicar caducidad diferenciada a un subconjunto de usuarios en un entorno híbrido es delegar la expiración a Active Directory on‑premises mediante Fine‑Grained Password Policies. Al sincronizar pwdLastSet con Azure AD Connect, Microsoft Entra ID respeta ese valor y fuerza el cambio de contraseña con la interfaz estándar de Microsoft 365, cumpliendo así los requisitos de seguridad sin afectar al resto de la organización.

Fuentes

[1]: Microsoft Q&A – “Cómo crear una política de expiración de contraseñas para un grupo específico en Azure”
[2]: Microsoft Q&A – “EnforceCloudPasswordPolicyForPasswordSyncedUsers con dominio federado”
[3]: Microsoft Learn – “Preguntas frecuentes sobre restablecimiento de contraseña autoservicio”

Microsoft 365
Microsoft 365 Password Expiration Entra ID FGPP Hybrid Identity
Índice