Office 365: forzar cambios de contraseña por grupos de usuarios

Es muy común tener diferentes políticas de cambios de contraseña en On-Premises [https://docs.microsoft.com/es-es/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770394(v=ws.10)], pero de momento para nuestros usuarios 100% Cloud [AzureAD] de momento no es posible de forma “nativa”. Esto no quiere decir que no podamos, sino que debemos “tirar de ingenio” + PowerShell + Automatic Task Azure.

Como todos sabemos, en AzureAD no podemos tener diferentes políticas de expiración de contraseñas, por lo que, o bien tenemos usuarios a los cuales no les expira la contraseña [Set-AzureADUser -ObjectId <usuario> -PasswordPolicies DisablePasswordExpiration] o todos tendrán el mismo tiempo de expiración. Por lo que, si queremos que algunos de nuestros usuarios cambien su contraseña a los 30 días, otros a 60 y otros a 90 días .. vamos a tener que realizar alguna configuración conjunta entre PowerShell y Azure.

Podemos restablecer la contraseña de lo usuarios, pero esto hace que nos genere una contraseña nueva y tenemos que entregársela al usuario para que luego él, pueda cambiarla en el primer inicio de sesión. Pero nosotros lo que queremos, es que a los x días al usuario le solicite cambiar su contraseña una vez haya completado un inicio de sesión y esto es lo que os voy a mostrar.

Antes de meternos de lleno con la configuración, os dejo una pequeña infografía sobre el proceso de tener diferentes usuarios a los cuales se les pedirá que cambien su contraseña en diferentes ventanas temporales:

Nuestro objetivo es configurar que diferentes a nuestros usuarios se les pida cambiar la contraseña obligatorios de forma obligatoria, en fechas diferentes y sin cambiar previamente su contraseña actual. Pues bien, como esto es algo que no tenemos en una configuración directa en Azure, nos tenemos que buscar un poco la vida para lograrlo, pero será muy sencillo.

Como el objetivo lo tenemos claro, veamos como podemos crear grupos de usuarios a los cuales mediante PowerShell les vamos a pedir un cambio de contraseña [Set-MsolUserPassword -UserPrincipalName <nombre-usuario> -ForceChangePasswordOnly $true -ForceChangePassword $true]. Si queremos hacerlo sobre un grupo de usuarios, podemos crear grupos de Office 365 [con asignación directa o dinámica de usuarios] y sobre los miembros de dicho grupo aplicar el comando Set-MsolUserPassword.

Nota: la creación de grupos dinámicos no la voy a explicar aquí, pero os dejo un enlace para que podáis ver como se crean: Creación o actualización de un grupo dinámico en Azure Active Directory

Aquí os dejo como sería el script de PowerShell para lograr ese objetivo [busca los miembros del grupo Nombre-Grupo-O365 y a cada uno le fuerza el cambio de contraseña]:

• $Grupo = Get-MsolGroup -SearchString “Nombre-Grupo-O365”
• $Usuarios = Get-MsolGroupMember -GroupObjectId $Grupo.ObjectId
• foreach ($user in $Usuarios) {Set-MsolUserPassword -UserPrincipalName $user.EmailAddress -ForceChangePasswordOnly $true -ForceChangePassword $true}

Para poder ejecutar dicho script, previamente debemos conectaros con O365 para ello, debemos previamente ejecutar Connect-MsolService y utilizar una cuenta de usuario con los permisos necesarios sobre los usuarios a los cuales queremos forzar el cambio de contraseña. Hasta aquí creo que ha sido súper sencillo, simplemente tenemos que ir ejecutando los diferentes comandos y listo, ya tenemos a nuestros usuarios del grupo Nombre-Grupo-O365 listos para que le pida el cambio de contraseña forzado sin tener que resetearles la cuenta.

Una vez ejecutado el comando Set-MsolUserPassword, el cambio no es inmediato, tiene un delay más o menos de 10 minutos [debemos tenerlo en cuenta]

Lo de utilizar un grupo de seguridad es por tener una manera de identificar los usuarios a los cuales queremos forzar el cambio de contraseña, pero vamos, podemos buscarlos utilizando filtros por atributos de los usuarios, etc… Yo personalmente creo que lo mejor es utilizar grupos, bien dinámicos o no, pero siempre grupos con nombres descriptivos, a continuación os expongo un ejemplo de nombres de grupos:

• Acl Az Change Password 30D: sus miembros tendrán un cambio de contraseña a los 30 días
• Acl Az Change Password 60D: sus miembros tendrán un cambio de contraseña a los 60 días
• Acl Az Change Password 90D: sus miembros tendrán un cambio de contraseña a los 90 días

Ya explicado este detalle, l0 que nos queda es como automatizar la ejecución de este script y que podamos forzar el cambio de contraseña a nuestros usuarios. Pues bien, para esto vamos a crear un Runbook en una cuenta de automatización de Azure!! La creación de la cuenta de automatización de Azure no la voy a comentar en este artículo, pero aquí os dejo información al respecto:

• Microsoft Azure: Ejecutar Scripts de O365 desde Cuentas de Automatización – Blog Santiago Buitrago (santiagobuitragoreis.com)
• Creación de tareas de automatización para administrar y supervisar recursos de Azure – Azure Logic Apps | Microsoft Docs

En el primer enlace os muestro ya como ejecutar comandos de O365 desde Azure, pero volveré a comentarlo para los que no queráis a leerlos el articulo. Pero antes de entrar de lleno en la configuración del runbook, veamos que necesitamos como requisitos:

• Creación de usuario [AzureAD] con el rol más ajustado a las necesidades de la cuenta, en nuestro caso, establecer el cambio de contraseña de los usuarios
• Una cuenta de automatización de AzureAD

Pues bien, lo primero será que tengamos una cuenta de usuario de AzureAD con el rol de Administrador de contraseñas [Puede restablecer la contraseña de usuarios no administradores y de administradores de contraseñas], evitando así problemas de seguridad mayores si alguien consigue el acceso a dicha cuenta [veremos como protegerla]. Una vez que la tengamos creada, lo primero que haremos será especificar que a ese usuario [similar a una cuenta de servicio en On-Premises] no le caduque la contraseña. Para esto, una vez creada la cuenta, la configuraremos para que no le caduque su contraseña. Una vez conectados con una cuenta de Global Admin a O365 [Connect-MsolService] ejecutaremos el siguiente cmdlet: Set-Msoluser -UserPrincipalName <nombre-usuario> -PasswordNeverExpired $True

De esta forma, evitaremos que la contraseña de la cuenta de ejecución del script caduque y no nos funcione pasados los días. Antes de configurar el script de forma automática, creo que es conveniente que lo ejecutemos línea a línea y veamos si funciona correctamente utilizando las credenciales de usuario de servicio que hemos creado anteriormente.

Os muestro como ya estando con la cuenta de servicio [UsrTaskPwd], busco el grupo “Acl Az Change Password 30” y me devuelve su ID. Luego, buscamos los usuarios que son miembros de dicho grupo y vemos que, tenemos a los usuarios:

• TestPwd01@asirsl.com
• TestPwd02@asirsl.com

Ahora os voy a mostrar la ejecución de los siguientes comandos:

• foreach ($user in $Usuarios) {Set-MsolUser -UserPrincipalName $user.EmailAddress -PasswordNeverExpires $True} [Opcional: este lo he añadido ahora, es para definir que a los usuarios del grupo que hemos buscado no le caduque la contraseña, sino se le pedirá el cambio de contraseña con la política de AzureAD ]
• foreach ($user in $Usuarios) {Set-MsolUserPassword -UserPrincipalName $user.EmailAddress -ForceChangePasswordOnly $true -ForceChangePassword $true} [forzar el cambio de contraseña de los usuarios]

Como podéis apreciar, nos da un error de Acceso Denegado para la ejecución de Set-MsolUser. Esto os ocurrirá el usuario de servicio no es miembro de los roles adecuados, en la siguiente captura de pantalla os muestro el usuario con el que estoy ejecutando el script y sus roles [vacío] por lo que es imposible que con esta cuenta podamos ejecutar el script con éxito:

Os lo muestro por si os ocurre, pero lo suyo es que ya tuviéramos el rol de AzureAD asociado al usuario, por lo que vamos a ello. Buscamos al usuario que utilizaremos como cuenta de ejecución, vamos a la sección de Roles Asignados, pulsamos en Añadir asignaciones y buscamos el rol Administrador de Contraseñas, lo seleccionamos y pulsamos en Agregar:

Ahora ya tenemos al usuario en cuestión con el rol de Administrador de Contraseñas:

Cerramos la consola de PowerShell y volvemos a iniciar sesión en O365 [Connect-MsolService] y volvemos a lanzar el mismos script que antes y vemos que ahora solo tenemos un error en la configuración opcional que os había puesto:

foreach ($user in $Usuarios) {Set-MsolUser -UserPrincipalName $user.EmailAddress -PasswordNeverExpires $True}

La pongo como opcional en el script, pero los usuarios que queramos que se les pida un cambio de contraseña automatizado por nosotros, deberíamos forzar que no les expire la contraseña, sino como os comentaba, les expirará la contraseña con la configuración de AzureAD general que tengamos. Yo prefiero poner esta configuración en el script, así no tenemos que hacerlo en cada usuario que creemos, pero bueno, allá cada uno.

Viendo el error anterior, claramente con el rol Administrador de Contraseñas no es suficiente, tenemos que agregarle una nuevo rol, el de Administrador de Usuarios:

Aquí  os dejo la información sobre ambos roles y sus diferencias: Administrador de contraseñas

Rol de Administrador de usuarios, claramente con este es con el que podemos cumplir todos los objetivos del proceso:

Como hemos comentado, ahora añadimos el rol Administrador de Usuarios y podemos quitar el de Administrador de Contraseñas:

Pues bien, ahora volvemos a ejecutar el script y  .. listo, funcionando sin problemas:

Ahora nos queda comprobar que los usuarios miembros del grupo Acl Az Change Password 30D ya se les solicita el cambio de contraseña, recordad que tiene un retraso de 10 min, que no es algo inmediato el que les solicite cambiar su contraseña. Pero bueno, ahora para probarlo simplemente iniciamos sesión con alguna de la cuentas de usuarios del grupo Acl Az Change Password 30D y vemos que ocurre:

Escribimos la contraseña actual del usuario

Una vez que hemos iniciado sesión, como vemos nos solicita cambiar la contraseña del usuario:

Debemos completar el proceso para continuar con el acceso a los servicios de O365:

Pues listo, con esto ya nos hemos dado cuenta de que el proceso funciona bien y la cuenta de servicio tiene los privilegios necesarios para ejecutar el script con éxito. Ahora lo siguiente que haremos será crea un llavero con las credenciales que vamos a utilizar en el runbook, para ello desde la cuenta de automatización que tengamos en Azure, vamos a la sección Credenciales y pulsamos en Agregar una credencial y cubrimos todos los campos con los datos de la cuenta:

Ahora ya tenemos nuestra credencial lista [UsrTaskPwd@asirsl.com], la cual llamaremos desde el Script para conectarnos a O365:

$credential = Get-AutomationPSCredential -Name “UsrTaskPwd@asirsl.com”
Connect-MsolService -Credential $Credential

Ahora toca crear nuestro runbook, nos vamos a la sección Runbooks de nuestra cuenta de automatización, pulsamos en Crear un runbook, escribimos un nombre descriptivo y elegimos PowerShell como tipo de Runbook:

Escribimos el código de nuestro script [nota: he cambiado la variable $Grupo por $Group, es que al principio del artículo lo tengo con Grupo]:

$credential = Get-AutomationPSCredential -Name “UsrTaskPwd@asirsl.com”
Connect-MsolService -Credential $Credential

$Group = Get-MsolGroup -SearchString “Nombre-Grupo-O365”
$Usuarios = Get-MsolGroupMember -GroupObjectId $Group.ObjectId
foreach ($user in $Usuarios) {Set-MsolUser -UserPrincipalName $user.EmailAddress -PasswordNeverExpires $True}
foreach ($user in $Usuarios) {Set-MsolUserPassword -UserPrincipalName $user.EmailAddress -ForceChangePasswordOnly $true -ForceChangePassword $true}

Si todo está correcto, pulsamos en Publicar y pulsamos en Si:

Por último, lo que nos queda es asociarle una programación para que se ejecute cuando queramos. Pues bien, dentro del runbook vamos a la sección Programas y pulsamos en Agregar una programación:

Pulsamos en Programa: Vincular una programación a su Runbook:

Si tenemos alguna planificación ya previamente configurada la podemos seleccionar, en caso contrario, pulsamos en Agregar una programación para crearla:

Aquí es donde vamos a definir la periodicidad de la ejecución del script, lo que haré que cada x días les solicite a los usuarios cambiar su contraseña. Me he despistado en la hora a la hora de capturar la pantalla, pero vamos, ajustarla vosotros. A lo mejor, lo suyo sería que se ejecutase los el último lunes de mes a las 07:00AM antes de que inicien sesión los usuarios.

Una vez creada, ya la tenemos seleccionada y pulsamos en Aceptar:

Listo, programación vinculada.

Ahora, desde el runbook podemos ver nuestro script antes de lanzar la primera prueba, para ello pulsamos en </>Ver y nos mostrará nuestro script:

Para probar el runbook pulsamos en Inicio y en Si, con esto hemos invocado la ejecución del script de forma manual e inmediata:

Esperamos unos segundos y vemos si el script se ha ejecutado bien o por el contrario tenemos algún problema con su ejecución. Este error que os muestro a continuación es algo hecho a propósito para que veáis un error típico que os pueda dar. Como podéis apreciar, no reconoce los comandos que estamos ejecutando en el script.

Esto es normal, puesto que, si la cuenta de automatización es nueva y no hemos importado los módulos de MSOnline. Si os da ese error, entonces tenéis que acceder a la sección de Módulos de la cuenta de automatización y pulsamos en Examinar la galería:

Buscamos por el texto Connect-Msol y elegimos el primero de la lista:

Una vez dentro del módulo podéis buscar los comandos que tiene disponibles y, ahí tenéis, los tenemos!! Pulsamos en Importar:

Pulsamos en Aceptar

Y módulo instalado

Ahora volvemos a iniciar el runbook de forma manual y ya tenemos nuestra ejecución limpia de errores:

Ya por último tendríamos que volver a iniciar sesión con alguno de los usuarios miembro del grupo Acl Az Reset Password 30 y vemos que le vuelve a pedir cambiar su contraseña!!

Pues ahí tenéis un pequeño proceso para tener grupos de usuarios cambiando sus contraseñas cuando nosotros queramos, sencillo y con un coste (Automation Task Azure) ridículo. Además, si utilizamos grupos de usuarios facilitamos la búsqueda de usuarios a los cuales queremos que cambien la contraseña cuando nosotros queramos.

El proceso es sencillo, ahora, como siempre, os toca probarlo a vosotros!!