Autorisations des runbooks
Comment autoriser/refuser l’accès à certains runbooks.
Champ d’application
Cela explique comment accorder/refuser l’accès à certains runbooks dans un tenant Azure. Si vous cherchez des réponses concernant les autorisations MS Graph API nécessaires pour exécuter une certaine action en tant que runbook, veuillez consulter notre prérequis.
Overview
« Runbook Permissions » définit la visibilité des runbooks pour certains utilisateurs. Certains runbooks peuvent également être bloqués/masqués globalement.
Comme les Runbook Customizations, la définition de ces autorisations se fait en fournissant une configuration au format JSON en tant qu’administrateur RealmJoin dans le portail web de RealmJoin à https://portal.realmjoin.com/settings/runbooks-permissions .
À propos de ce guide
Nous allons donner une courte description de la syntaxe, puis construire un exemple complet étape par étape. N’hésitez pas à aller directement à l’exemple complet et à commencer à partir de là.
Syntaxe de configuration
Noms des runbooks
Les runbooks sont référencés par leur nom, tel qu’il apparaît dans le compte Azure Automation, par exemple rjgit-group_general_remove-group.
Des jokers ('*') peuvent être utilisés pour faire correspondre plusieurs runbooks. Plusieurs jokers peuvent être utilisés dans la même chaîne, par exemple rjgit-*_security_*. Cela correspondrait à tous les exemples suivants :
rjgit-org_security_list-inactive-usersrjgit-device_security_enable-or-disable-device
Le préfixe rjgit- désigne les runbooks importés depuis notre dépôt GitHub public. Les runbooks spécifiques au client n’ont pas de préfixe, par exemple user_userinfo_custom-runbook
Entra ID Groups
Les groupes Entra ID seront référencés à l’aide de leur ID d’objet, comme 91688d11-9a34-42cd-8d1e-ce617d6c1234. Actuellement, seuls les groupes de sécurité peuvent être utilisés.
Structure JSON et exemple
Nous allons construire un exemple de configuration complet étape par étape.
Une configuration JSON se compose de plusieurs sections, mais toutes les sections sont facultatives et peuvent être omises.
Il est permis d’ajouter des commentaires en utilisant le préfixe "//".
EnabledRunbookPatterns
Cette section contient une liste de runbooks autorisés à être utilisés. Si cette section est omise, tous les runbooks sont activés/autorisés par défaut.
Si vous définissez cette section, alors seuls les runbooks mentionnés dans cette section seront utilisables par n’importe quel rôle / support et administrateur.
Exemple
Autoriser uniquement certains runbooks individuels en fournissant leur nom complet
rjgit-group_general_remove-groupAutoriser tous les runbooks liés aux appareils depuis notre dépôt partagé
rjgit-device_*Autoriser tous les runbooks utilisateur partagés
rjgit-user_*Autoriser tous les runbooks locaux spécifiques au client liés aux utilisateurs
user_*
Cela exclut implicitement de nombreux runbooks basés sur des groupes et tous les runbooks basés sur des organisations. Soyez-en conscient.
DisabledRunbookPatterns
Une liste de runbooks désactivés / interdits globalement. Si cette section est omise ou vide, tous les runbooks activés (fournis via EnabledRunbookPatterns) sont utilisables.
Les entrées de cette section ont priorité sur les entrées de EnabledRunbookPatterns - les runbooks seront masqués/ne seront utilisables par personne dans ce tenant.
Exemple
Nous allons réutiliser la EnabledRunbookPatterns section précédente.
Désactiver tous les runbooks partagés (
rjgit-) dans la catégoriesecurity.
Rôles
Dans cette section, vous pouvez attribuer une liste de runbooks à un groupe Entra ID. Cela permet de définir plusieurs rôles de support/opérateur dans votre tenant.
Si cette section est omise, tout le support RealmJoin et les administrateurs ont accès à tous les runbooks indiqués dans les sections précédentes.
Si elle est activée, tous les utilisateurs n’appartenant pas à un rôle ne verront aucun runbook.
Exemple
En poursuivant avec ce que nous avons, créons un rôle de support des appareils DeviceAdmin et un rôle de support utilisateur UserAdmin.
Nous appliquerons ces rôles à plusieurs groupes Entra ID et, pour chaque rôle, nous donnerons une liste de runbooks autorisés. Soyez attentif : cela limitera le rôle de support utilisateur à un petit ensemble de runbooks uniquement.
Ajoutons des commentaires ("//") à côté de l’ID d’objet du groupe pour aider le lecteur en fournissant les noms des groupes Entra ID.
Maintenant le UserAdmin rôle peut :
attribuer des licences à tous les utilisateurs de votre tenant
modifier les adresses e-mail de tous les utilisateurs de votre tenant
Le DeviceAdmin le rôle peut
effacer n’importe quel appareil de votre tenant
TargetEntityGroups
Peut-être avez-vous des utilisateurs VIP essentiels. Il ne devrait pas être possible pour n’importe quel membre du support d’effacer l’appareil d’un VIP ou de modifier l’adresse e-mail d’un VIP. Nous pouvons utiliser le « ciblage » pour restreindre les rôles sur les utilisateurs critiques à des équipes dédiées.
Les "Devices" seront ciblés par leur utilisateur principal/assigné, mais pas par l’objet appareil dans Entra ID. Cela permet de s’en tenir à un modèle de groupe purement basé sur les utilisateurs.
Nous supposons que des groupes Entra ID existent et contiennent des utilisateurs VIP critiques. À l’aide de cette section, nous pouvons définir avec soin certains rôles et runbooks plus critiques pour ces groupes Entra ID spécifiques (cibles).
Évidemment, si vous omettez cette section, tous les utilisateurs/groupes/appareils de votre tenant sont traités sur un pied d’égalité.
Si vous définissez TargetEntityGroups, cela ne devrait avoir aucun impact sur les autres groupes non mentionnés dans la section.
Exemple complet
Supposons le groupe 0000c0af-c217-41e9-b790-3043788f0000 est notre groupe d’utilisateurs VIP.
Nous introduisons un nouveau groupe Entra ID 4444c0af-c217-41e9-b790-3043788f4444 contenant le personnel de support qui a été approuvé pour administrer les utilisateurs VIP. Ce personnel de support doit également disposer de toutes les autres autorisations de support de base, nous l’ajouterons donc aux rôles existants.
« Restreindre » un rôle n’accordera pas de nouveaux rôles à un membre du support.
Exemple : restreindre le personnel de support US à la gestion des seuls utilisateurs US
Dans ce scénario, nous avons du personnel de support basé aux États-Unis qui ne doit gérer que les utilisateurs situés aux États-Unis. Pour appliquer cette restriction :
Créez une règle d’autorisation qui refuse explicitement aux soutiens US la possibilité d’exécuter des runbooks sur tous les utilisateurs.
Ajoutez une règle d’exception qui autorise explicitement l’exécution des runbooks uniquement pour les utilisateurs US.
Cela garantit que les soutiens US disposent d’autorisations strictement limitées au public cible prévu (les utilisateurs US) et empêche toute interaction accidentelle avec des utilisateurs hors de ce périmètre.
Mise en œuvre
Un groupe Entra de Runbook Runners doit être attribué dans le portail Realm Join
Paramètres > Autorisations > Autorisations du rôle Runbook Runner
Le groupe Entra des soutiens US doit être membre du groupe Runbook Runners pour permettre l’opération générale des runbooks dans le portail RealmJoin.
Ajout d’un nouveau rôle sous Paramètres > Autorisations des runbooks
Dans la section Rôles, ajoutez le rôle USSupporters avec son groupe Entra (ID d’objet du groupe)
Ajoutez AllowedRunbookPatterns pour les USSupporters
Modifiez les TargetEntityGroups
Le groupe Tous les utilisateurs doit Restreindre le rôle USSupporters avec une valeur vide (aucun ID d’objet de groupe Entra n’est ajouté ici). Il s’agit d’un refus implicite !
Le groupe Utilisateurs US doit Restreindre le rôle USSupporters à l’ID d’objet du groupe Entra des soutiens US

Ci-dessous l’exemple complet pour ce scénario :
SchedulingEnabledRunbookPatterns
Cette section contient une liste de runbooks qui seront marqués comme « planifiables ». RealmJoin Port permettra d’attribuer / gérer des planifications pour ces runbooks. Voir Planification des runbooks.
L’exemple suivant décrit le comportement par défaut si SchedulingEnabledRunbookPatterns n’est pas défini :
SchedulingDisabledRunbookPatterns
Cette section contient une liste de runbooks qui seront inscrits sur liste noire et ne pourront pas être marqués comme « planifiables ». RealmJoin Port n’autorisera pas l’attribution / la gestion de planifications pour ces runbooks. Voir Planification des runbooks.
Un runbook présent à la fois dans SchedulingEnabledRunbookPatterns et SchedulingDisabledRunbookPatterns sera renverra pas planifiable.
Par défaut, aucun runbook n’est inscrit sur liste noire. L’exemple suivant démontre simplement la syntaxe :
Mis à jour
Ce contenu vous a-t-il été utile ?