Synchroniser les groupes de sécurité avec les groupes Microsoft 365 (détaillé)

Dans cet article nous allons détailler le fonctionnement de l’application pour synchroniser les groupes de sécurité et les groupes Microsoft 365. Nous décrirons également le déroulement du déploiement. 

Nous allons découper l’application en 2 parties :

• Les scripts Azure functionL’interface SPFX

• Puis nous terminerons sur le déploiement de l’application.

L’ensemble de la solution pour synchroniser les groupes de sécurité et les groupes Microsoft 365 est disponible sur ce repository Github, n’hésitez pas à l’installer, la modifier pour l’adapter à votre organisation et à faire des retours.

L’ Azure Function App

L’Azure Function App est une ressource disponible dans le portail Azure. Cette App va contenir des scripts qui pourront être déclenchés par appel HTTP, timer… A ce jour il est possible d’y écrire du C#, du JavaScript ou encore du Powershell, le langage que nous allons utiliser. Les mises à jour sont constantes sur Azure Function, certains modules peuvent être dépréciés. Dans nos scripts, nous allons utiliser les modules les plus récents pour réaliser nos actions.

Les modules

Pour nos scripts nous allons utiliser 3 modules :

1. Az.Accounts, pour effectuer les opérations dans les groupes Microsoft 365
2. Az.Resources, pour récupérer les membres des groupes de sécurités
3. PnP.PowerShell, pour effectuer les actions dans SharePoint

Pour utiliser des modules dans les fonctions Azure, il existe 2 méthodes :

La première est de télécharger les modules dans le répertoire virtuel de l’Azure function App. Pour cela il faut se rendre dans la section « Outils de développement -> Outils avancés ». Cela vous redirigera vers Kudu, une plateforme où il est possible d’effectuer des opérations sur l’environnement virtuel de votre Azure function App. En allant dans la « Debug console », on fait apparaître les répertoires virtuels et on peut y déposer des modules PowerShell. Pour ajouter les modules, il faut se rendre dans « Site -> wwwroot » et créer un répertoire « Modules ». Puis vous pouvez déposer les modules dedans et les importer dans vos scripts. Si les modules sont mis à jour par leurs développeurs, il vous faudra les supprimer et les redéposer.

La deuxième méthode consiste à utiliser le fichier « requirements.psd1 » disponible dans la section « Fonctions -> Fichiers d’application ». Ce fichier permet d’inscrire des noms de modules et leur version qui seront automatiquement installés au premier lancement du script. A la création d’une Azure function application, le module Az est déjà inscrit. Il est possible d’inscrire une version précise dans le fichier, ou alors le premier chiffre suivit d’une * pour que le fichier récupère automatiquement la dernière version de l’itération. A chaque lancement d’un script, Une comparaison est effectuée entre la version du module installée et celle inscrite dans le fichier. Si elle est différente, une installation de la nouvelle version s’effectue.

Pour notre application, j’ai opté pour la deuxième méthode qui me semble plus propre et plus simple à maintenir à jour. Voici un aperçu du fichier « requirements » :

Les variables globales

Dans la section « Paramètres » puis dans « Configuration », il est possible d’ajouter des paramètres d’application. Dans nos 4 scripts, nous avons besoin d’informations qui sont communes à tous. Nous avons 4 paramètres :

• AdminSharePointSite, Url du site admin SharePoint. Il va être utilisé par le script quotidien pour obtenir la liste des sites SharePoint.
• AzureAppId, l’id de l’application Azure. Il va être utilisé pour s’authentifier sur les sites SharePoint et sur Azure.
• TenantId, l’id du tenant. Il va être utilisé pour s’authentifier sur les sites SharePoint et sur Azure.
• WEBSITE_LOAD_CERTIFICATES, thumbprint du certificat de l’azure application. Il va être utilisé pour s’authentifier sur les sites SharePoint et sur Azure. Cette variable autorise aussi les scripts de la fonction application d’utiliser un certificat. Je vous conseil de consulter la partie 2 de cet article qui explique comment ajouter un certificat à l’environnement virtuel d’une azure function app et comment s’en servir.

Pour appeler ces paramètres dans nos fonctions, il faut écrire « $env: » suivi du nom du paramètre.

Les 3 scripts HTTP

Les 3 scripts HTTP sont ceux qui vont être appelés par l’interface SharePoint. Ces scripts reçoivent 3 paramètres :

• securityGroupId
• microsoftGroupId
• siteUrl

Ajout d’un groupe de sécurité

