Administration de Windows

Délégation d'autorisation dans Active Directory

Joel Yoker and Rob Campbell

Vue d'ensemble:

• Définition des rôles administratifs
• Développement d'un modèle d'unité d'organisation et de groupe de sécurité
• Utilisation des comptes secondaires
• Outils de délégation des droits

Les fonctionnalités de délégation d'Active Directory sont très puissantes, répondent à plusieurs problèmes de sécurité et simplifient les tâches de gestion. En délégant convenablement les droits dans Active

Directory®,vous pouvez appliquer des rôles spécifiés au sein de l'environnement, limiter l'impact et la probabilité d'erreurs administratives et appliquer le principe de moindre privilège à l'échelle de votre infrastructure. Pourtant, un grand nombre des organisations qui s'appuient sur Active Directory n'exploitent pas encore son pouvoir de délégation. Ceci est en partie dû au fait qu'à première vue, le développement d'un modèle de délégation Active Directory pour votre entreprise semble assez complexe. Si la plus grande difficulté consiste à développer un modèle de délégation qui réponde aux besoins uniques de votre organisation, la vérité est qu'il existe des modèles très simples qui peuvent être appliqués à la plupart des infrastructures informatiques avec un minimum de modifications.

Bien que chaque environnement soit différent à tel ou tel égard, la réalité est que la plupart des grandes entreprises présentent de nombreuses similitudes et sont confrontées aux mêmes défis informatiques. Par exemple, beaucoup d'organisations sont divisées en régions géographiques, ont évolué à partir d'équipes d'ingénierie informatique ou de support opérationnel distinctes et comportent des divisions indépendantes. En outre, un grand nombre d'organisations doivent faire face à des problèmes tels que la promotion des privilèges, les abus de compte de service et la « confiance ».

La confiance est un terme intéressant et qui sert souvent à justifier la présence de plusieurs forêts Active Directory. Les problèmes de confiance ont souvent pour origine la capacité d'une division ou d'une région à avoir un impact majeur sur la disponibilité des systèmes d'une autre division ou région. Il est courant que les niveaux de compétences diffèrent d'un pays à l'autre et que les connaissances approfondies de systèmes spécifiques requises pour le support d'une région ou d'une division particulière soient absentes. De ce fait, les divisions ne veulent généralement pas renoncer à leurs droits administratifs au profit d'un groupe centralisé.

Pendant ce temps, pour n'importe quelle mise en œuvre d'Active Directory, les administrateurs doivent définir les règles d'engagement pour les applications qui utilisent l'infrastructure Active Directory. Malheureusement, une approche courante, souvent citée dans les guides d'installation d'applications, consiste à ériger un compte de service en membre du groupe Administrateurs de domaine. Le problème avec cette approche est que ces comptes de service sont essentiellement des comptes génériques. En accordant des droits d'administrateur de domaine à ces comptes, vous soumettez l'environnement informatique à une menace significative. Les comptes de service sont facilement victimes d'une utilisation inappropriée de la part d'administrateurs malveillants ou négligents. Ils peuvent également être mis à profit par des personnes malveillantes qui exploitent les problèmes de sécurité sous-jacents dans une application.

Bien que ces difficultés puissent sembler insurmontables, elles constituent un scénario idéal pour l'implémentation d'un modèle de délégation Active Directory. Le développement d'un modèle de délégation est un processus de conception itératif et nous vous suggérons de suivre ces étapes :

1. Définissez les rôles administratifs informatiques au sein de votre organisation.
2. Développez un modèle d'unité d'organisation et de groupe de sécurité.
3. Établissez des comptes secondaires pour les administrateurs informatiques.
4. Déléguez les droits.

Examinons ces étapes plus en détail.

Définition des rôles

Le processus de définition des rôles repose sur une compréhension détaillée de l'administration des services et de l'administration des données. Ces concepts sont les pierres angulaires de tout modèle de délégation Active Directory.

