For the complete documentation index, see llms.txt. This page is also available as Markdown.

Autorisations du runbook

Comment accorder/refuser l'accès à certains runbooks.

Champ d’application

Cela explique comment accorder/refuser l'accès à certains runbooks dans un locataire Azure. Si vous cherchez des réponses concernant les autorisations MS Graph API nécessaires pour exécuter une certaine action sous forme de runbook, veuillez consulter notre conditions requises.

Vue d’ensemble

"Runbook Permissions" définissent la visibilité des runbooks pour certains utilisateurs. Certains runbooks peuvent aussi être bloqués/masqués globalement.

Comme les Personnalisations des runbooks, la définition de ces autorisations se fait en fournissant une configuration au format JSON en tant qu'administrateur RealmJoin dans le portail web RealmJoin à l'adresse https://portal.realmjoin.com/settings/runbooks-permissions .

À propos de ce guide

Nous donnerons une brève description de la syntaxe puis construirons un exemple complet, étape par étape. N'hésitez pas à aller directement à l'exemple complet et à commencer à partir de .

Syntaxe de configuration

Noms des runbooks

Les runbooks sont référencés par leurs noms tels qu'ils apparaissent dans le compte Azure Automation, par ex. 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 ex. rjgit-*_security_*. Cela correspondrait à tous les exemples suivants :

  • rjgit-org_security_list-inactive-users

  • rjgit-device_security_enable-or-disable-device

Le préfixe préfixe rjgit- désigne les runbooks importés depuis notre dépôt GitHub public. Les runbooks spécifiques aux clients n'ont pas de préfixe, par ex. 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. À l'heure actuelle, seuls les groupes de sécurité peuvent être utilisés.

Structure JSON et exemple

Nous construirons un exemple complet de configuration, étape par étape.

Une configuration JSON se compose de plusieurs sections, mais toutes les sections sont facultatives et peuvent être omises.

Il est autorisé 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, seuls les runbooks mentionnés dans cette section pourront être utilisés par n'importe quel rôle / support et administrateur.

Exemple

  • Autoriser uniquement certains runbooks individuels en indiquant leur nom complet

    rjgit-group_general_remove-group

  • Autoriser 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 liés aux utilisateurs spécifiques au client (locaux)

    user_*

Cela exclut implicitement de nombreux runbooks basés sur les groupes et sur l'organisation. Soyez attentif.

DisabledRunbookPatterns

Une liste de runbooks globalement désactivés / interdits. Si cette section est omise ou vide, tous les runbooks activés (fournis via EnabledRunbookPatterns) sont utilisables.

Les entrées de cette section sont prioritaires sur les entrées de EnabledRunbookPatterns - les runbooks seront masqués / inutilisables pour quiconque dans ce locataire.

Exemple

Nous réutiliserons la EnabledRunbookPatterns section précédente.

  • Désactiver tous les runbooks partagés (préfixe rjgit-) dans la sécurité catégorie.

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 locataire.

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.

Exemple

En poursuivant avec ce que nous avons, créons un rôle de support pour les 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 conscient que cela limitera le rôle de support utilisateur à seulement un petit ensemble de runbooks.

Ajoutons des commentaires ("//") à côté de l'ID d'objet du groupe, afin d'aider le lecteur en donnant les noms des groupes Entra ID.

Maintenant, le UserAdmin rôle peut :

  • attribuer des licences à tous les utilisateurs de votre locataire

  • modifier les adresses e-mail de tous les utilisateurs de votre locataire

Le DeviceAdmin rôle peut

  • effacer n'importe quel appareil dans votre locataire

TargetEntityGroups

Vous avez peut-être des utilisateurs VIP cruciaux. Il ne devrait pas être possible pour n'importe quel personnel de 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.

"Devices" seront ciblés via leur utilisateur principal/attribué, et non via l'objet appareil dans Entra ID. Cela permet de s'en tenir à un modèle de groupe purement basé sur les utilisateurs.

Nous partons du principe qu'il existe des groupes Entra ID contenant des utilisateurs VIP critiques. Grâce à 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 locataire sont traités à é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 que le groupe 0000c0af-c217-41e9-b790-3043788f0000 soit notre groupe d'utilisateurs VIP.

Nous introduisons un nouveau groupe Entra ID 4444c0af-c217-41e9-b790-3043788f4444 contenant du personnel de support autorisé à administrer les utilisateurs VIP. Ce personnel de support doit également disposer de toutes les autres autorisations de support de base, nous les ajouterons donc aux rôles existants.

Le fait de « restreindre » un rôle n'accordera pas de nouveaux rôles à un support.

Exemple : restreindre le personnel de support américain à la gestion des seuls utilisateurs américains

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 imposer cette restriction :

  • Créez une règle d'autorisation qui refuse aux soutiens US la possibilité d'exécuter des runbooks sur tous les utilisateurs.

  • Ajoutez une règle d'exception qui autorise l'exécution des runbooks uniquement pour les utilisateurs US.

Cela garantit que les soutiens US disposent d'autorisations strictement limitées à leur public cible prévu (utilisateurs US) et empêche toute interaction accidentelle avec des utilisateurs hors de ce périmètre.

Mise en œuvre

  1. Un groupe Entra de lanceurs de runbooks doit être attribué dans le portail RealmJoin

    1. Paramètres > Autorisations > Autorisations des lanceurs de runbooks

    2. Le groupe Entra des soutiens US doit être membre du groupe Runbook Runners pour autoriser l'exécution générale des runbooks dans le portail RealmJoin.

  2. Ajout d'un nouveau rôle sous Paramètres > Autorisations des runbooks

    1. Dans la section Rôles, ajoutez le rôle USSupporters avec son groupe Entra (ID d'objet du groupe)

    2. Ajoutez AllowedRunbookPatterns pour les USSupporters

  3. Modifiez TargetEntityGroups

    1. Le groupe All-Users doit restreindre le rôle USSupporters avec une valeur vide (aucun ID d'objet de groupe Entra n'est ajouté ici). C'est un refus implicite !

    2. Le groupe US Users doit restreindre le rôle USSupporters à l'ID d'objet du groupe Entra des soutiens US

Restreindre le personnel de support US à la gestion des seuls utilisateurs US

Voici 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 mis sur liste noire pour ne pas être marqués comme « planifiables ». RealmJoin Port ne permettra pas d'attribuer / gérer des planifications pour ces runbooks. Voir Planification des runbooks.

Un runbook présent à la fois dans SchedulingEnabledRunbookPatterns et SchedulingDisabledRunbookPatterns sera pas planifiable.

Par défaut, aucun runbook n'est mis sur liste noire. L'exemple suivant illustre uniquement la syntaxe :

Mis à jour

Ce contenu vous a-t-il été utile ?