8.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 :

8.3.1 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 ActiveView comprenant JSmith. Il recherche toutes les instances ActiveView 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 ActiveView inclut d'autres instances ActiveView, le serveur d'administration recherche également ces instances ActiveView 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 ActiveView. 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.

8.3.2 Exemple 2 : chevauchement d'instances ActiveView

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 ActiveView peuvent inclure le même objet. Cette configuration est désignée sous le terme de chevauchement d'instances ActiveView.

Lorsque des instances ActiveView se chevauchent, vous pouvez accumuler un ensemble de pouvoirs différents pour les mêmes objets. Par exemple, si une instance ActiveView vous permet d'ajouter un compte utilisateur à un domaine et qu'une autre instance ActiveView 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 ActiveView et comment vous pouvez obtenir des pouvoirs accrus sur les objets inclus dans ces dernières. Imaginons la configuration ActiveView illustrée dans la figure suivante.

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

Le groupe NYC_Sales et le groupe HOU_Sales sont représentés tous les deux dans l'instance ActiveView Sales. Si vous disposez de pouvoirs dans l'instance ActiveView Sales, vous pouvez gérer tous les membre des groupes NYC_Sales et HOU_Sales. Si vous disposez également de pouvoirs dans l'instance ActiveView 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 ActiveView.

Le chevauchement des instances ActiveView 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 ActiveView 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 ActiveView

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

Utilisation des pouvoirs dans plusieurs instances ActiveView

Supposons qu'un assistant administrateur, JSmith, dispose du pouvoir Modifier les propriétés des utilisateurs généraux dans l'instance ActiveView 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 ActiveView 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 ActiveView NYC_*

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

La délégation de pouvoirs dans ces chevauchements d'instances ActiveView 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 ActiveView qui représentent le groupe NYC_Sales.