El extraño caso de Password Synchronization para usuarios cuyo password ha expirado On-Premises y puede seguir iniciando sesión a la nube con dicho Password.

Por: Hernan Bohl

• ¿Tienen ustedes usuarios cuyos por ejemplo que están en el campo y no inician sesión al ambiente On-premises?
• ¿Están ustedes utilizando Password Syncronization?

Si la respuesta a estas dos preguntas es sí, entonces este articulo será de su interés.

Recientemente trabajé en un incidente de soporte, en donde los usuarios estaban utilizando password syncronization, pero a dichos usuarios ya les había expirado el password en el ambiente On-Premises. La política de Password On-premises, indicaba que el password debería expirar luego de un mes, pero los usuarios podían seguir iniciando sesión con dicho password expirado en la nube.

Si revisamos el articulo referenciado arriba acerca de implementación de sincronización de contraseñas, vamos a encontrar los siguientes párrafos:

• Al habilitar la sincronización de contraseñas, las directivas de complejidad de contraseñas configuradas en el Active Directory local anulan las directivas de complejidad que pueda haber definidas en la nube para los usuarios sincronizados. Esto significa que cualquier contraseña válida en el entorno de Active Directory local del cliente se puede usar para acceder a los servicios de Azure AD.
• Las contraseñas de los usuarios que se crean directamente en la nube siguen estando sujetas a directivas de contraseñas tal y como se define en la nube.
• Si un usuario está en el ámbito de la característica Sincronización de contraseñas, la contraseña de la cuenta en la nube se establece en "No caducar nunca". Esto significa que es posible que la contraseña de un usuario caduque en el entorno local y que este pueda seguir iniciando sesión en los servicios en la nube usando la contraseña caducada.
• Un administrador puede restablecer manualmente una contraseña de usuario con Azure Active Directory PowerShell. En este caso, la nueva contraseña invalidará la contraseña sincronizada del usuario y todas las directivas de contraseñas definidas en la nube se aplicarán a la nueva contraseña.
• Si el usuario vuelve a cambiar la contraseña local, la nueva contraseña se sincronizará en la nube e invalidará la contraseña actualizada manualmente.

Si leemos detenidamente los párrafos anteriores, llegaremos a la conclusión, de que si un usuario inicia sesión ocasionalmente al ambiente On-premises, entonces no se le requerirá que se cambie el password y, en consecuencia, como dice el párrafo anterior resaltado, podrá seguir utilizando ese password expirado hasta que lo cambie, obviamente, en el ambiente On-Premises. Esto es, porque la idea es que la política de password solo se administre On-premises.

Probablemente estarán pensando, y entonces ¿porque no le cambio el atributo PasswordNeverExpires a False en el objeto asociado en Windows Azure AD?

Como dice la documentación, si un usuario está dentro del ámbito de sincronización de passwords el atributo PasswordNeverExpires se cambiará a True.

Ejemplo de cómo luce el usuario cuando cae dentro del ambito de Password Sync:

Cambiando el atributo PasswordNeverExires a False manualmente:

Asegurándome que el password se replicó:

Verificando como luce el usuario luego de replicar el cambio de password:

Conclusión

En este tipo de casos, vamos a necesitar seguir algunas de las alternativas abajo:

• Crear los usuarios directamente en la nube para que se rijan con las políticas de passwords en la nube.
• Utilizar identidades federadas. De esta manera nos vamos a tener que iniciar sesión a recursos de On-Premises y cuando el password expire, vamos a recibir la solicitud de cambiarlo.
• Asegurarnos que los usuarios se iniciar sesión a recursos On-premises con una periodicidad suficiente para poder cambiar el password antes de que expire.