Windows PowerShell

Windows PowerShell 2.0 intègre la génération de scripts à Active Directory, et pas uniquement pour Windows Server 2008

Don Jones

Parfois, Microsoft met un temps incroyable à mettre au point les solutions dont nous avons besoin. Enfin ! Des dizaines de milliers d'employés dans le monde, et toujours aucun « Halo 4 »? Mais il arrive parfois que l'attente soit justifiée par la recherche de la bonne solution et dans le cas de la génération de scripts et de l'automatisation Active Directory, cela valait la peine d'attendre. Windows Server 2008 R2 est fourni avec le module Windows PowerShell 2.0 qui permet la génération de scripts et l'automatisation pour Active Directory.

Configuration requise : Réalités et mythes

Les nouvelles commandes Active Directory pour Windows PowerShell nécessitent Windows PowerShell v2. Les commandes sont distribuées dans un module, ce qui est une nouveauté de la version 2.0, et non sous forme d'un PSSnapin. La distribution de modules est plus simple et ne nécessite ni installation ni inscription. Il suffit de copier ces fichiers dans le dossier Modules du shell et d'utiliser la commande Import-Module pour importer le module dans le shell.

Windows PowerShell 2.0 est préinstallé sur Windows 7 et Windows Server 2008 R2 ; il devrait être disponible pour Windows Server 2008, Windows Vista, Windows XP et Windows Server 2003 vers la fin 2009 ou le début 2010. Le module Active Directory est fourni avec Windows Server 2008 R2, mais vous n'avez absolument pas besoin de disposer de chaque contrôleur de domaine (DC) dans l'environnement qui exécute ce système d'exploitation pour utiliser les commandes. En fait, les commandes fonctionnent très bien avec un DC Windows Server 2003 et un DC Windows Server 2008 (non R2), à condition que vous installiez le service de passerelle de gestion gratuit Active Directory (à télécharger à l'adresse microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008940c6-0296-4597-be3e-1d24c1cf0dda) sur ces DC. C'est au service de passerelle que les commandes Active Directory s'adressent et il peut être installé sur Windows Server 2003 R2 SP2 et versions ultérieures ou sur Windows Server 2008 SP2 et versions ultérieures.

En attendant, l'ordinateur client doit exécuter Windows 7 ou Windows Server 2008 R2, car il n'est actuellement pas possible d'installer le module Active Directory sur une version antérieure.

Authentification

L'authentification est l'une des difficultés d'utilisation d'Active Directory : vous voudrez peut-être gérer un autre domaine que celui auquel vous êtes connecté et vous ne disposez peut-être pas des approbations entre tous les domaines que vous souhaitez gérer. Dans certains cas, vous disposez peut-être des droits administratifs dans un autre domaine, mais uniquement via un autre compte d'utilisateur. Windows PowerShell 2.0 n'intègre aucun mécanisme permettant de conserver toutes ces informations d'identification, et les développeurs du module Active Directory ont dû trouver une technique. Ce qu'ils ont mis au point est aussi élégant que simple : Le module Active Directory inclut un fournisseur Windows PowerShell PSDrive, ce qui signifie que vous pouvez « mapper un lecteur » à un domaine Active Directory. Ce mappage de lecteur contient vos informations d'identification et leur permet d'être conservées pendant toute la durée de votre session shell. Lorsque le module se charge dans le shell, il mappe automatiquement votre domaine de connexion en utilisant les informations d'identification que vous avez utilisées pour exécuter Windows PowerShell 2.0 (attention : le contrôle de compte d'utilisateur étant appliqué, veillez à exécuter le shell en tant qu'administrateur si cela correspond à vos besoins). Pour mapper de nouveaux domaines, utilisez l'applet de commande New-PSDrive, qui prend en charge les paramètres de ligne de commande pour indiquer les informations d'identification.

Pour changer des répertoires en domaine mappé, utilisez la commande Cd habituelle : Cd AD:, par exemple, change l'orientation du shell en domaine mappé par défaut. Changer en domaine est essentiel, car toutes les commandes Active Directory utiliseront, par défaut, les informations d'identification du domaine sur lequel le shell est axé à ce moment-là. C'est vraiment une astuce intéressante que de permettre l'exécution des commandes Active Directory sans devoir indiquer manuellement et systématiquement les informations d'identification. Vous devez exécuter la même commande sur un autre domaine ? Il vous suffit de passer à ce domaine, d'appuyer sur la touche Haut plusieurs fois pour rappeler la commande Active Directory, et d'appuyer sur Entrée pour l'exécuter dans le nouveau domaine.