Essentiellement, l'administration des services consiste à gérer les composants d'infrastructure de services d'annuaire critiques tels que les serveurs Exchange et les contrôleurs de domaines. L'administration de données est la gestion d'objets, tels que les boîtes aux lettres et les comptes d'utilisateur, qui résident au sein de ces services. Dans Active Directory, les administrateurs de services sont en fait responsables de la livraison et de la disponibilité de services d'annuaire tandis que les administrateurs de données gèrent les comptes d'utilisateur et de serveur, les groupes et les autres ressources de domaine.

Active Directory prend en charge la délégation d'autorisation granulaire par le biais d'unités d'organisation (UO). Les UO peuvent fréquemment être adaptées pour offrir le même niveau d'autorisation que celui dont disposent les administrateurs dans les modèles de services d'annuaire ou de domaine existants. Mais il importe de comprendre que certaines fonctions ne peuvent tout simplement pas être déléguées et doivent être gérées par un seul un groupe ou entité de confiance.

L'analyse des tâches revêt également une importance critique. Vous devez savoir quelles tâches Active Directory sont exécutées par les administrateurs et comment ces tâches sont mappées aux rôles. Par exemple, la création d'un site Active Directory est une tâche d'administration de service alors que la modification de l'appartenance au groupe de sécurité fait généralement partie de l'administration des données. Chaque tâche doit être évaluée selon sa fréquence, son importance et sa difficulté. Ce sont là des aspects vitaux de la définition des tâches parce qu'ils déterminent si un droit doit ou non être délégué. Les tâches qui sont exécutées de façon routinière, présentent un risque limité et sont très faciles à exécuter font d'excellentes candidates pour la délégation. En revanche, les tâches qui sont rarement exécutées, ont un grand impact dans toute l'organisation et nécessitent des niveaux élevés de compétences sont ne devraient pas être déléguées. Pour ces tâches, il convient plutôt de recourir à la promotion (en élevant temporairement un compte au rôle requis ou en réaffectant la tâche).

Dans la mesure où les grandes organisations partagent un grand nombre de caractéristiques, on peut raisonnablement supposer qu'un modèle de délégation commun puisse être implémenté. Dans le cadre de cet article, nous allons vous présenter une série de rôles définis qui activent les fonctionnalités de gestion tout en respectant les limites organisationnelles et en essayant de limiter les problèmes de confiance (par exemple, la disponibilité des actifs nécessaires à l'échelle de l'entreprise tels que les contrôleurs de domaine). Il convient de noter que ce modèle n'est qu'un exemple : c'est un excellent point de départ pour débattre des rôles dans votre organisation, mais vous ne devez pas envisager de suivre ces conseils à la lettre.

Quelques rôles sont déjà définis par Active Directory et d'autres doivent être entièrement créés pour compléter le modèle de délégation. Parmi la gamme de rôles qui conviendraient à un grand nombre d'environnements Active Directory, citons d'une part les Administrateurs d'entreprise, les Administrateurs de domaine et les Administrateurs de niveau 4 pour l'administration des services, et de l'autre les Administrateurs de niveau 3, les Administrateurs régionaux, les Administrateurs de niveau 2 et les Administrateurs de niveau 1 pour l'administration des données. Consultez la figure 1 pour obtenir une liste de ces rôles et de leurs responsabilités.

Figure 1 Define Roles and Responsibilities (en anglais)

Administrateurs de services

Regardons plus en détails les rôles d'administrateurs de services. Les administrateurs de services gèrent les composants d'infrastructure critiques et tous les administrateurs qui appartiennent à cette catégorie bénéficient de privilèges extrêmement élevés. Par conséquent, une stratégie de moindre privilège, qui veut que seuls les jeux d'autorisations nécessaires à l'exécution des tâches requises soient accordés, est fortement recommandée dans ce cas.

