par Darren Mar-Elia
Les futures versions de nombreux produits Microsoft tels que Exchange Server,
Site Server et SQL Server ne fonctionneront plus sur le principe d'annuaires autonomes,
mais sur Active Directory (AD). Cette mutation obligera beaucoup d'entreprises
à déployer une infrastructure AD, ce qui leur posera un double défi : la planification
d'une implémentation de AD et sa gestion pour répondre aux nombreux besoins des
utilisateurs et des applications.
L'une des caractéristiques les plus importantes d'Active Directory, à savoir sa
capacité de supporter l'administration déléguée des objets d'annuaire à des groupes
d'utilisateurs spécifiés, oblige à bien comprendre la sécurité AD et les complexités
de sa gestion des permissions. Il est également indispensable de comprendre l'éditeur
d'ACL (listes de contrôles d'accès) d'Active Directory et l'assistant Délégation
de contrôle, de connaître les défis et les pièges que l'on risque de rencontrer
en mettant sur pied une stratégie de délégation AD.
Délégation Active Directory : des hauts et des bas
Ce sont les objets et leurs attributs qui constituent Active Directory. Les attributs
d’un objet utilisateur sont, par exemple, le nom et l’adresse. Les attributs d’un
objet Unité organisationnelle (UO), peuvent être une description et une adresse.
Active Directory permet de définir aussi bien des permissions pour des objets
entiers que des attributs individuels pour tel ou tel objet. Cette granularité
donne une variété de possibilités lorsqu’il s’agit d’affecter des permissions
aux objets. Chaque classe d’objet peut en outre posséder un jeu de droits de sécurité
différent. Si une application ajoute une nouvelle classe ou un nouvel attribut
d’objet et étend le schéma d’Active Directory, l’extension du schéma peut très
bien requérir des droits de sécurité supplémentaires.
Ces droits sont les types d’opérations (par exemple lecture, écriture, suppression)
permis pour un objet particulier. Il existe dix-neuf droits de sécurité standards
dans Active Directory et une classe d’objet peut avoir un nombre quelconque de
droits étendus qui lui sont spécifiques. Par exemple, le droit Créer des objets
liens de sites n’intéresse et ne s’applique qu’aux classes d’objets pouvant contenir
des liens de sites.
La mise en place de permissions pour les objets et leurs attributs est au coeur
même de la délégation Active Directory. Pour contrôler quels utilisateurs sont
autorisés à apporter des changements à certains objets, on utilise le modèle de
sécurité d’AD. Pour gérer la délégation dans AD, il faut acquérir une expertise
de l’éditeur d’ACL de Windows 2000.
Chaque objet Active Directory possède une ACL (liste de contrôle d’accès) contenant
des entrées de contrôle d’accès (ACE). Les ACE se composent de droits ou de permissions
s’appliquant à un objet ou à un attribut. Un objet Active Directory stocke son
ACL dans l’attribut ntSecurityDescriptor. Mais celui-ci n’est habituellement pas
visible, lorsqu’on utilise les outils d’administration Active Directory habituels
pour afficher les objets.
Les ACL des objets peuvent s’afficher avec l’éditeur d’ACL. Certaines documentations
font une distinction entre une liste de contrôle d’accès discrétionnaire (DACL)
et une liste de contrôle d’accès système (SACL). Les DACL contrôlent quel utilisateur
a accès à un objet et son niveau d’accès. Une SACL définit une liste d’utilisateurs
dont l’accès à un objet provoquera un événement d’audit. Active Directory supporte
l’utilisation des SALC pour auditer l’accès aux objets.
Chaque classe d’objet du schéma Active Directory contient une ACL par défaut,
qui réside dans l’attribut DefaultSecurityDescriptor de la classe d’objet. Un
objet AD nouvellement créé qui n’hérite pas de permissions d’un objet parent ou
reçoit des permissions d’une autre source, reçoit une ACL basée sur l’attribut
DefaultSecurityDescriptor.
Le processus de définition des ACL d’AD donne plus de flexibilité que
les procédures de permissions des systèmes de fichiers
Le processus de définition des ACL d’AD donne plus de flexibilité que les procédures
de permissions des systèmes de fichiers. Lorsqu’une ACE est ajoutée à un objet
Active Directory pour un groupe d’utilisateurs particulier, il faut décider quels
droits accorder et refuser, ainsi que leur portée. Un droit peut s’appliquer à
un objet entier ou seulement certains de ses attributs. L’objet et ses attributs
peuvent avoir différents ensembles de droits. Par exemple pour définir la sécurité
d’une UO, on a la possibilité d’accorder des droits tels que Créer des objets
imprimantes et Supprimer des objets ordinateurs. Mais pour définir la sécurité
d’objets particuliers d’une UO, on a la possibilité de définir un simple accès
en lecture ou en écriture à chaque attribut. La Figure 1 montre des permissions,
telles que Lire Code Pays, pour l’objet UO Finance.
On peut également contrôler la portée des changements de sécurité. La Figure 1
montre, par exemple, une liste déroulante Appliquer à , qui permet de choisir le
type d’objet auquel s’applique l’ACE. L’ACE peut ne s’appliquer qu’à cette UO,
à tous les objets se trouvant dans cette UO (y compris les groupes et les utilisateurs
de l’UO) ou à des types d’objets individuels de l’UO (par exemple les ordinateurs,
les utilisateurs). Si vous ne faites pas attention, vous pouvez créer un réseau
de permissions compliqué en utilisant ce niveau de contrôle de sécurité Active
Directory.
Téléchargez cette ressource
Travail à distance – Guide complet pour les Directions IT et Métiers
Le travail à distance met à l'épreuve la maturité numérique des entreprises en termes de Cybersécurité, d'espace de travail, de bien-être des collaborateurs, de communication et gestion de projet à distance. Découvrez, dans ce nouveau Guide Kyocera, quels leviers activer prioritairement pour mettre en place des solutions de travail à domicile efficaces, pérennes et sécurisées.