Les commandes Active Directory ne vous obligent cependant pas à procéder ainsi : chacune d'elles gère également les paramètres de ligne de commande nécessaires permettant d'indiquer les informations d'identification au cas par cas. Vous pouvez ainsi choisir votre méthode de travail, ce qui est un avantage appréciable. L'équipe de produits aurait très bien pu choisir l'une des deux techniques ; le fait qu'ils aient inclus les deux montre qu'ils connaissent bien la diversité des utilisateurs.

Les commandes

En tout, le module Active Directory offre 82 nouvelles commandes au shell, des plus évidentes telles que New-ADUser aux plus obscures comme Install-ADServiceAccount. Tous les applets de commande ont le préfixe « AD », qui remplit deux fonctions importantes. La première permet de distinguer les applets de commande d'autres applets similaires ; New-ADUser crée un nouvel utilisateur Active Directory, pas un nouvel utilisateur local ni un nouvel utilisateur SQL Server ou autre. La deuxième permet de trouver facilement tous les applets de commande : exécutez Help *–AD* et vous obtiendrez la liste des 82 commandes.

Chaque commande Active Directory a des paramètres de ligne de commande, voire de nombreux paramètres dans certains cas. New-ADUser, par exemple, a des milliards de paramètres qui permettent de définir des attributs de répertoire, comme Office, Organization, etc., sans besoin de mémoriser les noms d'attributs de schéma internes (par exemple, j'oublie tout le temps que « Last Name » s'écrit « sn » dans le schéma).

