Garder les équipes en ordre grâce à l'automatisation

Le problème de l’étalement des groupes

Les groupes Microsoft 365 existent depuis longtemps maintenant, et bien qu'il existe sans aucun doute de bonnes utilisations, comme une alternative aux boîtes aux lettres partagées et un remplacement potentiel des redoutables dossiers publics, ils ont vraiment trouvé leur rythme avec Microsoft Teams. Chaque équipe est soutenue par un groupe Microsoft 365, et chaque groupe contient une variété de composants provenant de différentes zones de la plateforme, constituant un objet unique (en quelque sorte) avec plusieurs cas d'utilisation.

Le problème de l’étalement des groupes n’est pas propre à Teams, mais l’adoption rapide et la création facile de Teams pour les utilisateurs finaux par défaut n’ont certainement pas aidé les administrateurs de locataires très occupés à garder p leur environnement bien rangé. Fournir une formation aux utilisateurs finaux sur la façon de gérer Teams de manière responsable peut aider, mais comme la plupart des éléments de Microsoft 365, cela peut être une cible quelque peu mouvante.

Il existe différents contrôles disponibles pour les administrateurs qui facilitent un peu la gestion des groupes/équipes, mais il n'existe pas de solution unifiée de bout en bout disponible de manière native. Cela étant dit, avec un peu d'ingéniosité et une certaine automatisation, il existe des moyens de contrôler la création d'équipes sans trop de frais généraux.

Remarque : Les exemples de code décrits dans cet article sont tous disponibles sur GitHub pour vous aider à démarrer avec votre propre solution.

Domaines clés à contrôler

Certains domaines clés de Teams sont utiles à contrôler à un niveau plus granulaire pour que tout reste en ordre dans votre locataire. Lors de la planification de vos scripts d'automatisation Teams, les domaines suivants sont importants à prendre en compte car ils peuvent réellement aider à définir les règles pour différents types d'équipes.

Nom de groupe : les stratégies de dénomination de groupe dans le centre d'administration Microsoft Entra autorisent certaines fonctionnalités de convention de dénomination de base pour les groupes Microsoft 365 (et les équipes), mais en réalité, elles manquent cruellement de flexibilité. Baser les noms de groupe sur des attributs d'utilisateur statiques est une bonne idée en théorie, mais passe à côté de plusieurs cas d'utilisation clés, tels que les équipes interdépartementales ou la différenciation entre les équipes disponibles en interne et en externe. Un autre aspect de la dénomination qui peut être utile dans les grandes organisations consiste à contrôler l’URL du site SharePoint utilisé. Par défaut, Microsoft 365 utilise le pseudonyme de messagerie de groupe pour concevoir l'URL du site associé. En fonction de la structure SharePoint au sein d'un locataire, cela peut ne pas être suffisamment granulaire.

Expiration de groupe : l'expiration de groupe est un moyen utile de supprimer les anciens groupes de votre locataire. La stratégie de cycle de vie du groupe Azure AD est un moyen simple de configurer cela, mais il n'existe qu'une seule stratégie disponible et, à moins que vous n'y incluiez tous les groupes, elle doit être mise à jour pour chaque groupe que vous souhaitez inclure ou exclure.

Contrôles d'accès et de partage : avec différents types de groupes ou d'équipes au sein d'une organisation, différents niveaux d'accès et de partage doivent être pris en compte. Par exemple, une équipe de projet orientée client doit avoir une configuration d'accès externe très différente de celle d'une équipe départementale RH. La configuration des différents types de groupes est facilement configurée à l'aide d'étiquettes de sensibilité, comme expliqué dans cette série en trois parties sur l'utilisation des étiquettes de sensibilité avec les sites SharePoint, Microsoft Teams et les groupes M365. Malheureusement, l'attribution d'étiquettes de sensibilité par programme nécessite l'utilisation d'autorisations déléguées avec l'API Graph, ce qui est difficile à réaliser lors d'une exécution non interactive. Pour les besoins de cet exemple, je configure les paramètres du groupe et du site directement plutôt que d'utiliser des étiquettes.