Les termes Administrateurs d'entreprise et Administrateurs de domaine Active Directory couvrent deux groupes d'administrateurs spéciaux dont le contexte de sécurité est requis pour des fonctions critiques dans l'annuaire. Ces groupes (Administrateurs d'entreprise et Administrateurs de domaine) sont responsables de l'administration des services au plus haut niveau. Pour limiter les risques inhérents aux groupes disposant de privilèges si élevés, nous vous conseillons de limiter fortement l'appartenance à ces groupes. En fait, les groupes Administrateurs d'entreprise ne devraient pas avoir de membres permanents et les groupes Administrateurs de domaine ne devraient compter qu'un nombre réduit et facilement gérable d'individus de confiance qui travaillent à plein temps pour l'organisation.

Lorsque des tâches d'administration d'entreprise telles que l'autorisation d'un serveur DHCP ou la création d'un site Active Directory doivent être exécutées, les Administrateurs de domaine du domaine racine de la forêt Active Directory peuvent promouvoir des privilèges en gérant l'appartenance au groupe Administrateurs d'entreprise. Ces privilèges ne doivent être accordés que pour de courtes périodes de temps afin d'éviter la création de membres permanents dans le groupe Administrateurs d'entreprise. Bien sûr, tous les membres d'un groupe Administrateurs de domaine d'une forêt Active Directory donnée doivent jouir de la même confiance.

La désactivation ou la paralysie de ces rôles prédéfinis représente un piège courant dans lequel tombent la plupart des organisations lorsqu'elles développent un modèle de délégation. La modification des rôles par défaut peut avoir des résultats imprévisibles et rien ne garantit que les révisions de service pack ou les mises à niveau de produits conserveront ces paramètres. De plus, ce type de modification crée un environnement qui n'est pas pris en charge hors de l'organisation. Une approche pratique consiste à utiliser les groupes et les rôles prédéfinis mais à en limiter l'appartenance. En agissant ainsi, vous devrez probablement créer de nouveaux rôles pour les administrateurs qui s'appuyaient précédemment sur l'appartenance à des groupes tels qu'Administrateurs de domaine.

Administrateurs de niveau 4 Le groupe Administrateurs de niveau 4 doit être composé d'administrateurs de services centralisés qui assurent la prise en charge de tous les services d'entreprise. Dans la mesure où il s'agit d'un rôle créé, les autorisations d'accès au service d'annuaire et au système peuvent être adaptées aux exigences spécifiques de votre organisation. Même si les membres de ce groupe sont des administrateurs de services, ils peuvent aussi occasionnellement exécuter des tâches de gestion des données à l'échelle de la forêt. Comme il existe de nombreuses classes de systèmes et différents domaines de responsabilité, les rôles de niveau 4 sont répartis en plusieurs sous-groupes dans l'annuaire. Par exemple, des groupes de niveau 4 distincts doivent être créés pour assurer une gestion discrète de systèmes spécifiques tels que les serveurs Exchange. Ce groupe fait également office de point de promotion pour les administrateurs de données.

Si les individus souhaitent souvent bénéficier de l'appartenance au groupe Administrateurs de domaine, c'est notamment parce qu'ils veulent obtenir des droits administratifs sur chaque système d'un domaine donné. Pour que ces administrateurs de services ouvrent leurs sessions dans un mode de moindre privilège, l'astuce consiste à accorder le contrôle des serveurs d'entreprise aux Administrateurs de niveau 4 sans en faire des Administrateurs de domaine. Afin d'empêcher la promotion des privilèges, les Administrateurs de niveau 4 ne doivent pas être autorisés à appartenir au groupe BUILTIN\Administrators sur les contrôleurs de domaine puisque ce groupe dispose, sur le service d'annuaire, de nombreux droits sous-jacents qui ne peuvent pas être séparés. Par exemple, un membre du groupe BUILTIN\Administrators d'un domaine donné peut gérer l'appartenance au groupe Administrateurs de domaine, ce qui permet aux membres de promouvoir les privilèges sans que s'exerce aucun contrôle ni équilibrage.

