Windows PowerShellAutomatisation de la gestion d'annuaire

Don Jones

L'un des choses les plus regrettables concernant la première version de Windows PowerShell touche au moment de sa publication. L'équipe Windows PowerShell faisait l'objet d'une pression importante pour la livraison du produit (un petit produit nommé Exchange Server 2007 allait sortir et dépendait de Windows PowerShell) et l'équipe

Active Directory avait beaucoup à faire à l'époque (un autre petit produit nommé Windows Server® 2008 était également en développement). Windows PowerShell a donc été livré avec des fonctions de gestion d'Active Directory® moins qu'excellentes.

Pour être honnête, Windows PowerShell® ne manque pas complètement de fonctionnalités Active Directory. En fait, l'équipe Windows PowerShell a consenti des efforts héroïques de dernière minute pour inclure une prise en charge correcte de l'interface ADSI (Active Directory Services Interface), une technologie adaptée à l'écriture de scripts bien connue des utilisateurs de VBScript.

La méthode ADSI

Le mode de fonctionnement d'ADSI est similaire à celui de Windows® Management Instrumentation (WMI). Vous émettez une requête, qui est écrite à l'aide d'une syntaxe spéciale. La requête est transmise à un ordinateur distant (tel qu'un contrôleur de domaine) puis exécutée. Le résultat de la requête est un objet ou une collection d'objets Active Directory (tel qu'un utilisateur ou un groupe) et vous obtenez une référence à cet objet avec laquelle vous pouvez ensuite travailler. Vous pouvez modifier les propriétés de l'objet ou exécuter des méthodes pour enregistrer vos modifications, créer de nouveaux objets, supprimer des objets, etc. Par exemple, pour créer un utilisateur, vous envoyez une requête à l'unité d'organisation (UO) ou au conteneur dans lesquels vous voulez que l'utilisateur soit hébergé. L'objet que vous recevez possède une méthode Create qui peut être utilisée pour créer l'utilisateur.

À un niveau très rudimentaire, l'utilisation d'ADSI dans Windows PowerShell paraît simple et directe. Par exemple, la commande suivante récupérera un utilisateur et affichera son attribut Company :

$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")

Vous pouvez rediriger l'utilisateur vers Get-Member pour voir ses propriétés et ses méthodes. Malheureusement, Windows PowerShell 1.0 n'est pas très doué pour l'implémentation de ces objets d'annuaire. Comme l'illustre la figure 1, l'interpréteur de commandes n'énumère pas les attributs d'annuaire de l'objet et n'affiche pas non plus les méthodes de l'objet, telles que la méthode Get que j'ai utilisée.

Figure 1 Redirection de l'utilisateur vers Get-Member pour voir ses propriétés

Figure 1** Redirection de l'utilisateur vers Get-Member pour voir ses propriétés **(Cliquer sur l'image pour l'agrandir)

Cette prise en charge s'est quelque peu améliorée dans la version CTP (Community Technology Preview) de Windows PowerShell 2.0, mais seulement de façon limitée. Le problème principal réside dans le fait que l'infrastructure Microsoft® .NET Framework sous-jacente n'aide pas les administrateurs à voir ce qu'ils veulent, probablement parce qu'elle a au départ été conçue pour les développeurs. L'autre problème est que l'équipe Windows PowerShell ne peut pas tout faire et qu'une bonne prise en charge d'Active Directory doit venir des personnes qui connaissent le mieux les annuaires. En d'autres termes, l'équipe Active Directory. Je suis sûr que cela arrivera avec le temps ; après tout Windows PowerShell est encore assez récent. Mais que faire entre-temps ?

Vous vous rappelez peut-être que j'ai abordé l'utilisation des technologies ADSI incluses dans Windows PowerShell dans cette rubrique en juin 2007 (technetmagazine.com/issues/2007/06/PowerShell). Je vous suggère de revenir en arrière et de lire cet article si vous recherchez plus de détails sur cette technique « native ». Ce mois-ci, je souhaite vous montrer quelques autres approches.

Un écosystème riche

