Windows PowerShellAutorisations dans l'interpréteur de commandes
Don Jones
Télécharger le code de cet article: PowerShell2008_02.exe (151KB)
Lorsque je parle de Windows PowerShell, on me pose souvent des questions sur les autorisations, et on me demande en particulier l'interpréteur de commandes permet d'automatiser les modifications d'autorisations. Les questions sur les autorisations de fichiers sont peut-être les plus courantes, bien que celles concernant les autorisations d'annuaire et du Registre soient également nombreuses. S'agissant des autorisations et de pratiquement
toute interface de ligne de commande ou de script (y compris Windows PowerShellTM et VBScript), j'ai une bonne et une mauvaise nouvelle à vous annoncer.
La mauvaise nouvelle est que les autorisations dans Windows® sont tout simplement compliquées, et Windows PowerShell ne peut pas faire grand chose pour y remédier. Le problème vient du fait que sur un système d'exploitation Windows, il existe plusieurs objets liés aux autorisations, que vous examiniez le système de fichiers, Active Directory®, le Registre ou pratiquement n'importe quel autre emplacement.
Tout d'abord, il y a la ressource elle-même, par exemple, un objet d'annuaire, un fichier ou un dossier. Ensuite, il y a l'objet Liste de contrôle d'accès (ACL) qui est associé à la ressource. L'ACL consiste en une ou plusieurs entrées de contrôle d'accès, ou objets ACE. Un ACE relie essentiellement une entité de sécurité (un utilisateur ou un groupe, qui représente un objet de plus) à une autorisation (telle que Lecture ou Contrôle total) et un état Accorder ou Refuser. Nous parlons ici de pas moins de cinq objets : la ressource, l'ACL, un ACE, une entité et une autorisation.
Les autorisations sont encore compliquées par le fait que chaque type de ressource possède des types d'autorisations différents. Les objets d’annuaire, par exemple, ont des autorisations complexes qui régissent l'accès aux attributs des objets individuels. Les autorisations de fichier sont relativement peu compliquées en comparaison.
Et, techniquement, tout ceci est multiplié par deux lorsqu'il s'agit d'effectuer un audit. Chaque ressource possède en fait deux ACL. Il y a tout d'abord la Liste de contrôle d'accès discrétionnaire (DACL) qui gère l'accès à la ressource. Ensuite, il y a une Liste de contrôle d'accès système (SACL) qui contrôle l'audit de la ressource. Pour utiliser ces autorisations, vous devez littéralement vous frayer un chemin à travers tout un tas d'objets de programmation compliqués, et un interpréteur de commandes comme Windows PowerShell ne peut pas faire grand chose pour vous simplifier la tâche.
Limité par .NET Framework
Plus d'infos ?
Pour obtenir plus de ressources Windows PowerShell, notamment une bibliothèque d'applets de commandes pouvant faire l'objet d'une recherche, et pour entrer en contact avec Don Jones et d'autres experts Windows PowerShell, rendez-vous sur le site www.PowerShellCommunity.org.
La nature de Windows PowerShell rend les choses un peu plus compliquées. Étant construit sur Microsoft® .NET Framework, Windows PowerShell utilise les classes sous-jacentes de .NET Framework pour représenter et utiliser les autorisations. Ces classes .NET Framework sous-jacentes sont conçues pour offrir aux développeurs de logiciels un contrôle granulaire et précis des autorisations. Bien sûr, « granulaire et précis » signifie beaucoup de choses et se traduit souvent par « très compliqué ».
De plus, .NET Framework ne fournit pas de classes représentant les autorisations dans chaque type de ressource Windows. Par exemple, bien que .NET Framework vous propose des classes qui vous permettent de manipuler la sécurité des fichiers, il ne fournit pas de classe qui vous permette de manipuler la sécurité sur les dossiers partagés. Il en résulte que Windows PowerShell ne peut pas manipuler les autorisations sur tous les types de ressources Windows. En résumé, Windows PowerShell est limité aux fonctionnalités exposées par .NET Framework.
Autorisations dans l'interpréteur de commandes
La gestion des autorisations dans Windows PowerShell est dérivée de deux applets de commande : Get-ACL et Set-ACL. Comme vous pouvez le deviner, Get-ACL récupère l'ACL d'une ressource. Vous pouvez ensuite modifier l'ACL en fonction de vos besoins et utiliser Set-ACL pour le réintégrer à la ressource. Ces applets de commande sont toutes deux génériques et s'appuient sur le système Windows PowerShell de fournisseurs PSDrive. Ainsi, ces deux applets de commande ACL peuvent théoriquement fonctionner avec n'importe quel type de ressource, à condition qu'il y ait un fournisseur PSDrive capable de comprendre un type de ressource donné et de modifier les autorisations sur ce type de ressource. Les fournisseurs FileSystem et Registry PSDrive, qui sont inclus avec Windows PowerShell, prennent en charge la gestion des autorisations via les deux applets de commande ACL. (Il est possible que les autres fournisseurs PSDrive ne prennent pas en charge cette opération).
L'exemple de script illustré à la figure 1 vous permet de spécifier un répertoire de démarrage, une entité de sécurité et une autorisation. Le script applique ensuite l'autorisation que vous avez spécifiée pour cette entité à tous les fichiers et dossiers se trouvant dans le répertoire spécifié. Le script lit également les sous-répertoires de façon récursive.
Figure 1 Appliquer une autorisation pour une entité aux fichiers et dossiers d'un répertoire
#ChangeACL.ps1
$Right="FullControl"
#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl
$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"
#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")
foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
$acl=get-acl $file.FullName
#Add this access rule to the ACL
$acl.SetAccessRule($rule)
#Write the changes to the object
set-acl $File.Fullname $acl
}
La fonction la plus importante de ce script se situe là où il définit une nouvelle règle d'accès dans la variable $rule. Pour ce faire, j'utilise une classe .NET Framework « brute », ce qui est peut-être la partie la plus compliquée de la gestion des autorisations sous Windows PowerShell. Le script récupère ensuite l'ACL de chaque fichier et dossier à tour de rôle en utilisant Get-ACL, applique la nouvelle règle en utilisant la méthode SetAccessRule de l'ACL et réintègre l'ACL modifiée dans la ressource à l'aide de Set-ACL.
En réalité, ceci n'est pas très compliqué, bien que des opérations plus complexes telles que la suppression d'un ACE d'une ACL soient impliquées. À mon avis, ce qui complique le processus, c'est le fait que qu'il comporte de nombreuses étapes : obtenir l'ACL, définir une règle, modifier l'ACL et écrire l'ACL. Il ne s'agit pas d'une commande unique propre qui fait tout d'un seul coup. Et puisque je voulais modifier les ACL sur plusieurs fichiers, j'ai dû tout encapsuler dans une boucle Foreach, en utilisant Get-ChildItem pour accéder à tous les fichiers et dossiers.
J'opterai pour la solution la plus simple
Applet de commande du mois : Get-QADUser
Cette applet de commande est un must si vous gérez Active Directory. Elle n'est pas intégrée à Windows PowerShell, mais elle est disponible sous forme de téléchargement gratuit inclus dans Management Shell for Active Directory de Quest Software (www.quest.com/activeroles-server/arms.aspx).
Une fois le composant logiciel enfichable installé, vous pouvez utiliser Get-QADUser pour récupérer des objets utilisateur du répertoire. Bien sûr, le fait d'exécuter l'applet de commande ne fait que renvoyer tous vos utilisateurs, ce qui n'est pas très utile dans la plupart des tâches administratives. Toutefois cette applet de commande vous permet de spécifier des critères de filtrage qui sont appliqués au contrôleur de domaine de sorte que seuls les utilisateurs qui vous intéressent soient renvoyés à Windows PowerShell. Cette technique est beaucoup plus rapide que celle qui consiste à d'abord obtenir tous les utilisateurs puis à les filtrer avec l'applet de commande Where-Object. Par exemple, Get-QADUser -l Redmond renverra uniquement les utilisateurs dont l'attribut « l » contient « Redmond ». (L'attribut « l », au fait, représente la localité et est indiqué comme une ville dans la GUI). Vous pouvez ensuite canaliser ces utilisateurs vers d'autres applets de commande afin de créer un rapport HTML, les placer dans un groupe ou même les supprimer.
Je ne trouve pas mon exemple très complexe, mais je sais que beaucoup d'administrateurs préfèrent une façon plus simple de gérer les autorisations. Certains voudraient peut-être supprimer d'un seul coup un groupe d'utilisateurs particulier d'une série de dossiers, mais ils ne souhaitent pas écrire un script de plusieurs étapes comme celui de la figure 1.
Fort heureusement, Windows PowerShell propose une méthode de gestion des autorisations simplifiée, et vous la connaissez probablement déjà.
Windows PowerShell ne vous oblige pas à renoncer à toutes les méthodes de gestion familières et fiables. Vous pouvez continuer d'utiliser des outils de ligne de commande tels que Dsacls.exe, Cacls.exe et Xcacls.exe qui ont été spécialement conçus pour vous permettre de gérer les divers types d'autorisations en toute simplicité. Bien que leur syntaxe soit complètement différente de la syntaxe normalisée utilisée par les applets de commande de Windows PowerShell, ces utilitaires de ligne de commande n'ont plus besoin d'être utilisés d'une manière ad hoc à la ligne de commande comme ils l'étaient dans l'ancien interpréteur de commandes cmd.exe. De plus, vous pouvez utiliser Windows PowerShell pour automatiser ces utilitaires.
J'ai rencontré des personnes (je dirai des « puristes ») qui prétendent que ceux qui utilisent un utilitaire de ligne de commande ancienne génération dans Windows PowerShell ont tort. Je ne suis pas tout à fait sûr de comprendre leur logique. Je suis entièrement d'accord avec ceux qui pensent qu'il est important de mener à bien une tâche, et si le moyen le plus facile de le faire est d'utiliser un utilitaire de ligne de commande vieux de 10 ans, je suis tout à fait pour. Je n'ai surtout pas envie de passer des heures interminables à essayer de faire les choses d'une autre manière parce que c'est « plus pur ». Et l'équipe Windows PowerShell de Microsoft pense comme moi. Si un outil existant vous aide à faire votre travail, Windows PowerShell vous laisse l'utiliser dans l'interpréteur de commandes. Pourquoi réinventer la roue ?
La figure 2 illustre un bref script, extrait de mon livre Windows PowerShell : TFM (SAPIEN Press, 2006), qui utilise Windows PowerShell pour automatiser Cacls.exe. Ce script n'est qu'une démonstration, ce qui signifie que vous devez l'ajuster si vous voulez en faire un véritable outil d'automatisation. Il vous montre, cependant, comment un script Windows PowerShell peut recueillir des informations et les utiliser pour lancer Cacls.exe, comme si Cacls.exe était une commande Windows PowerShell « native ». (Bien que ce script recueille des informations en invitant l'utilisateur à les lui fournir, il peut également lire les paramètres d'un fichier ou d'une base de données).
Figure 2 Automatiser Cacls.exe
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write
$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
"F" {$Null}
"C" {$Null}
"R" {$Null}
"W" {$Null}
default {
Write-Host -foregroundcolor "Red" `
`n $Right.ToUpper() " is an invalid choice. Please Try again."`n
exit
}
}
$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"
$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"
if ($Verify -eq "Y") {
foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
#display filename and old permissions
write-Host -foregroundcolor Yellow $file.FullName
#uncomment if you want to see old permissions
#CACLS $file.FullName
#ADD new permission with CACLS
CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL
#display new permissions
Write-Host -foregroundcolor Green "New Permissions"
CACLS $file.FullName
}
}
Du succès avec les autorisations ?
J'ai entendu dire que Windows PowerShell n'était pas très pratique pour l'administration des autorisations parce qu'il ne proposait pas d'applet de commande native capable d'offrir une gestion des autorisations simplifiée et universelle. Je ne suis pas d'accord. Tout d'abord, cet argument est souvent avancé par des administrateurs spécialistes d'UNIX, et le fait est que le système d'autorisations de Windows est infiniment plus complexe que celui utilisé par UNIX. En exposant ce système, Windows PowerShell sera également compliqué. Ce problème ne provient toutefois pas de Windows PowerShell.
En outre, Windows PowerShell vous permet d'utiliser des outils simplifiés sous forme de bons vieux utilitaires de ligne de commande, comme je l'ai montré dans cet article. Il est vrai que .NET Framework doit être quelque peu étendu de sorte à couvrir d'une manière plus complète la gestion des autorisations à l'échelle de la plate-forme Windows, mais en général, Windows PowerShell vous offre le meilleur des deux mondes : une gestion des autorisations simplifiée et l'accès à des outils de gestion granuleux et précis.
Don Jones contribue à l'élaboration de TechNet Magazine et est co-auteur de Windows PowerShell: TFM (SAPIEN Press, 2007). Il enseigne Windows PowerShell (voir www.ScriptingTraining.com) et peut être contacté par le biais du site Web www.ScriptingAnswers.com
© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.