Souvenons-nous de la règle selon laquelle il ne faut pas paralyser les autorisations par défaut : ce risque peut être réduit en faisant des groupes de niveau 4 des membres imbriqués dans les groupes de domaine prédéfinis Opérateurs de serveur et Administrateurs de DNS. Ceci permet une gestion locale des contrôleurs de domaine tout en limitant la capacité des Administrateurs de niveau 4 à promouvoir des privilèges. Pour la plupart des systèmes (hormis les des contrôleurs de domaine, les serveurs de certificats, etc.), il conviendrait que le groupe Administrateurs de niveau 4 soit fait membre du groupe Administrateurs locaux. L'automatisatoin de l'appartenance aux groupes locaux imbriqués peut être obtenue avec la fonctionnalité Groupes restreints de la stratégie de groupe.

Administrateurs de données

Étudions maintenant les rôles d'administration de données. Ceux-ci doivent être conçus avec des droits cumulatifs, ce qui signifie qu'un administrateur de niveau 2 doit disposer de tous les droits d'un administrateur de niveau 1 ainsi que de quelques privilèges supplémentaires, et ainsi de suite. C'est pour cette raison que nous étudierons ces groupes en partant du groupe de plus bas niveau.

Administrateurs de niveau 1 Le groupe Administrateurs de niveau 1 doit s'occuper de la gestion générale des objets de répertoire précédemment créés. Ce groupe est destiné aux administrateurs ayant reçu la formation la moins poussée ou à ceux qui effectuent des tâches isolées, par exemple les réinitialisations de mots de passe. Accordez à ce groupe, dans son unité d'organisation, le droit de modifier les propriétés des comptes d'utilisateur, de réinitialiser les mots de passe des comptes d'utilisateur, de déverrouiller des comptes, d'activer et désactiver les comptes d'utilisateur, d'ajouter et de réinitialiser des comptes d'ordinateur poste de travail et de modifier l'appartenance à un objet de groupe pour les groupes non administrateurs.