L'architecte Windows PowerShell Jeffrey Snover fait souvent référence à l'écosystème riche qui entoure Windows PowerShell. Cela signifie simplement que l'équipe a réussi à s'assurer que tout le monde et non uniquement les programmeurs de Microsoft, peut étendre les fonctionnalités de Windows PowerShell. Plusieurs entreprises le font déjà en créant des applets de commande Windows PowerShell natives qui vous permettent d'administrer leurs produits à partir de la ligne de commande. VMWare, IBM, Citrix et Foundry ne sont que quelques-unes de ces grandes entreprises.

L'un de mes exemples préférés de cet écosystème riche provient de Quest Software. Cette société propose un jeu d'applets de commande gratuites, non commerciales, conçues pour l'administration d'Active Directory. Vous pouvez les télécharger depuis quest.com/powershell. Elle propose également PowerGUI (powergui.org), une interface utilisateur graphique non commerciale, s'appuyant sur Windows PowerShell pour les gens qui ne souhaitent pas encore se lancer dans un environnement avec ligne de commande uniquement. PowerGUI peut faciliter l'apprentissage de l'utilisation des applets de commande Active Directory. Et croyez-moi, vous voudrez les utiliser. Ces applets de commande vous offrent une facilité et une puissance de gestion d'Active Directory tout simplement incomparable. (Si vous voulez en lire davantage sur PowerGUI, il était inclus dans la rubrique Boîte à outils de janvier 2008, que vous trouverez à l'adresse technetmagazine.com/issues/2008/01/Toolbox.)

La méthode Windows PowerShell

Tout ce qui a trait aux applets de commande correspond véritablement à la méthode Windows PowerShell. Vous n'aurez pas à vous soucier de scripts d'aspect traditionnel ou d'objets de programmation spéciaux. Voici ma commande uniligne favorite de cet univers. Il s'agit d'une ligne de commande unique qui importe un fichier CSV et utilise les informations qu'il contient pour créer des dizaines, voire des centaines, de nouveaux utilisateurs Active Directory :

Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name') 
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department} 

Il s'agit certes d'une commande longue, mais extrêmement puissante. Elle commence par Import-CSV, une applet de commande native de l'interpréteur de commandes qui lit simplement un fichier CSV et renvoie des objets. Chaque ligne du fichier CSV est un objet unique et les colonnes du fichier CSV deviennent des propriétés de l'objet. Dans mon fichier Provision1.csv, les noms de colonne sont des choses telles que « Logon Name » (Nom de connexion) et « Firstname » (Prénom). Ceci est intéressant car les noms de colonne ne sont pas directement mappés à des attributs d'utilisateur Active Directory. J'ai trouvé qu'il était courant pour les fichiers tels que celui-ci d'utiliser des noms de colonne familiers au lieu de noms spécifiques à Active Directory. Après tout, vous pourriez recevoir ce fichier d'un membre du service du personnel de votre entreprise, et il est peu probable qu'il sache que le nom correspond en fait à l'attribut sn dans Active Directory.

Une fois toutes les données du fichier CSV importées et converties en objets, ces objets sont redirigés vers l'applet de commande ForEach-Object, qui exécute un bloc de code (entre accolades dans ma ligne de commande) pour chaque objet. C'est-à-dire que ce script s'exécutera une fois pour chaque ligne du fichier CSV. Dans le script, la variable spéciale $_ est une référence à l'objet actuel, autrement dit la ligne actuelle du fichier CSV.

Vous pouvez voir que pour chaque objet, j'exécute l'applet de commande New-QADUser. Il s'agit de l'une des dizaines d'applets de commande du complément de Quest. Il est important de noter le nom QADUser. Le Q, comme vous pouvez le deviner, correspond à Quest. Cette convention de dénomination est conçue pour éviter un conflit avec l'applet de commande New-ADUser que l'équipe Active Directory de Microsoft créera probablement un jour. Ainsi, si les deux applets de commande sont chargées dans l'interpréteur de commandes en même temps, l'interpréteur de commandes, comme vous, pourra facilement distinguer l'une de l'autre.

Le reste de la commande est composé de paramètres pour l'applet de commande New-QADUser. Cela commence par la spécification d'organizationalUnit, qui est l'emplacement dans lequel vous voulez que tous les nouveaux utilisateurs soient créés. Vient ensuite l'attribut name, que j'ai défini comme étant le contenu de la colonne First Name (Prénom), un point, puis le contenu de la colonne Last Name (Nom).