Le script va permettre d’ajouter les membres d’un groupe de sécurité à un groupe Microsoft 365, voici son fonctionnement :

Tout d’abord on se connecte au site SharePoint du groupe Microsoft, et à Azure :

Ensuite on vient récupérer les membres actuels du groupe M365 avec la commande « Get-AzADGroupMember » du module Az.Resources. On les ajoute à un tableau que l’on convertira en Json pour le stocker dans un Property Bag du site SharePoint :

Puis via une fonction, on récupère les membres du groupe de sécurité que l’on ajoute au groupe Microsoft 365. On ajoute aussi ces membres dans un tableau que l’on sauvegardera dans un Property Bag. Il est possible que des groupes de sécurité soient inclus dans un groupe de sécurité. La fonction est construite de manière à être récursive, si elle détecte qu’un groupe fait partie du groupe de sécurité elle vient récupérer ses membres. Ainsi les membres du groupes inclus sont aussi ajoutés au groupe Microsoft :

Pour finir le script, on vient inscrire les informations du groupe de sécurité dans une Property Bag aussi. S’il n’y a pas eu d’erreur dans le traitement, on retourne le code 200 qui indique un statut OK à l’interface SharePoint. A noter que les Property Bag n’accepte que des strings, nous convertissons donc nos tableaux en JSON pour les stocker dans les Property Bag :

Suppression d’un groupe de sécurité

Le script de suppression va supprimer les membres du groupe de sécurité associer au groupe Microsoft 365. Pour cela, il va se baser sur les membres qui sont enregistrés dans le Property Bag du site SharePoint.

La première étape concerne la connexion comme pour le script précédent.

On récupère ensuite les membres de sécurité et membres du groupe Microsoft 365 enregistrés dans les Property Bag :

et on supprime les membres de la liste de sécurité du groupe Microsoft 365 s’ils ne faisaient pas partie du groupe de base :

Si tout s’est bien déroulé, on retourne le code 200 et le statut OK à l’interface SharePoint.

Synchronisation d’un groupe de sécurité associé à un groupe Microsoft 365

Ce script va permettre de mettre à jour les membres du groupe de sécurité inclut dans le groupe M365. Il est nécessaire d’avoir ce script car pour rappel, ce sont bien les membres et non le groupe qui sont associés au groupe M365. Toutes modifications dans le groupe de sécurité ne sont donc pas répliquées dans le groupe M365 nativement.

La première étape reste celle de la connexion. Ensuite, on vient récupérer les listes des membres de sécurité et du groupe M365 des Property Bag comme dans le script précèdent. Puis il faut requêter le groupe de sécurité comme dans le script d’ajout pour récupérer la liste des membres à jour.

Suite à ça, deux fonctions mettent à jour les membres.

La première est celle d’ajout des nouveaux membres. Dans cette fonction on va venir boucler sur la liste des membres du groupe de sécurité fraichement récupérée. On va regarder si le membre n’est pas déjà dans le Property Bag des membres de sécurité et dans le Property Bag des membres du groupe M365 de base. S’il n’est pas présent, cela signifie que le membre a été ajouté récemment dans le groupe de sécurité. On l’ajoute alors au groupe M365 et dans le Property Bag des membres du groupe de sécurité :

La deuxième fonction va servir à retirer les membres qui ne sont plus présent dans le groupe de sécurité. Dans cette fonction, on va boucler sur la liste des membres de sécurité du Property Bag. Si le membre n’est pas contenu dans la liste nouvellement récupérée du groupe de sécurité ni dans la liste du Property Bag du groupe M365 de base, il est retiré du groupe M365.

Le script Timer

Dans l’optique de maintenir cette association à jour, un script Timer est mis en place. Par défaut, son exécution est quotidienne. Le script se connecte au site admin SharePoint du tenant, et récupère la liste des sites SharePoint. Puis il effectue une connexion sur chaque site et vérifie si le Property Bag « syncGroupAppEnabled » est à « true ». Si c’est le cas, le script effectue les mêmes opérations que celui de synchronisation vu au dessus.

L’interface SPFX

L’interface SPFX a pour but d’appeler les scripts de l’azure function app. Elle est constituée de 2 designs :

• Interface pour ajouter un groupe de sécurité
• Interface pour synchroniser / retirer un groupe de sécurité

Interface d’ajout de groupe

Cette interface est très simple et affiche les informations suivantes :

• Le nom du groupe Microsoft 365
• La liste des groupes de sécurité qui peuvent être associés