Propriété : les groupes orphelins (groupes qui n'ont plus de propriétaires) sont une réalité dans Microsoft 365. Il existe certaines méthodes pour gérer cela via des stratégies ou des scripts qui sont abordés dans cet article sur les stratégies de gouvernance de la propriété des groupes. . Par défaut, les groupes nécessitent au moins un propriétaire au moment de la création, mais c'est une bonne idée d'en avoir au moins deux.

Gestion des droits : pour les groupes sensibles, la configuration initiale ne représente que la moitié de la bataille. Il est important de garantir que l’accès accordé à des groupes ou sites spécifiques est continuellement examiné et confirmé. Il s’agit d’un problème plus large auquel de nombreux administrateurs sont confrontés et qui n’est pas propre à Microsoft 365. La gestion du cycle de vie de l’accès aux ressources est essentielle pour assurer la sécurité de votre environnement. Un bon moyen de garder le contrôle de cela consiste à utiliser la gestion des droits, comme indiqué dans cette série : Un guide pour la gestion des droits.

Par où commencer ?

Les domaines que j’ai mentionnés ne sont que quelques-unes des différentes solutions et paramètres disponibles dans Microsoft 365 qui, à eux seuls, représentent une partie d’une solution. Rassembler chaque pièce et l’automatiser est là où nous ajoutons vraiment de la valeur (et gagnons du temps).

En se lançant directement dans la création d’une solution, Azure Automation est facilement un bon choix pour automatiser quelque chose comme celui-ci car il fonctionne de manière fiable et sécurisée. Il existe également une multitude de bons exemples en ligne montrant comment Azure Automation est utilisé avec Microsoft 365 et le SDK Microsoft Graph.

Il existe cependant certaines limitations lors de l'utilisation de l'API Graph, en particulier pour la configuration de SharePoint Online. Microsoft a récemment ajouté une prise en charge (très) limitée de Microsoft Graph pour les paramètres de locataire SharePoint Online dans le point de terminaison Graph bêta, mais cela ne permet pas encore la granularité nécessaire pour configurer chaque site. Pour contourner ce problème, le module PNP PowerShell comble les lacunes.

Préparer l'environnement

Il existe de nombreux didacticiels permettant de créer une application enregistrée dans Azure AD et de générer les paramètres d'authentification et de consentement requis,, je ne m'attarderai donc pas trop sur cette configuration ici. En bref, nous fournissons un nouveau compte Automation avec une identité managée attribuée par le système, similaire à cet article sur l'utilisation des identités managées avec le SDK Microsoft Graph. Une fois le compte Automation créé, les autorisations d'application suivantes sont requises pour l'identité managée :

GroupMember.ReadWrite.All (Pour gérer l'appartenance à un groupe)
Group.Create (Pour créer des groupes)
User.ReadWrite.All (Pour gérer l'appartenance à un groupe)
Group.ReadWrite.All (Pour gérer les groupes)
Directory.ReadWrite.All (pour gérer les paramètres d'annuaire et les politiques de cycle de vie)
Sites.FullControl.All (Pour gérer les paramètres du site)

Remarque : Il existe un certain chevauchement dans les autorisations ci-dessus, en particulier avec « Directory.ReadWrite.All », mais j'ai inclus l'autorisation minimale pour chaque tâche afin qu'elles puissent être facilement modifiées pour votre script. Les autorisations Directory.ReadWrite.All sont un niveau d'autorisation hautement privilégié qui est actuellement requis pour ajouter des groupes à une stratégie de cycle de vie de groupe. Ce n’est pas idéal, mais jusqu’à ce qu’un niveau d’autorisation plus granulaire soit disponible, c’est le seul moyen d’y parvenir via Microsoft Graph.

Nous avons également besoin des autorisations « Office 365 SharePoint Online » suivantes :

Sites.FullControl.All (pour autoriser l'accès PNP)

Le script suivant attribue les autorisations répertoriées ci-dessus à un principal de service à l'aide du module Microsoft.Graph PowerShell :

##List Required Permissions
$Permissions = @(
    "“GroupMember.ReadWrite.All"”
    "“User.ReadWrite.All"”
    "“Group.ReadWrite.All"”
    "“Directory.ReadWrite.All"”
    "“Sites.FullControl.All"”
    "“Group.Create"”
)
##Add Managed Identity ID
$MIID = "“<Replace with Managed Identity Service Principal ID>"”
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "“AppId eq '‘00000003-0000-0000-c000-000000000000'’"” # Microsoft Graph
[array]$Roles = $GraphApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
    $AppRoleAssignment = @{
        "“PrincipalId"” = $MIID
        "“ResourceId"” = $GraphApp.Id
        "“AppRoleId"” = $Role.Id
    }
    # Assign the Graph permission
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}
##List Required Permissions
$Permissions = @(
    "“Sites.FullControl.All"”
)
##Get Roles for Permissions
$GraphApp = Get-MgServicePrincipal -Filter "“AppId eq '‘00000003-0000-0ff1-ce00-000000000000'’"” # SharePoint Online
[array]$Roles = $GraphApp.AppRoles | Where-Object {$Permissions -contains $_.Value}
##Loop through and add each role
foreach($role in $roles){
    $AppRoleAssignment = @{
        "“PrincipalId"” = $MIID
        "“ResourceId"” = $GraphApp.Id
        "“AppRoleId"” = $Role.Id
    }
    # Assign the SharePoint permission
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $MIID -BodyParameter $AppRoleAssignment
}

Les autorisations ajoutées (illustrées dans la figure 1) sont requises pour l'exemple que je donne ici, mais il est important de déterminer les autorisations Microsoft Graph dont vous avez besoin et de les ajuster pour votre propre script.

Ensuite, le compte d'automatisation nécessite que les modules requis soient installés. Les modules suivants sont utilisés dans cet exemple, mais en fonction de vos besoins, assurez-vous que les bons modules sont installés :

Microsoft.Graph.Authentication
Microsoft.Graph.Groups
Microsoft.Graph.Identity.DirectoryManagement
Microsoft.Graph.Teams
PnP.PowerShell
Az.Accounts (celui-ci devrait déjà être installé dans le compte d'automatisation)

Création du script

Pour toute tâche d’automatisation réutilisable, vous souhaitez autant que possible éviter de mettre des références statiques dans le code. Il ne s’agit pas seulement d’une bonne pratique pour rendre les scripts réutilisables, mais cela aide également les autres à réutiliser et à développer votre script. Cela se fait en créant des paramètres dans le code qui sont transmis au moment de l'exécution. Dans ce script, je définis les paramètres d'entrée suivants :

SiteURL - Il s'agit de l'URL relative du site SharePoint associé. Il est utilisé pour renseigner le mailnickname du Groupe, qui est ensuite utilisé pour générer l'URL du site.
AdminURL - Il s'agit de l'URL d'administration de votre instance SharePoint Online.
GroupName - Il s'agit du nom du groupe à créer pour l'équipe.
GroupDescription - Il s’agit de la valeur de description du groupe.
DefaultOwner1 - Il s’agit du propriétaire du site.
DefaultOwner2 - Comme nous voulons au minimum deux propriétaires, il s’agit du deuxième propriétaire.
InternalOnly - Il s’agit d’une valeur booléenne permettant de définir si le site doit être rendu interne uniquement - la définition de cette valeur sur false permettra l’accès externe au site. Nous en reparlerons plus tard.

Param
(
  [Parameter (Mandatory= $true)]
  [String] $SiteURL,

  [Parameter (Mandatory= $true)]
  [String] $adminURL,

  [Parameter (Mandatory= $true)]
  [String] $GroupName,

  [Parameter (Mandatory= $true)]
  [String] $GroupDescription,

  [Parameter (Mandatory= $true)]
  [String] $DefaultOwner1,

  [Parameter (Mandatory= $true)]
  [String] $DefaultOwner2,

  [Parameter (Mandatory= $true)]
  [bool] $InternalOnly
)

Le domaine clé suivant consiste à se connecter à Microsoft Graph à l’aide de l’identité gérée du compte d’automatisation. Actuellement, cela doit utiliser la cmdlet Get-AzAccessToken pour acquérir un jeton qui est ensuite transmis à la cmdlet Connect-MgGraph. Une fois connecté, nous passons au point de terminaison bêta pour permettre la configuration des paramètres d'annuaire, qui n'est pas disponible dans la v1.0. Pour tester ce code localement, vous devez avoir les modules Microsoft.Graph, AZ et PNP.PowerShell installés sur votre machine.

##Connect to Azure to retrieve an access token
Connect-AzAccount -Identity
$Token = (Get-AzAccessToken -ResourceURL "https://graph.microsoft.com").token

##Connect to Microsoft Graph
Connect-MgGraph -AccessToken $Token
select-mgprofile beta

Lors de la création du groupe, nous utilisons les variables de paramètre déclarées ci-dessus pour créer le corps de la requête et le transmettre à l'applet de commande New-MgGroup. Mettez ensuite le script en pause pendant 60 secondes pour laisser le temps au groupe d'être complètement créé avant de continuer. Il s'agit d'une manière rudimentaire d'éviter les erreurs, principalement incluse ici pour vous aider à démarrer. Avant de mettre votre propre solution en production, il vaut la peine d’ajouter une gestion des erreurs plus robuste. Le corps du groupe contient les paramètres de base du groupe et est personnalisable pour tous les cas d'utilisation que vous pourriez avoir.

##Build Parameters for new M365 Group
$GroupParam = @{
    DisplayName = $GroupName
    description = $GroupDescription
    GroupTypes = @(
        "Unified"
    )
    SecurityEnabled     = $false
    IsAssignableToRole  = $false
    MailEnabled         = $false
    MailNickname        = $SiteURL
    "Owners@odata.bind" = @(
        "https://graph.microsoft.com/v1.0/users/$DefaultOwner1",
        "https://graph.microsoft.com/v1.0/users/$DefaultOwner2"
    )
}

#Provision M365 Group
$Group = New-MgGroup -BodyParameter $GroupParam

##Wait for Group to finish provisioning
start-sleep -seconds 60

Ensuite, nous suivons le même processus pour activer une équipe pour le groupe qui a été créé. Ceci est encore une fois personnalisable en fonction de vos besoins. Par exemple, j'ai choisi de créer une chaîne nommée « Bienvenue ! pour chaque équipe. Il s'agit d'un exemple assez simpliste, mais il peut être développé avec des canaux/messages de canal personnalisés, etc., pour créer des mises en page et des personnalisations d'équipe spécifiques.

##Build Parameters for new Team

$TeamParam = @{
       "Template@odata.bind" = "https://graph.microsoft.com/v1.0/teamsTemplates('standard')"
       "Group@odata.bind" = "https://graph.microsoft.com/v1.0/groups('$($Group.id)')"
       Channels = @(
             @{
                    DisplayName = "Welcome!"
                    IsFavoriteByDefault = $true
             }
       )
       MemberSettings = @{
             AllowCreateUpdateChannels = $false
             AllowDeleteChannels = $false
             AllowAddRemoveApps = $false
             AllowCreateUpdateRemoveTabs = $false
             AllowCreateUpdateRemoveConnectors = $false
       }
}

##Add Team to group
New-MgTeam -BodyParameter $TeamParam

J’ai également choisi d’ajouter l’équipe à la politique de cycle de vie du groupe des locataires. Si votre stratégie est configurée pour tous les groupes, cela ne sera pas obligatoire, mais de nombreuses organisations souhaiteront exclure les groupes clés des stratégies de cycle de vie. Comme aucun paramètre d'exclusion n'est disponible dans la stratégie, celui-ci doit être ajouté lors de la création du groupe.

##Add Group to tenant group lifecycle policy
Add-MgGroupToLifecyclePolicy -GroupLifecyclePolicyId (Get-MgGroupLifecyclePolicy).id -GroupId $Group.id

Enfin, si l'équipe doit être disponible en interne uniquement (en fonction du paramètre IsInternal), nous appliquons le paramètre Azure AD Directory pour bloquer l'ajout d'utilisateurs invités et utilisons PNP pour configurer les paramètres de partage de site afin de bloquer partage externe de données.

##If the Team is internal only, block guest access and external sharing
if($InternalOnly){

##Block Guest Access to Group if required
$Template = Get-MgDirectorySettingTemplate | ?{$_.displayname -eq "Group.Unified.Guest"}

$TemplateParams = @{
       TemplateId = "$($template.id)"
       Values = @(
             @{
                    Name = "AllowToAddGuests"
                    Value = "false"
             }
       )
}
New-MgGroupSetting -BodyParameter $TemplateParams -GroupId $Group.id

##Connect to PNP
Connect-PnPOnline -ManagedIdentity -Url $adminURL

##Set Sharing policy to internal only
$site = Set-pnptenantsite -SharingCapability Disabled -Url $url

}

En utilisant différents paramètres d'entrée, la configuration exacte de chaque équipe est entièrement personnalisable. Il s'agit d'un simple exemple d'équipe interne/externe, mais il devrait vous donner une idée de la façon de structurer le script pour permettre différentes options d'équipe.

Exécuter le script

L’exécution du script via Azure Automation est simple et demande les paramètres au moment de l’exécution (Figure 2).

Valider l'équipe

Une fois le script terminé, une nouvelle équipe sera dotée des paramètres définis et prête à être utilisée. En vérifiant dans SharePoint Online (illustré dans la figure 3), nous constatons que le site a été restreint pour autoriser uniquement le partage interne de fichiers.

Lors de l'enregistrement dans Teams, l'équipe reçoit les paramètres fournis et le message « Bienvenue ! » le canal est présent (comme le montre la figure 4)

Enfin, les invités externes ne peuvent pas être ajoutés à l'équipe, ce qui indique que le paramètre d'annuaire a été appliqué avec succès (comme le montre la figure 5).

Automatisation de la création d'équipes

Avec un effort relativement faible, la mise à disposition des équipes dans une organisation peut être automatisée pour répondre aux exigences de l'entreprise, ainsi qu'à celles de l'informatique. Exécuter le script directement à partir d'Azure Automation est une bonne chose, mais faire un pas en avant et examiner différentes méthodes pour déclencher le runbook permet aux organisations de faire preuve de créativité dans la façon dont elles structurent ce processus. Une fois le script principal en place, pourquoi ne pas déclencher le runbook depuis vos outils ITSM ? Ou depuis une PowerApp ? Cela peut être fait assez facilement en utilisant un Webhook et en l'appelant depuis l'application de votre choix tout en transmettant les paramètres requis. Un Webhook peut être créé dans Azure Automation, comme le montre la figure 6. Ceci est abordé plus en détail dans cette série sur la façon d'utiliser Azure Automation pour travailler avec SharePoint Online.

L'exemple très simpliste que je donne ici est disponible sur GitHub et contient très peu de gestion des erreurs et d'optimisation. Cependant, c'est un bon point de départ pour développer votre propre processus, et pousser Teams à fournir un processus automatisé offre beaucoup plus de contrôle que celui disponible dès le départ.

Planification et consolidation de la migration de la plateforme Microsoft

Simplifiez la planification de la migration, surmontez les défis de migration et terminez les projets plus rapidement tout en minimisant les coûts, les risques et les interruptions pour les utilisateurs.