Un dernier fait intéressant ici : le paramètre city (ville) modifiera en fait l'attribut l (Locality-Name, nom de la localité) dans Active Directory. L'applet de commande accepte également un paramètre nommé l, qui fait la même chose. Pour la plupart, les paramètres qui font référence à des attributs Active Directory peuvent utiliser le nom d'attribut ou le libellé de texte de l'outil Utilisateurs & ordinateurs Active Directory.

L'autre méthode Windows PowerShell

Active Directory est un magasin hiérarchique et l'un des points forts de Windows PowerShell est sa capacité à exposer tout magasin hiérarchique en tant que lecteur de disque, vous permettant ainsi d'utiliser un jeu familier de commandes telles que Dir, Del, Ren, Copy, etc. pour gérer une variété de magasins. Malheureusement, Windows PowerShell 1.0 n'a pas été livré avec un fournisseur PSDrive pour Active Directory, ce qui signifie que l'interpréteur de commandes ne dispose d'aucun moyen d'exposer Active Directory en tant que lecteur.

Heureusement, l'écosystème riche vient à nouveau à notre secours sous la forme de PowerShell Community Extensions. Il s'agit d'un complément Open Source gratuit disponible sur codeplex.com/powershellcx. Une fois installé, PowerShell Community Extensions vous permet de diriger simplement l'interpréteur de commandes vers votre nom de domaine pour commencer à gérer l'annuaire comme s'il s'agissait d'un lecteur :

CD COMPANY:
CD SINGERS
DIR

Ces commandes basculeront vers le domaine COMPANY, l'UO Singers et afficheront ensuite une liste d'objets, comme illustré à la figure 2. À partir de là, je peux utiliser des commandes telles que Del pour supprimer un utilisateur, Md pour créer une nouvelle UO, etc. Le fournisseur PSDrive de Community Extensions présente quelques spécificités. Celles-ci ont essentiellement trait à des fonctionnalités dont vous pourriez penser qu'elles ont déjà été implémentées, mais qui ne sont pas disponibles parce que les éléments ne correspondent pas à la façon dont Active Directory fonctionne. Vous devez en outre être extrêmement prudent : le basculement vers la racine de votre domaine suivi de l'exécution de del * -recurse supprimera en fait tout objet du domaine, dans la mesure où vous disposez des autorisations nécessaires. Par défaut, il ne vous sera même pas demandé de confirmation. Oui, la ligne de commande est puissante et cette puissance s'accompagne de risques pour ceux qui ne sont pas compétents et prudents.

Figure 2 Utilisation de PowerShell Community Extensions pour diriger l'interpréteur de commandes et gérer l'annuaire

Figure 2** Utilisation de PowerShell Community Extensions pour diriger l'interpréteur de commandes et gérer l'annuaire **(Cliquer sur l'image pour l'agrandir)

Commencez à utiliser Power Shell dès aujourd'hui

Les élèves de mes cours me demandent toujours ce qu'ils peuvent faire avec Windows PowerShell dès maintenant. Après tout, tous les produits Microsoft n'ont pas été reconçus pour utiliser Windows PowerShell et, sans préparation, vous pourriez penser que Windows PowerShell attend toujours que les choses deviennent véritablement intéressantes.

En fait, les choses sont déjà intéressantes. Bien que Microsoft n'ait pas encore équipé Active Directory pour la gestion à partir de la ligne de commande, d'autres s'y sont attaqués et ont tout à fait réussi. Vous pouvez utiliser Windows PowerShell pour exécuter de nombreuses tâches administratives, y compris l'automatisation de certaines tâches parmi les plus longues et ardues, comme la création de lots de nouveaux utilisateurs. Il suffit de découvrir les choses que fait la communauté pour rendre Windows PowerShell plus utile dès maintenant. (Vous pouvez explorer PowerShellCommunity.org, un site coparrainé par Microsoft que j'aide à administrer) Une fois les outils appropriés chargés dans Windows PowerShell, vous pouvez commencer à écrire des scripts pour certaines des tâches administratives les plus laborieuses dont vous ne souhaitez pas vous soucier, et commencer à devenir un administrateur plus efficace et productif.

Don Jones est coauteur de Windows PowerShell: TFM, 2nd Edition, auteur de VBScript, WMI, and ADSI Unleashed, et directeur de PowerShellCommunity.org.

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