Maintenir des liens précis avec le gestionnaire de compte utilisateur Entra ID

Liens utilisateur-gestionnaire précis nécessaires à de nombreuses fonctionnalités de Microsoft 365

Dans le passé, j'ai écrit sur l'importance de standardiser le processus de création de compte utilisateur afin que les propriétés du compte finissent par être entièrement renseignées avec des propriétés telles que le service, le responsable, etc. Bien qu'il soit relativement facile de s'assurer que les propriétés du compte sont exactes lors de leur création, au fil du temps, il est presque inévitable que des inexactitudes s'installent à moins que des mesures ne soient prises pour valider et corriger les erreurs dans les liens du gestionnaire de compte utilisateur Entra ID. PowerShell est très utile à cet égard, car les scripts permettant d'identifier les problèmes de données de compte sont faciles à écrire.

Les relations manager-employé sont probablement les mises à jour les plus difficiles à gérer. Souvent, les changements dans les lignes hiérarchiques se produisent sans aucune connaissance du service informatique. Il s'agit de questions RH, et à moins que les RH n'informent le service informatique de la nécessité de mettre à jour Entra ID, l'annuaire reste intact et descend progressivement dans un état inexact.

La raison pour laquelle la précision des annuaires est importante est que Microsoft 365 met en évidence les organigrammes à plusieurs endroits tels que Teams (Figure 1), la carte de profil utilisateur Microsoft 365 et l'explorateur d'organisation dans Outlook pour Windows (nécessite une licence Viva Suite).

Évidemment, si Entra ID contient des informations inexactes sur les relations hiérarchiques, les graphiques générés par les applications seront trompeurs. C’est un problème qui devrait être résolu.

Les grandes organisations ont tendance à disposer de systèmes RH sophistiqués qui peuvent inclure un flux vers Entra ID pour gérer les changements tels que les relations hiérarchiques, les départements, les numéros de téléphone, les emplacements physiques, etc. Mais imaginons que notre organisation ne possède pas un tel flux. Au lieu de cela, nous devons trouver un moyen de reproduire ce qui pourrait se produire si un flux RH était disponible.

Définir une solution possible

En esquissant le type de solution que nous pourrions développer, j'ai proposé ce qui suit :

Les RH fournissent des mises à jour régulières sur les informations sur les managers et leurs départements, y compris le manager de niveau 2 pour chaque département. Pour cet exercice, nous utiliserons un fichier CSV appelé c:\temp\ManagerData.csv pour contenir ces données.
Un script PowerShell lit les informations RH et vérifie chaque compte utilisateur pour mettre à jour le responsable en fonction du service attribué au compte. Si l'utilisateur est le chef de service, le script met à jour le compte auprès du responsable de niveau 2. Étant donné qu’il est nécessaire de s’éloigner des anciens modules Azure AD et MSOL, nous utiliserons les applets de commande du SDK Microsoft Graph PowerShell.

Simple. Le script peut s'exécuter de manière interactive, mais dans un environnement de production, il sera plus susceptible de l'exécuter de manière planifiée à l'aide d'un élément tel qu'un runbook Azure Automation.

Une solution commerciale de maintenance d'annuaire telle que LiveTiles Directory (anciennement connue sous le nom d'Hyperfish) fera le travail de manière plus élégante et plus complète, mais il est plus amusant de coder une solution maison. Vous pouvez télécharger le script que j'ai écrit depuis GitHub. Comme toujours, les scripts que nous écrivons visent à illustrer des principes plutôt qu'à constituer des solutions entièrement fonctionnelles. Veuillez utiliser le script comme vous le souhaitez.

Scripter la solution

L'exemple de script passe par plusieurs phases pour rechercher les comptes d'utilisateurs, déterminer le bon responsable de service à attribuer et éventuellement mettre à jour les comptes. Voici un aperçu de ce qui se passe.