Administrateurs de niveau 2 Ce groupe doit permettre la gestion et la création sélectives d'objets en autorisant uniquement la création d'objets pouvant être gérés par des administrateurs de niveau 1. (Par exemple, les groupes de sécurité peuvent uniquement être créés dans l'UO de groupes). Les administrateurs de niveau 2 peuvent ajouter et peuvent modifier les comptes d'administrateur de niveau 1, ajouter, modifier et supprimer des comptes utilisateur pour une UO, supprimer les objets Ordinateur poste de travail et enfin ajouter, modifier et supprimer les objets Serveur, Contact et Dossier Partagé.

Administrateurs régionaux Les droits de ce groupe sont exclusivement limités à la structure d'UO régionale. Cependant, ces administrateurs ne peuvent pas gérer les autres structures d'UO régionales du répertoire. Les comptes d'administrateurs régionaux doivent être considérés comme étant extrêmement privilégiés et, par conséquent, ces comptes sont enregistrés dans une hiérarchie d'UO séparée et gérés par les administrateurs de services du groupe Administrateurs de niveau 4. Les administrateurs régionaux sont autorisés à créer la plupart des objets sans restriction dans leur structure d'UO (une exception notable étant la création d'autres unités d'organisation), ce qui fait naître le risque supplémentaire que soient créés des objets ne pouvant pas être gérés par les niveaux inférieurs.

Administrateurs de niveau 3 De nombreuses organisations possèdent un support technique centralisé ou de niveau supérieur. Ce rôle remplit la liste d'administrateurs de données, constituant un groupe d'administrateurs de données au-dessus de tous les administrateurs régionaux. Les droits ne sont pas délégués aux groupes se trouvant spécifiquement dans le répertoire. En fait, ils sont établis par l'intermédiaire de l'appartenance imbriquée dans chaque groupe d'administrateurs régionaux. Cette approche fournit un point de promotion au niveau supérieur pour tous administrateurs de données, ainsi qu'un point d'entrée permettant de remonter les problèmes vers les groupes d'administration de services.

Élaboration d'un modèle d'UO et de groupe de sécurité

Une fois les rôles définis dans l'organisation, un modèle d'UO et de groupe de sécurité doit être défini. Il existe deux raisons principales pour créer une UO dans Active Directory : la délégation de droits et la création d'un point où les objets de stratégie de groupe peuvent être liés. Les UO définissent une étendue de la gestion dans le répertoire et peuvent être utilisées pour imposer des droits à des objets à divers niveaux. Par conséquent, la façon dont vous choisissez de déléguer l'autorisation doit jouer un rôle déterminant dans la manière dont vous implémentez votre structure d'UO.

Ceci étant établi, une UO de niveau supérieur (ou une série d'UO) devrait être directement créée en-dessous du domaine pour loger tous les objets. Cette UO a pour objectif spécifique de définir l'étendue de la gestion du niveau le plus élevé pour les administrateurs de niveau 4. La création d'une UO de premier supérieur, permet de faire démarrer explicitement les droits sur le service de répertoire au niveau de l'UO plutôt qu'au niveau du domaine. La délégation depuis une UO de niveau supérieur plutôt que depuis le domaine réduit le risque que des utilisateurs aient la possibilité de promouvoir des privilèges en manipulant les groupes de domaine prédéfinis mentionnés précédemment.

En-dessous des UO de niveau supérieur, vous devez créer des hiérarchies de sous-UO distinctes pour représenter chaque région ou chaque division disposant d'une équipe de gestion des données discrète. Chaque sous-UO régionale doit avoir une hiérarchie d'UO commune et non extensible pour la gestion des objets de répertoire. L'uniformité est essentielle à la gestion continue puisqu'une bonne partie de la délégation des droits sera automatisée. Il ne s'agit pas d'une mince affaire puisque chaque région peut désirer des UO uniques. Mais les administrateurs informatiques doivent maintenir leur position et, si une extension est nécessaire pour une région, la structure de sous-UO doit être étendue pour toutes les régions. Ceci peut tout d'abord sembler difficile, mais si l'organisation fournit un logement générique pour les objets, les situations isolées ont tendance à progressivement trouver leur place.

Finalement, créez des sous-groupes d'administration et des comptes séparés (un groupe Administrateurs de niveau 1, Administrateurs de niveau 2 et Administrateurs régionaux pour chaque hiérarchie de sous-UO) pour supprimer la capacité des administrateurs à promouvoir leurs privilèges. L'enregistrement de ces comptes dans des UO séparées permet la restriction de la gestion à leur niveau ou à un niveau inférieur. Ainsi, si tous les comptes Administrateurs de niveau 1 et le groupe de sécurité associé résident dans une UO où ils ne disposent d'aucun droit, les administrateurs ne pourront pas détourner d'autres comptes d'administrateur ni promouvoir les privilèges d'autres administrateurs jusqu'à leur niveau. Tout membre du groupe Administrateurs de domaine peut, par exemple, transformer n'importe quel autre compte utilisateur du domaine en un administrateur de domaine. Cependant, avec ce modèle d'UO en place, ce risque est réduit. La figure 2 présente un exemple de structure d'UO associée à des groupes de sécurité.

Figure 2** Structure d'UO et groupes de sécurité associés **

Établissement de comptes secondaires

Si l'on veut obtenir un modèle de délégation réussi, la clé du succès consiste à appliquer le principe de moindre privilège. Dans la pratique, cela signifie qu'une entité de sécurité dot uniquement pouvoir exécuter les tâches requises pour son rôle donné et rien plus. Malheureusement, beaucoup d'administrateurs informatiques utilisent la même entité de sécurité pour l'administration du répertoire et pour les tâches quotidiennes comme la navigation sur le Web et la lecture des messages électroniques. L'existence de comptes séparés réduit la probabilité qu'un administrateur d'un niveau n'endommage le service d'annuaire par erreur ou ne soit victime d'une attaque livrée par l'intermédiaire d'applications quotidiennes mais ciblant l'administrateur d'annuaire.

Pour accomplir ceci sans que l'utilisateur ne soit obligé de se déconnecter et de se reconnecter, utilisez le service d'ouverture de session secondaire (Runas.exe). Celui-ci autorise les utilisateurs à promouvoir leurs privilèges en fournissant une autre série d'informations d'identification lors de l'exécution de scripts ou d'exécutables sur les serveurs et les postes de travail.

Bien que le concept d'utilisation de comptes à moindres privilèges soit relativement simple, les organisations ont parfois des difficultés à le mettre en place car, en matière d'informatique, les vieilles habitudes sont difficiles à changer. Si l'on souhaite empêcher que des comptes privilégiés soient utilisés lors des tâches quotidiennes, une approche directe consiste à ne pas fournir d'accès au courrier à ces comptes dans Exchange Server et à appliquer cette méthode par le biais par la stratégie administrative de l'organisation. Cette approche relativement simple réduit de manière significative la probabilité que de tels comptes soient utilisés pour des tâches non administratives de routine.

Délégation de droits

L'étape finale dans le développement d'un modèle de délégation est la délégation des droits elle-même dans Active Directory. Elle implique la manipulation des entrées de contrôle d'accès (ACE) et des listes de contrôle d'accès (ACL) sur les données enregistrées dans l'annuaire. Les ACL placées sur les conteneurs Active Directory, définissent les objets qui peuvent être créés et leur mode de gestion. La délégation des droits concerne des opérations fondamentales sur les objets, telles que la possibilité d'afficher un objet, de créer un objet enfant d'une classe spécifiée ou de lire des informations sur les attributs et la sécurité pour les objets d'une classe spécifiée. Outre ces opérations fondamentales, Active Directory définit des autorisations étendues qui activent des opérations telles que Envoyer sous forme de et Gérer la topologie de la réplication.

Au cours des étapes précédentes, nous avons abordé la création de groupes de sécurité qui se mappent sur des rôles organisationnels définis. Cela signifie que pour chaque rôle, il existe un groupe de sécurité associé par structure de sous-UO. Pour implémenter le modèle de délégation, ces groupes doivent se voir attribuer des autorisations sur les objets de l'annuaire. À ce stade du processus, vous ne voulez pas réinventer la roue et créer un environnement extrêmement personnalisé. Essayez plutôt d'exploiter des groupes et des droits prédéfinis lorsque cela est possible. Disons qu'un rôle particulier doit gérer les enregistrements DNS pour la forêt. N'essayez pas de déléguer des droits sur les conteneurs et contextes d'attribution de noms apparentés au DNS intégré à Active Directory. Contentez-vous plutôt d'exploiter le groupe BUILTIN\lDNS Admins du domaine. En outre, les droits d'utilisateur et les autres autorisations peuvent être étendus via la stratégie de groupe pour fournir les droits supplémentaires requis pour gérer une classe spécifique de système en fonction d'un rôle donné.

Si vous attribuez des autorisations en utilisant la délégation, vous devez limiter voire complètement éliminer l'utilisation d'entrées de contrôle d'accès Refuser dans l'annuaire. Celles-ci peuvent se révéler complexes quand il s'agit de les dépanner. Une meilleure approche consiste à utiliser des ACE autorisées explicites pour accorder des droits aux groupes personnalisés représentant vos rôles. Rappelez-vous que les rôles définis par l'utilisateur, tels que les Administrateurs de niveau 4, ne disposeront que des droits explicites définis par ce rôle.

L'héritage est essentiel à la sécurité d'Active Directory et définit la façon dont une LCA particulière s'applique aux objets présents dans un conteneur ou sous-conteneur donné. Soyez toujours spécifique sur l'étendue de l'héritage en vous assurant que les ACE héréditaires sont appliquées aussi près des objets cibles que possible. Les autorisations de refus pouvant être héritées appliquées à l'objet parent précéderont toute autorisation de refus pouvant être héritée appliquée à l'objet grand-parent, ce qui constitue l'une des principales raisons pour lesquelles les entrées de contrôle d'accès Refuser ne sont pas recommandées pour la délégation pratique. De plus, les autorisations pouvant être héritées ne peuvent pas remplacer une ACE explicite sur un objet. C'est pourquoi il est conseillé de limiter ou de supprimer la capacité des administrateurs de niveau à modifier la liste de contrôle d'accès discrétionnaire (en supprimant le privilège de DACL d'écriture) sur les objets d'annuaire. (Notez que le créateur de l'objet dispose implicitement de ces droits). La règle de base est que si un administrateur a la capacité de modifier le DACL sur un objet, il le fera probablement. Ne laissez pas se perdre tout le travail fourni par votre organisation pour créer son modèle de délégation en introduisant des choix et des erreurs potentielles d'administration.

