4.1 Présentation du modèle de délégation dynamique

DRA permet de gérer l'accès administratif à votre entreprise dans le cadre d'un modèle de délégation. Le modèle de délégation permet de définir un accès à « privilège minimal » pour les assistants administrateur par le biais d'un ensemble dynamique de contrôles qui peuvent s'adapter en fonction de l'évolution de l'entreprise. Le modèle de délégation fournit un contrôle d'accès administratif représentant de manière plus fidèle le fonctionnement de votre entreprise :

  • Des règles d'étendue flexibles permettent aux administrateurs de cibler des autorisations par rapport à des objets gérés spécifiques en fonction des besoins commerciaux plutôt que de la structure de l'entreprise.

  • La délégation basée sur les rôles permet d'octroyer les autorisations de manière cohérente et simplifie le provisioning.

  • L'assignation de privilèges peut être administrée sur l'ensemble des domaines, des locataires cloud et des applications gérées à partir d'un emplacement unique.

  • Les pouvoirs granulaires vous permettent de définir sur mesure l'accès spécifique octroyé aux assistants administrateur.

4.1.1 Contrôles du modèle de délégation

Pour provisionner l'accès via le modèle de délégation, les administrateurs utilisent les contrôles suivants :

  • Délégation : les administrateurs provisionnent l'accès aux utilisateurs et groupes en assignant un rôle qui dispose d'autorisations spécifiées dans le contexte d'une instance Active Views qui fournit l'étendue.

  • Instances Active Views : une instance Active Views représente une étendue spécifique d'objets gérés qui sont définis par une ou plusieurs règles. Les objets gérés identifiés par chaque règle dans une instance Active Views sont regroupés dans une étendue unifiée.

  • Règle Active Views : les règles sont définies par des expressions qui correspondent à un ensemble d'objets gérés en fonction de diverses conditions telles que le type d'objet, l'emplacement, le nom, etc.

  • Rôles : un rôle représente un ensemble spécifique de pouvoirs (autorisations) requis pour exécuter une fonction d'administration spécifique. DRA fournit un nombre de rôles intégrés pour des fonctions métier courantes et vous pouvez définir des rôles personnalisés mieux adaptés aux besoins de votre organisation.

  • Pouvoirs : un pouvoir définit une autorisation spécifique pour les tâches prises en charge par l'objet géré telles que l'affichage, la modification, la création, la suppression, etc. Les autorisations relatives à la modification d'un objet géré peuvent à leur tour être décomposées en propriétés spécifiques qui peuvent être éditées. DRA fournit une vaste liste de pouvoirs prédéfinis pour les objets gérés pris en charge et permet de définir des pouvoirs personnalisés pour étendre le provisioning via le modèle de délégation.

4.1.2 Mode de traitement des requêtes par DRA

Lorsque le serveur d'administration reçoit une requête pour une action, telle que le changement d'un mot de passe, il procède comme suit :

  1. Il recherche les instances Active Views qui sont configurées pour gérer l'objet cible de l'opération.

  2. Il valide les pouvoirs assignés au compte qui demande l'action.

    1. Il évalue toutes les assignations Active Views qui contiennent l'assistant administrateur demandant l'opération.

    2. Une fois que cette liste est dressée, il répertorie toutes les instances Active Views qui contiennent l'objet cible et l'assistant administrateur.

    3. Il compare les pouvoirs avec ceux requis pour effectuer l'opération qui émet la requête.

  3. Si le compte dispose du pouvoir approprié, le serveur d'administration permet d'effectuer l'action.

    Si le compte ne dispose pas du pouvoir approprié, le serveur d'administration renvoie une erreur.

  4. Il met à jour Active Directory.

4.1.3 Exemples de la façon dont DRA traite les assignations de délégation

Les exemples ci-après décrivent les scénarios courants qui surviennent dans la façon dont DRA évalue le modèle de délégation lors du traitement d'une requête :

Exemple 1 : modification du mot de passe d'un utilisateur

Lorsqu'un assistant administrateur tente de définir un nouveau mot de passe pour le compte utilisateur JSmith, le serveur d'administration recherche toutes les instances Active Views comprenant JSmith. Il recherche toutes les instances Active Views qui indiquent JSmith directement, par le biais d'une règle de caractère joker ou via l'adhésion à un groupe. Si une instance Active Views inclut d'autres instances Active Views, le serveur d'administration recherche également ces instances Active Views supplémentaires. Le serveur d'administration détermine si l'assistant administrateur dispose du pouvoir Réinitialiser le mot de passe du compte utilisateur dans l'une de ces instances Active Views. Si l'assistant administrateur possède le pouvoir Réinitialiser le mot de passe du compte utilisateur, le serveur d'administration réinitialise le mot de passe de JSmith. S'il ne dispose pas de ce pouvoir, le serveur d'administration refuse la requête.