La liste des groupes de sécurité qui peuvent être associés proviennent d’un Property Bag qui est initialisé au déploiement de l’application SPFX. Un fichier Excel est présent pour inscrire la liste des groupes de sécurité. Le bouton « Add » reste désactivé tant que l’utilisateur n’a pas sélectionné un groupe dans la liste.

Une fois sélectionné, l’utilisateur peut actionner le bouton et l’appel est effectué vers la fonction Azure. Un message d’attente s’affiche :

Ce message s’affiche pour toutes les actions qui appellent un script sur Azure.

Interface de synchronisation et de suppression 

Une fois le groupe associé, l’interface présente 2 option : Sync ou Remove.

On retrouve aussi l’information de la dernière synchronisation, les utilisateurs ajoutés ou supprimé lors de cette dernière.

Si l’utilisateur utilise l’option « Sync » et que des mouvements ont eu lieu dans le groupe de sécurité associé, les noms des personnes s’afficheront :

Si l’utilisateur sélectionne l’option « Remove », la première interface graphique reviendra. 

Le déploiement

Dans cette partie nous allons voir quelles sont les étapes du déploiement de l’application. Ce déploiement se fait en 2 parties :

• Un déploiement à faire une fois au niveau du tenant global.
• Un déploiement à faire pour chaque groupe qui utilisera l’application.

Le package de déploiement comprend les fichiers suivants :

• Un dossier certificates, il contient les certificats à déployer dans l’application Azure pour s’authentifier.
• Un ficher deployAzure.ps1, script qui permet de déployer l’Azure Application et la fonction application Azure.
• Un fichier manifest.json, fichier qui contient les permissions à ajouter sur l’Azure application.
• Un dossier zip PowerShellGroupOperation.zip, dossier qui contient les fonctions Azure à déployer dans la fonction application Azure.
• Un fichier deploySPFX.ps1, script qui permet de déployer l’application SPFX et de créer les Property Bag dans le site SharePoint.
• Un fichier securityGroups.xlsx, il contient les groupes de sécurités qui seront utilisés dans l’application et ajouter dans le Property Bag.

Le déploiement au niveau du tenant

Avant de lancer le script il faut avoir Azure CLI installé. Les commandes apportées par ce module servent à créer l’application Azure AD et la fonction application. Pour installer Azure CLI, je vous recommande la documentation Microsoft : Install Azure CLI.

Pour les autres modules utilisés dans le script, une vérification est effectuée au lancement avec l’installation si nécessaire.

Nous allons d’abord dérouler le script qui est à lancer une seule fois au niveau du tenant global. Ce script va réaliser 2 actions majeures :

• Création de l’application Azure avec un certificat associé.
• Création de la fonction application Azure avec les paramètres d’application et le certificat uploadé.

Pour réaliser ces actions, le script a besoin de 8 paramètres :

• $TenantName, utilisé pour récupérer l’url du site admin SharePoint.
• $FullTenantName, utilisé pour créer l’Azure application.
• $TenantId, stocké dans un paramètre de la fonction Azure application.
• $AzureAppName, nom de l’Azure application.
• $FunctionAppName, nom de la fonction Azure application.
• $SubscriptionId, utilisé pour créer la fonction Azure application.
• $StorageAccount, utilisé pour créer la fonction Azure application.
• $ResourceGroupName, utilisé pour créer la fonction Azure application.
• $Location, utilisé pour créer la fonction Azure application.
• $CertificatePassword, mot de passe du certificat.

Au lancement du script 3 connexions avec des comptes admin sont demandées :

• Une pour se connecter à Azure AD.
• Une pour se connecter à Azure CLI.
• Une pour se connecter à SharePoint.

Création de l’Azure application

Une fois connecté, la création de l’Azure application se lance. On vérifie si l’application existe déjà. Si oui, on lui ajoute les droits qui sont nécessaire pour l’application. Si non, le processus de création se lance.

Pour créer l’Azure application et son certificat auto signé, nous utilisons une commande qui a été conçue par les développeurs de PnP. Cette commande est la suivante :

Initialize-PnPPowerShellAuthentication

Cette commande est disponible dans le module « SharePointPnPPowerShellOnline ». Je place ici un petit warning car ce module est en train d’être déprécié. Les développeurs PnP ont sorti récemment le module PnP.PowerShell que nous utilisons d’ailleurs dans nos fonction Azure. Cependant ils ont enlevé cette commande qui est je trouve assez utile pour générer facilement un certificat auto signé. C’est pourquoi j’utilise l’ancien module pour effectuer le déploiement. Si vous avez le module PnP.PowerShell installé, il faut le désinstaller afin de pouvoir installer SharePointPnPPowerShellOnline.

