Introducción
Primero, vamos a ubicar el contexto de nuestro escenario: estamos a punto del Go Live de una solución, nuestro entorno está securizado mediante un grupo de seguridad de Azure AD y queremos asegurarnos de que todos los usuarios tienen sus roles de seguridad asignados antes del gran día.
En otras palabras, cuando los usuarios accedan, queremos evitar este error:
Seguramente ya sepas que ese error desaparecería si el usuario refresca la página. Esto es porque con ese refresco, AAD se sincronizaría con Dataverse. Pero, ¿cuántos tickets / incidencias llegarían a tu equipo? Desde el punto de vista del usuario, este caso se percibiría como un error que podría provocar una avalancha justo cuando los usuarios han de empezar a usar la solución.
Para resolver esto, recomiendo usar el módulo de PowerShell Power Platform Administration PowerShell module. Sólo vas a necesitar estos commandlets:
#Conectarse al entorno mediante Service Principal
Add-PowerAppsAccount -Endpoint "prod" -TenantID $tenantId -ClientSecret $clientSecret -ApplicationId $applicationId
#Sincronizar un usuario desde AAD hasta Dataverse (Tabla systemuser)
Add-AdminPowerAppsSyncUser -EnvironmentName $environmentId -PrincipalObjectId $aadObjectIdEn el resto de este artículo, intentaré guiarte y explicarte por qué damos cada paso. Y, oye, ¡hazme saber en los comentarios qué te ha parecido (y si tienes una mejor forma de hacerlo)! 😁💪
¡Vamos a ello!
Vale, para recapitular, este es nuestro entorno en Power Platform (con Dataverse), cuyo acceso está controlado mediante un grupo de seguridad de Azure Active Directory:
Grosso modo, los pasos que daríamos para dar acceso a una aplicación son:
Añadir el usuario al grupo de AAD llamado "Awesome App Security Group".
Asignar un rol al usuario.
Compartir la aplicación con el usuario (seguramente, esto se haría automáticamente mediante un grupo de AAD).
Sobre el papel, todo perfecto: el usuario accederá a la app sin problemas mediante el link facilitado como parte de tu plan de comunicación y adopción.
Así que ahora, a una semana del Go Live, te dispones a asignar los roles a todos los usuarios siguiendo el Excel facilitado por negocio; accedes al entorno y te das cuenta de que los usuarios no están.
¿No están? Ah, tu compañero se habrá olvidado de añadirlos al grupo de AAD que funciona como "primer filtro" en el entorno...
Ups... sí que están. Entonces, ¿qué está pasando? Vamos a verlo paso a paso:
Cómo solucionarlo
Todavía estamos casi a una semana del Go Live, así que empiezas a buscar soluciones. Y ¿cuál es el problema de fondo? Para asignar roles a un usuario, es necesario que esté en la tabla systemuser. Hemos visto que esto se sincroniza "automáticamente" con AAD, pero sólo después de que el usuario refresque la página.
Entonces, ¿cómo forzamos ese comportamiento?
Aquí es donde entra la librería de PowerShell Power Apps Admin module:
Si no quieres saber nada de PowerShell, puedes conseguir lo mismo mediante Power Automate, siguiendo este post de la Comunidad: PowerApps force sync users from Azure AD to Data V... - Power Platform Community (microsoft.com)
Ahora, veamos cómo suelo enfocar este escenario:
1. Consigue que negocio te dé la lista de usuarios
Por lo general, sin la colaboración e implicación con negocio, es muy complicado que la solución sea un éxito. En este caso, necesitarás su ayuda para conseguir los usuarios que deben usar la app.
Típicamente (cómo no), hablamos de conseguir un Excel. Debes conseguir que te faciliten las direcciones de mail de los usuarios:
2. Obtiene los ids de AAD
El commandlet de PowerShell que vamos a usar necesita el "id interno" de los usuarios en Azure Active Directory. Como siempre, hablamos de un GUID único para tu tenant. Por mi experiencia con la librería PnP.PowerShell, normalmente haré lo siguiente:
#Conectarse a un Sitio de SharePoint que tengas acceso mediante login interactivo:
Connect-PnPOnline -Url "<SPO site>" -Interactive
#Ahora vamos a ir recorriendo el Excel fila a fila
#Para leer el Excel, puedes usar la librería Import-Excel o las capacidades de CSV nativas de PowerShell
$users = Get-Content -Path "<path to the CSV file>" | ConvertFrom-CSV -Delimiter ";"
$outputUsers = [System.Collections.ArrayList]::new()
foreach ($user in $users) {
$aadUser = Get-PnPAzureAADUser -Identity $user."Email"
$outputUsers.Add( [PSCustomObject]@{
"Name" = $user."Name";
"Email" = $user."Email";
"Country" = $user."Country";
"Role" = $user."Role";
"AADObjectId" = $aadUser.Id
})
}
#Exportamos y guardamos en un nuevo fichero
$outputUsers | ConvertTo-Csv -Delimiter ";" > "<path and for your output file>.csv"Con esas pocas líneas, deberíamos haber conseguido lo siguiente:
3. Sincronizar AAD y Dataverse
Ahora ya sí estamos listos para forzar la sincronización y el comando estrella va a ser el siguiente:
Add-AdminPowerAppsSyncUser -EnvironmentName $environmentId -PrincipalObjectId $aadObjectIdAsí, podríamos tener un pequeño script que, a partir del último CSV generado, se encargue de las operaciones de sincronización:
#Conectarse al entorno mediante Service Principal
Add-PowerAppsAccount -Endpoint "prod" -TenantID $tenantId -ClientSecret $clientSecret -ApplicationId $applicationId
$usersToSync = Get-Content -Path "<path to the CSV file>" | ConvertFrom-CSV -Delimiter ";"
foreach ($user in $usersToSync ) {
Add-AdminPowerAppsSyncUser -EnvironmentName $environmentId PrincipalObjectId $user."AADObjectId"
}
Resumiendo
Hemos visto cómo funciona la sincronización entre AAD y Dataverse, y cómo forzarla sin requerir que hagan login los usuarios. Así es como podremos asignar roles de antemano.
Para hacer esto, yo prefiero PowerShell porque es una increíble navaja suiza para automatizar cualquier cosa. Lo uso mucho desarrollando soluciones, desplegando, con el ALM y administrando entornos.
Bueno, espero que este artículo te haya servido. Si es así, agradeceré tu feedback en los comentarios y si estás interesad@ en que escriba sobre algo concreto, ¡házmelo saber!
Nos vemos,
Andrés