Il existe plusieurs outils dont vous devrez apprendre à vous servir convenablement pour implémenter un modèle de délégation Active Directory. Pour la plupart des grandes organisations, l'utilisation de l'Assistant Délégation intégré pour attribuer des autorisations dans l'annuaire représente une tâche imposante comportant de nombreuses possibilités d'erreurs d'administration. Il vaut plutôt mieux toujours recourir à l'automatisation pour s'assurer que le modèle de délégation est bien documenté, qu'il peut être pris en charge et qu'il offre une option de récupération au cas où les paramètres seraient perdus ou modifiés par inadvertance.

Le principal outil requis pour implémenter la délégation est DSACLS.EXE, un outil de ligne de commande utilisé pour manipuler les ACL de service d'annuaire sur les objets. Cet outil permet également de spécifier les indicateurs d'héritage d'un DACL sur l'objet parent. (Les indicateurs d'héritage incluent cet objet et ses sous-objets, les sous-objets uniquement et propagent les autorisations pouvant être héritées sur un niveau seulement). Les commandes DSACLS échoueront au final si un indicateur d'héritage est déterminé de façon incorrecte. Il est essentiel de procéder à des tests lorsque l'on utilise cet outil. Voici un exemple de syntaxe DSACLS pour déléguer la capacité de créer des objets Ordinateur dans l'UO de démonstration cible :

dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer

Le DSACLS est sensible à la casse en ce qui concerne les types d'objets. Cela signifie que si vous tentez de déléguer des autorisations pour la classe d'objet « cn = Ordinateur » la classe d'objet sur « cn = ordinateur » ne fonctionnera pas (voir la figure 3).

Figure 3** Erreurs due au non respect de la casse **(Cliquer sur l'image pour l'agrandir)

Un jeu de droits spécifique est requis pour la création de certains objets. Ceci est causé par les attributs « doit contenir » et « peut contenir » sur les objets. La meilleure métaphore que j'ai entendue pour expliquer ce concept est le modèle du hamburger. Les hamburgers doivent contenir un steak haché et un petit pain pour être considérés comme des hamburgers. Ils s'agit là des attributs « doit contenir » de la classe d'objet Hamburger. Les éléments tels que les condiments, le ketchup, la laitue et autres correspondent aux attributs « peut contenir ». Si nous voulions étendre la classe d'objet afin de définir un cheeseburger, nous ajouterions du fromage à la liste des attributs « doit contenir ».

Les objets utilisateurs fonctionnent de la même façon. Supposons que nous voulions suivre ce modèle pour créer des objets utilisateurs utilisant la syntaxe DSACLS suivante :

dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user 

L'administrateur serait confronté à plusieurs erreurs pendant la création de l'objet utilisateur. Nous devons accorder les privilèges nécessaires pour définir les attributs requis sur l'objet utilisateur, y compris la définition du mot de passe. Ceci est illustré dans la syntaxe DSACLS supplémentaire suivante.

Pour la première étape, accordez le privilège d'écrire des attributs « doit contenir » en accordant les autorisations Lecture générique/Écriture générique à tous attributs de la classe d'utilisateur :

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user

Pour l'étape suivante, accordez l'autorisation étendue de modifier le mot de passe :

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user

Pour l'étape finale, accordez l'autorisation Propriété de lecture et Propriété d'écriture pour l'attribut Dernier changement de mot de passe :

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user

Une fois que les autorisations correctes auront été déléguées, les rôles définis seront limités à la seule gestion des classes d'objets définies dans le DACL du conteneur. Revenons à l'exemple d'objet Ordinateur précédent. Le menu contextuel dans Utilisateur et Ordinateurs d'Active Directory limite la liste de nouveaux objets qui peuvent être créés par l'utilisateur auquel ces droits sont délégués (voir la liste limitée dans la figure 4).

Figure 4** Liste de nouveaux objets restreinte **

Le DSACLS peut également être automatisé pour permettre un déploiement complexe des droits. Voici certaines des commandes DSACLS qui peuvent être utilisées pour déléguer les droits permettant de manipuler des attributs d'adresse communs par-dessus les objets d'utilisateur dans un conteneur donné :

dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user

Les exemples de ce type sont courants pour la plupart de modèles de délégation et peuvent être utilisés avec les rôles précédemment définis.

Un autre outil utilisé pour implémenter la délégation est DSREVOKE.EXE, qui autorise les administrateurs à localiser et à supprimer les droits délégués pour des entités de sécurité spécifiques sur les objets de l'annuaire. Bien que cet outil puisse être très utile, il est spécifique aux entités de sécurité et n'évalue pas l'appartenance imbriquée dans les groupes de sécurité.

Outre ces outils de ligne de commande, nous vous recommandons aussi d'utiliser l'Attribution de droits d'utilisateur et les Groupes restreints avec la stratégie de groupe. Comme nous l'avons vu précédemment, l'attribution de droits d'utilisateur permet aux administrateurs informatiques d'étendre ou de supprimer des droits de bas niveau (tel que le droit à accéder à un système à distance et à le faire redémarrer) pour divers groupes d'utilisateurs sur des systèmes cibles spécifiques. Les groupes restreints peuvent être utilisés pour spécifier et appliquer l'appartenance aux groupes et domaines locaux au sein de la forêt. Ensemble, ces outils vous fournissent tout ce dont vous avez besoin pour automatiser et implémenter un modèle de délégation Active Directory.

Résumé

Bien que la tâche consistant à développer un modèle de délégation Active Directory puisse sembler complexe, la vérité est que des modèles très simples peuvent être appliqués à la plupart des infrastructures informatiques. L'une des étapes les plus importantes du déploiement d'un modèle de délégation pratique consiste à définir des rôles clairs. Vous devez veiller à ce que le nombre de rôles définis demeure assez limité et facile à gérer. Trouver le juste équilibre n'est pas aisé : si vous avez trop de rôles, certains ne seront pas utilisés alors que si vous n'en créez pas assez, vous ne pourrez pas séparer les rôles.

Souvenez-vous, lorsque vous définissez des tâches, qu'il faut les classer par fréquence, importance et difficulté. Une fois vous aurez défini ces rôles, développez une série de cas d'usage qui vous aideront à identifier ce que chaque rôle peut ou ne peut pas faire et à automatiser le processus de test. Ces cas d'usage bien préparés vous aideront à expliquer ces rôles aux parties prenantes dans votre organisation et limiteront les surprises dues aux erreurs d'automatisation.

Enfin, il est toujours judicieux d'adopter une approche pratique lorsque l'on développe un modèle de délégation. Rappelez-vous que simplicité est synonyme de prise en charge et qu'un modèle de délégation viable se rentabilisera de lui-même en contrôlant les droits administratifs au sein de votre environnement Active Directory.

Ressources supplémentaires

• Considérations relatives à la conception d'une délégation d'administration dans Active Directory
• Best Practices for Delegating Active Directory Administration (en anglais)

Joel Yoker est consultant senior dans l'équipe Microsoft Federal. Joel et Robe s'emploient tous deux à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.

Rob Campbell est spécialiste technique senior dans l'équipe Microsoft Federal. Joel et Robe s'emploient tous deux à développer et à déployer des solutions de sécurité destinées aux agences gouvernementales américaines.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.