La commande va d’abord générer le certificat, puis lancer la création de l’Azure application. Ensuite, elle enregistre le certificat dans l’application et une fenêtre va s’ouvrir avec une demande de connexion avec un compte Admin. Une fois connecté, l’admin doit approuver les permissions qui sont instanciées de base par la commande.

Suite à cette commande, des permissions spécifiques sont ajoutées à l’Azure application. Encore une fois une connexion Admin est demandée. Les permissions ajoutées sont disponible au format JSON dans le fichier « Manifest.json ». Pour pouvoir ajouter des permissions à l’application depuis ce fichier, nous passons par une commande Azure CLI.

Après ces étapes, l’Azure application est créée.

Création de la fonction Azure application

Pour créer la fonction Azure application, nous passons aussi par une commande Azure CLI :

az functionapp create

Elle prend en paramètre le type de langage et sa version.

Une fois créée, on ajoute les paramètres qui nous seront utiles dans nos scripts :

Ensuite on vient uploader le certificat dans la fonction Azure application avec la commande :

Ajouter les scripts

A ce stade la fonction Azure application est créée et elle contient le certificat ainsi que les paramètres utiles aux scripts. Ils ne restent qu’à ajouter ces fameux scripts dans le portail Azure. Une commande Azure CLI permet de pousser un dossier zip d’une azure function application dans une autre :

Cette opération peut prendre un peu de temps.

Pour finir on ajoute l’application SPFX dans le catalogue d’application de SharePoint :

Et voilà ! Notre déploiement au niveau global est terminé.

Le déploiement par groupe Microsoft 365

Le script de déploiement par groupe va permettre de créer les Property Bag dans le site SharePoint et d’ajouter la Web Part SPFX. Dans ce script pour éviter d’avoir des problèmes de droits par rapport à des groupes privés nous allons utiliser l’application Azure et son certificat créé pour s’authentifier. Pour cela il faut d’abord installer le certificat sur son environnement local. Il faut installer le fichier .pfx qui est disponible dans le dossier de déploiement. Il vous sera demander de renseigner le mot de passe que vous avez choisi pour le certificat durant le déploiement de l’Azure application.

Une fois installé, vous pouvez lancer le script. Voici les paramètres dont il a besoin :

• $SiteUrl, le site SharePoint du groupe sur lequel on veut installer l’application.
• $TenantName, le nom du tenant.
• $FunctionAppName, nom de la fonction application Azure qui sera stocké dans un Property Bag.
• $AzureAppId, ID de l’Azure application utilisé pour s’authentifier.
• $TenantId, ID du tenant utilisé pour s’authentifier.
• $Thumbprint, Empreinte du certificat utilisée pour s’authentifier.

La première partie du script va créer les Property Bag :

Vous pouvez voir que les groupes de sécurité sont récupérés depuis un fichier Excel. Ce fichier est à modifier selon vos besoin et vos groupes de sécurité.

Suite à ça, l’application SPFX est installée sur le site du groupe :

Dans notre cas d’étude, le tenant supporte le CDN Office 365 pour hoster les composants d’une application SPFX. Ici, l’application a été packagée et le chemin indiqué dans la commande est celui par défaut. Pour en apprendre plus sur la mise en production d’une solution SPFX, je vous conseil cet article qui explique comment déployer la solution.

Il ne vous reste plus qu’à placer la Web Part dans le site et c’est parti !

Pour conclure

L’application de synchronisation de groupes de sécurité permet de placer des membres d’une équipe de sécurité dans un groupe Microsoft 365. Cet article avait pour but de présenter l’application et son fonctionnement, ainsi qu’apporter des conseils sur l’utilisation de certaines technologies.

Pour apprendre encore plus de l’application, je vous recommande fortement de l’installer et de commencer à l’utiliser. Dans toutes les parties de la solution, des commentaires sont présents pour faciliter la compréhension.

Si vous voulez continuer dans la voie de l’utilisation d’application pour faciliter l’administration de votre tenant Microsoft 365, je vous conseille de nous contacter pour vous présenter les différentes solutions alternatives.

Laurent Heroguelle

---

Administration Microsoft Capitaine Obvie Green IT Microsoft Viva MS Teams OneDrive Outlook Power Apps Power BI Power Platform SharePoint Solution Obvie Stream Transformation Numérique