Exemple 2 : chevauchement d'instances Active Views

Un pouvoir définit les propriétés d'un objet qu'un assistant administrateur peut afficher, modifier ou créer dans votre domaine ou votre sous-arborescence gérée. Plusieurs instances Active Views peuvent inclure le même objet. Cette configuration est désignée sous le terme de chevauchement d'instances Active Views.

Lorsque des instances Active Views se chevauchent, vous pouvez accumuler un ensemble de pouvoirs différents pour les mêmes objets. Par exemple, si une instance Active Views vous permet d'ajouter un compte utilisateur à un domaine et qu'une autre instance Active Views vous permet de supprimer un compte utilisateur du même domaine, vous pouvez ajouter ou supprimer des comptes utilisateur dans ce domaine. De cette manière, les pouvoirs dont vous disposez sur un objet donné sont cumulatifs.

Il est important de comprendre comment se chevauchent les instances Active Views et comment vous pouvez obtenir des pouvoirs accrus sur les objets inclus dans ces dernières. Imaginons la configuration Active Views illustrée dans la figure suivante.

Les onglets blancs identifient les instances Active Views par emplacement : New York City et Houston. Les onglets noirs identifient les instances Active Views selon leur fonction organisationnelle : Sales et Marketing. Les cellules affichent les groupes inclus dans chaque instance Active Views.

Le groupe NYC_Sales et le groupe HOU_Sales sont représentés tous les deux dans l'instance Active Views Sales. Si vous disposez de pouvoirs dans l'instance Active Views Sales, vous pouvez gérer tous les membre des groupes NYC_Sales et HOU_Sales. Si vous disposez également de pouvoirs dans l'instance Active Views New York City, ces pouvoirs supplémentaires s'appliquent au groupe NYC_Marketing. De cette manière, les pouvoirs s'accumulent selon les chevauchements des instances Active Views.

Le chevauchement des instances Active Views peut fournir un modèle de délégation souple et puissant. Toutefois, cette fonction peut également avoir des conséquences inattendues. Planifiez soigneusement vos instances Active Views pour être certain que chaque assistant administrateur dispose uniquement des pouvoirs prévus pour chaque compte utilisateur, groupe, unité organisationnelle, contact ou ressource.

Groupes dans plusieurs instances Active Views

Dans cet exemple, le groupe NYC_Sales est représenté dans plusieurs instances Active Views. Les membres du groupe NYC_Sales sont représentés dans l'instance Active Views New York City parce que le nom du groupe correspond à la règle Active View NYC_*. Le groupe est également dans l'instance Active Views Sales, car son nom satisfait à la règle Active View*_Sales. En incluant le même groupe dans plusieurs instances Active Views, vous pouvez autoriser différents assistants administrateur à gérer les mêmes objets différemment.

Utilisation des pouvoirs dans plusieurs instances Active Views

Supposons qu'un assistant administrateur, JSmith, dispose du pouvoir Modifier les propriétés des utilisateurs généraux dans l'instance Active Views New York City. Ce premier pouvoir permet à JSmith de modifier toutes les propriétés sous l'onglet Général de la fenêtre des propriétés d'un utilisateur. JSmith possède le pouvoir Modifier les propriétés du profil utilisateur dans l'instance Active Views Sales. Ce deuxième pouvoir permet à JSmith de modifier toutes les propriétés sous l'onglet Profil de la fenêtre des propriétés d'un utilisateur.

La figure suivante indique les pouvoirs que JSmith possède pour chaque groupe.

JSmith dispose des pouvoirs suivants :

  • Propriétés générales dans l'instance Active Views NYC_*

  • Propriétés du profil dans l'instance Active Views *_Sales

La délégation de pouvoirs dans ces chevauchements d'instances Active Views permet à JSmith de modifier les propriétés générales et de profil du groupe NYC_Sales. Par conséquent, JSmith dispose de tous les pouvoirs accordés dans toutes les instances Active Views qui représentent le groupe NYC_Sales.