L’un des points forts d’AD par rapport aux domaines de Windows NT 4.0, est la délégation : la possibilité de créer un utilisateur ou un groupe avec des pouvoirs définis de façon très détaillée. Sous NT 4.0, les utilisateurs sont soit tous puissants (membres du groupe Domain Admins, par exemple) soit relativement impuissants (membres du groupe Domain Users, par exemple). En revanche, AD permet de créer des « sous-administrateurs », c’est-à-dire des gens qui ont un pouvoir administratif, mais inférieur à celui d’un administrateur de domaine. AD permet aussi d’octroyer à certaines personnes le contrôle complet sur uniquement un sous-ensemble de domaine (c’est-à-dire, une OU – organizational unit). Mieux encore, avec son Delegation of Control Wizard, Microsoft a simplifié la tâche plutôt complexe que constitue la délégation.Cependant, la délégation d’AD n’a jamais été parfaite, et ce pour deux raisons. Premièrement, bien qu’un wizard aide à pratiquer la délégation, il n’en est pas qui permette d’annuler cette même délégation. Or, il est toujours difficile de retirer un pouvoir que l’on a accordé.
Il faut pour cela creuser au travers de plusieurs couches de la GUI de sécurité. Deuxièmement, AD ne permet pas de déterminer facilement quelles délégations vous avez instaurées. Avec son superbe outil ligne de commande Dsrevoke, Microsoft a simplifié les deux processus : celui de la documentation et celui de l’annulation des délégations existantes. Vous trouverez Dsrevoke au Microsoft Download Center (http://www.microsoft.com/downloads).
DSREVOKE
Dsrevoke indique exactement les permissions qu’un utilisateur ou groupe donné a sur un domaine. Dans la commande
dsrevoke /report
vous utiliseriez le format domainname\username ou domainname\groupname pour la variable user-or-group-name, où domainname\username est le nom NetBIOS du domaine. (Je n’arrive pas à faire fonctionner le nom DNS).
Supposons que vous travailliez dans un domaine nommé bigfirm.biz avec Bigfirm comme nom de NetBIOS. Pour connaître les pouvoirs qu’un groupe appelé Test a sur le domaine local, vous taperiez
dsrevoke /report bigfirm\test
Le rapport résultant ne donnera pas une explication complète des pouvoirs de test dans bigfirm, mais il indiquera si Test a délégué explicitement des pouvoirs dans Bigfirm.
Toutefois, le rapport ne montrera pas les pouvoirs que Test possède parce qu’il appartient à un autre groupe. Si Test fait partie d’un groupe appelé Bigtest et si celui-ci a quelques pouvoirs, Test en héritera mais le rapport Dsrevoke ne l’affichera pas parce que le pouvoir en question n’est pas accordé explicitement à Test.
Pour identifier les pouvoirs de Test dans un domaine différent, on peut recourir à l’option /domain pour spécifier le domaine concerné par le rapport. Cette option prend le nom NetBIOS ou DNS. Si vous devez fournir à Dsrevoke un nom et un mot de passe administratif pour ce domaine, vous pouvez utiliser les options /username et /password. Par exemple, la commande
dsrevoke /report "/domain:apex.com"
/username:joeadmin /password:swordfish
bigfirm\test
identifierait les pouvoirs de Test sur un domaine appelé apex.com. Le nom du domaine est placé entre guillemets parce que le nom DNS du domaine inclut un point ; en effet, les caractères spéciaux tels que les espaces et les signes de ponctuation doivent être assortis de guillemets. Cette commande ordonne aussi à Dsrevoke d’offrir le nom de compte utilisateur joeadmin et le mot de passe swordfish, dans le cas où apex.com voudrait connaître l’identité du demandeur.
Mais les domaines peuvent être vastes et peuvent contenir de nombreuses OU. Pour un groupe donné, vous pouvez ne vous intéresser qu’à ses pouvoirs sur une OU particulière, sans vous soucier des pouvoirs qui lui ont été délégués plus généralement. Pour ordonner à Dsrevoke de ne pas explorer la totalité d’un domaine mais de se concentrer plutôt sur une OU particulière d’un domaine, vous utiliserez l’option /root:ou. L’OU doit être spécifiée en format LDAP (Lightweight Directory Access Protocol).
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