Ce qu'il y a d'ingénieux avec ces commandes c'est qu'elles vous évitent de faire des bêtises. Par exemple, si vous exécutez Get-ADUser, vous vous attendez peut-être à recevoir la liste de tous les utilisateurs du répertoire. Dans un grand domaine, non seulement cela prendrait du temps, mais cela pourrait en plus avoir des conséquences importantes sur votre DC. Pour éviter cela, le paramètre –filter de la commande est obligatoire, ce qui vous oblige à indiquer un point de départ (par exemple une unité d'organisation) ou un autre critère. Bien sûr, la commande ne vous empêchera pas de faire ce que vous souhaitez ; –filter * extraira effectivement tous les utilisateurs du répertoire. Cependant, elle n'extraira pas automatiquement tous les attributs de ces utilisateurs, car, là encore, cela pourrait ralentir le contrôleur de domaine pour un certain temps. D'autres paramètres comme –ResultPageSize, qui permet de spécifier le nombre de résultats à envoyer simultanément, et –Properties, qui permet de spécifier les attributs à extraire, permettent d'affiner l'équilibre entre performances et résultats recherchés.

Vous travaillez à peine, ou tout comme

Je me souviens avec nostalgie, enfin presque, de l'époque ou l'on devait écrire deux douzaines de lignes de VBScript pour créer et remplir un nouvel utilisateur dans Active Directory. Désormais, c'est aussi simple que cela :

PS AD:\> new-aduser -name DonJ -CannotChangePassword $True -Department IT -DisplayName 'Don Jones' -EmployeeNumber 42 -GivenName Don -Office 'Las Vegas' -Organization 'Concentrated Technology' -PasswordneverExpires $True

Voici une astuce : après avoir créé un nouvel utilisateur, vous avez peut-être d'autres choses à faire avec l'objet utilisateur. Si vous ajoutez le commutateur –PassThru à la commande, le nouvel objet utilisateur est dirigé vers le pipeline, où un autre applet de commande peut l'accepter comme entrée. Cela vous permet de procéder, par exemple, comme ceci :

New-ADUser ... -passThru | Set-ADAccountPassword ... -passThru | Enable-ADAccount

Évidemment, j'ai raccourci la syntaxe : « ... » contiendrait tous les paramètres classiques. Cela permet d'illustrer comment –passThru permet de continuer de diriger l'objet utilisateur vers le pipeline afin que d'autres applets de commande puissent l'utiliser. De telles techniques autorisent des instructions d'une ligne extrêmement efficaces, à la place d'un script, moins efficace.

Attendez… Cela devient encore mieux

C'est pour ce qui suit que j'ai dressé un petit autel, là, dans mon bureau, à ceux qui ont écrit ces commandes Active Directory : j'ai découvert un petit miracle appelé liaison de paramètres de pipeline, et ces développeurs l'utilisent à plein. Exécutez Help New-ADUser –full et recherchez l'aide pour chaque paramètre individuellement. Vous noterez qu'un grand nombre de paramètres, ceux qui correspondent aux attributs Active Directory, comme City, Office et Department, acceptent l'entrée pipeline « ByPropertyName ». Ce qui signifie que vous pouvez rediriger l'entrée dans l'applet de commande New-ADUser et que, si votre entrée contient des propriétés qui correspondent au nom du paramètre, la correspondance sera automatique. Ainsi, si votre entrée contient une propriété « City », elle se joindra elle-même au paramètre –City. Si votre entrée a une propriété « Department », elle s'attachera elle-même au paramètre –Department.

Si vous connaissez le fonctionnement de l'applet de commande Import-CSV, alors vous êtes déjà enthousiaste. Imaginez un fichier .CSV qui contient les colonnes suivantes :

"Name","Department","Organization","City"

Chaque ligne du fichier contient les informations correspondant à ces colonnes. Vous pouvez facilement créer cette structure dans Microsoft Office Excel, Microsoft Office Access, Microsoft SQL Server, ou autre, puis exporter vos données au format CSV. Si vous procédez ainsi (et n'oubliez pas de faire correspondre les noms de vos colonnes à ceux des paramètres de New-ADUser), alors vous pouvez créer de nouveaux utilisateurs comme suit :

Import-CSV c:\new-users.csv | New-ADUser

Eh oui, c'est tout ce que vous devez taper. Si votre fichier .CSV contient toutes les colonnes nécessaires - comme Name, si le paramètre –Name est obligatoire - alors New-ADUser connecte comme par magie les colonnes .CSV et les paramètres correspondants. Vous pouvez importer une centaine de nouveaux utilisateurs en quelques secondes, en tapant moins de 50 caractères. Si cela ne vous incite pas à passer à Windows PowerShell 2.0, alors… vous devez réellement être du genre à aimer cliquer sur « Next, Next, Finish ».

Gestion Active Directory, comme il faut

L'un des principes de base de Windows PowerShell est que les programmeurs doivent écrire toutes les fonctionnalités administratives, comme la gestion d'Active Directory, dans les applets de commande shell. Toutes les interfaces graphiques doivent, en somme, être des front-end pour ces applets de commande. Microsoft Exchange Server 2007 a inauguré ce schéma, et cela fonctionne très bien. L'interface graphique est excellente et vous pouvez toujours revenir à la ligne de commande si l'interface ne vous permet pas de procéder exactement comme vous le souhaitez. Alors, les utilisateurs et les ordinateurs Active Directory Microsoft ont-ils été réécrits dans cette optique ?

Eh bien, non. Mais, franchement, l'outil n'est pas tout neuf. Cependant, Windows Server 2008 R2 propose une autre fonctionnalité innovante, le Centre d'administration Active Directory, une toute nouvelle interface qui permet de gérer Active Directory. Et devinez ce qui se cache sous le centre d'administration ? Oui, les fameux applets de commande Active Directory. Cela signifie que vous pouvez faire à partir du shell tout ce que vous faites dans l'interface et que vous pouvez confier à un script shell toutes les tâches répétitives ou ennuyeuses.

Presque dix ans plus tard, Active Directory connaît vraiment le succès. Nous avons désormais le choix entre la gestion simple et intuitive via une interface et une administration puissante et automatisée via une ligne de commande élaborée, dont l'utilisation n'est, franchement, pas bien plus compliquée que celle de l'interface. Inutile d'attendre Windows Server 2008 R2, car avec le module complémentaire adapté vos domaines Windows Server 2003 peuvent bénéficier de la même simplicité de gestion.

 

Don Jones est l'un des formateurs et des rédacteurs Windows PowerShell les plus expérimentés du pays. Il rédige toutes les semaines des astuces sur Windows PowerShell sur le blog à l'adresse ConcentratedTech.com et vous pouvez également le contacter ou lui poser des questions ici.