Tout d’abord, le script lit les informations sur les chefs de service des RH. Étant donné que les données se trouvent dans un fichier CSV, l'applet de commande Import-CSV suffit. Cependant, le script peut devoir traiter des milliers d'employés, un accès rapide aux données est donc nécessaire. Pour cette raison, le script charge le nom du service et le responsable (nom de l'utilisateur principal) dans une table de hachage. Si le script détecte des erreurs dans les données de gestion, il signale une erreur et s'arrête.

Ensuite, le script recherche l'ensemble des comptes d'utilisateurs à traiter. Les comptes d'utilisateurs ne sont pas toujours associés à de vraies personnes susceptibles d'avoir un responsable. Par conséquent, pour exclure les comptes utilisés pour des éléments tels que les salles de réunion, les boîtes aux lettres partagées et les comptes d'invités, le script utilise une méthode avancée. Requête graphique sur Entra ID avec l'applet de commande Get-MgUser pour rechercher les comptes avec au moins une licence attribuée. Filtrer la sortie de Get-MgUser comme ceci est une commande très utile que vous finirez probablement par utiliser dans de nombreux scripts :

Write-Host "Finding licensed user accounts..."
[array]$Users = Get-MgUser -All -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable UsersFound | Sort-Object DisplayName
If (!($Users)) { Write-Host "Couldn't find any user accounts with assigned licenses!" ; break }

Après avoir récupéré l'ensemble des comptes d'utilisateurs, le script divise les comptes entre ceux avec une propriété de département remplie et ceux qui n'en ont pas. Évidemment, le script ne peut traiter que les comptes des départements car il utilise cette propriété pour trouver le responsable. En même temps, se rendant compte que la vie est imparfaite, le script lit un gestionnaire par défaut à utiliser lorsqu'il ne peut pas correspondre à un service :

[array]$UsersNoDepartment = $Users | Where-Object {$Null -eq $_.department}
[array]$UsersWithDepartment = $Users | Where-Object {$Null -ne $_.department}
# Get default manager to assign people to when we can't find a department manager
$DefaultManager = $ManagerData | Where-Object {$_.Department -eq "Default" } | Select-Object -ExpandProperty Manager

La partie suivante du script se concentre sur la détermination du gestionnaire à attribuer à un compte utilisateur. Si la recherche dans la table de hachage utilisant la valeur du département pour le compte utilisateur réussit, nous savons quel responsable attribuer. Certains traitements conditionnels traitent la situation dans laquelle un utilisateur est le chef de service. Ce code existe parce que Microsoft 365 permet à un utilisateur d’être son propre manager, ce qui n’arrive pas trop souvent dans la vraie vie. Un autre chèque existe pour le compte PDG, qui n’a pas de manager car il est au sommet de l’organisation.

Après avoir déterminé le manager à attribuer à un compte utilisateur, le script vérifie si le manager est déjà présent pour le compte. Pour ce faire, le script exécute l'applet de commande Get-MgUserManager et compare la valeur du nom d'utilisateur principal du responsable avec le nom d'utilisateur principal du responsable de service actuel. Si les deux correspondent, le script ne tentera pas de mettre à jour le compte.

$UserManager = (Get-MgUserManager -UserId $User.Id -ErrorAction SilentlyContinue).additionalProperties.userPrincipalName
 If ($DepartmentManager -eq $UserManager) {
    # Same manager, so don't update
    $DepartmentManager = $Null 
}

La dernière étape est celle où le script appelle l'applet de commande Set-MgUserManagerByRef pour mettre à jour le compte. L'applet de commande fonctionne par référence, ce qui signifie que l'entrée fait référence à un autre objet (le chef de service). L'applet de commande accepte l'objet cible identifié par son identifiant d'objet ou son nom d'utilisateur principal (tel qu'utilisé dans cet exemple). Voici ce que fait le code :

Write-Host ("Updating user account {0} with manager {1}" -f $User.displayName, $DepartmentManager)
$ManagerId = ("https://graph.microsoft.com/v1.0/users/{0}" -f $DepartmentManager) 
$NewManager = @{"@odata.id"=$ManagerId}
Set-MgUserManagerByRef -UserId $User.Id -BodyParameter $NewManager

En sortie, le script génère un rapport sur les mises à jour de gestion qu'il traite. Le script exporte la sortie sous forme de fichier CSV et affiche les détails via l'applet de commande Out-GridView (Figure 2).

Le script indique également s’il trouve des comptes qui n’ont pas de propriété de département.

Un peu plus complexe que prévu

Quand j’ai commencé à écrire l’exemple de script, je pensais que le code finirait par faire environ 40 lignes. Le script final représente environ le double (sans aucune gestion des erreurs), ce qui prouve encore une fois mon incompétence lors de l'estimation des tâches. Savoir gérer les missions de gestion avec PowerShell est une bonne chose. Indépendamment de toute autre chose, cet exercice démontre l'utilisation des applets de commande Get-MgUserManager et Set-MgUserManagerByRef dont vous pourriez avoir besoin pour mettre à niveau les scripts qui utilisent le futur modules AzureAD et MSOL obsolètes.

Planification et consolidation de la migration de la plateforme Microsoft