PowerShell et ASP.NET part 3

Nous voici rendu à la troisième et dernière partie de ce petit tutorial sur PowerShell et ASP.NET

Nous allons voir ici comment piloter un script depuis un formulaire web, et comment déployer ce site sur un serveur IIS convenablement.

Piloter un script

Nous avons vu précédemment comment exécuter du code PowerShell à partir d'une Textbox. Voyons maintenant comment nous pouvons piloter un script en modifiant ces paramètres à la volée.

Ceci est pratique quand vous voulez par exemple faire un portail de provisioning ou d'audit. Plutôt que de proposer à l'utilisateur de taper du code PowerShell, vous pouvez plutôt proposer un formulaire qui va se charger d'exécuter un script avec des paramètres.

Pour illuster ceci, voici un exemple de recherche d'information avec WMI qui peut prendre en argument un nom de machine. j'ai légèrement modifié notre exemple de départ en rajoutant une petite Textbox qui va prendre ce nom de machine :

Voyons maintenant ce qui change côté code. En fait, très peu de chose : Nous allons à présent lire un script incorporé au site web, modifier le contenu et l'exécuter.

Voici le script ajouté au projet :

$strComputer = "*ComputerName*"

get-wmiobject -class "Win32_LogicalDisk" -namespace "root\cimv2" -computername $strComputer where{$_.DriveType –eq 3}out-string

Un script très classique de requête WMI. Comme vous pouvez le voir, j'ai mis le nom de machine en argument. J'ai mis une référence arbitraire de nom "*ComputerName*", qui va me servir pour remplacer cette valeur de variable par le contenu de la TextBox du formulaire.

Voyons le changement opéré dans le code :

        // On the fly script modification before execution

        StreamReader objReader = new StreamReader(Server.MapPath("~/scripts/WmiAsset.ps1"));

        string strContent = objReader.ReadToEnd();

        strContent = strContent.Replace("*ComputerName*", TxtComputerName.Text);

        this.executePowerShellCode(strContent);

Première chose, nous allons lire le fichier contenant le code de notre script. Je l'ai rangé dans un sous-répertoire nommé "scripts", et on utilise simplement à nouveau la librairie system.IO

StreamReader objReader = new StreamReader(Server.MapPath("~/scripts/WmiAsset.ps1"));

Ensuite nous allons mettre l'intégralité du contenu dans une variable, et fermer l'objet StreamReader qui ne nous servira plus :

string strContent = objReader.ReadToEnd();

Ensuite nous utilisons simplement la méthode replace sur cette string, en changeant le code avec le contenu de notre Textbox qui contient le nom de machine.

strContent = strContent.Replace("*ComputerName*", TxtComputerName.Text);

C'est pour ça qu'il est important que le contenu de la variable modifiée soit unique (ici *ComputerName*). Comme vous avez la maitrise du code PowerShell utilisé, ceci est normalement facile à obtenir.

Voilà qui est fait, il ne nous reste plus qu'à exécuter le code comme dans l'exemple précédent.

this.executePowerShellCode(strContent);

Et voilà, rien de bien compliqué si vous avez saisi les précédentes parties. L'intérêt ici est qu'il suffit, en cas de modification de la requête à effectuer, d'aller simplement modifier le fichier .PS1 du répertoire script sur le serveur web, sans avoir à lancer un éditeur C#/ASP.NET.

Vous pouvez bien sûr mettre plusieurs paramètres dans le formulaire. Il reste des choses importantes à implémenter pour une gestion "pro" (prise en compte des erreurs de scripts PowerShell, gestion plus poussé des modes de sorties de script, un contrôle plus adapté que la Textbox pour le suivi des sorties de scripts, etc...) mais vous avez maintenant les bases pour vous lancer, et surtout je l'espère une meilleure compréhension du principe d'interaction envisageable entre le monde web et le scripting PowerShell.

Voyons a présent comment déployer ce portail sur un serveur IIS.

Déploiement du site web

L'intérêt de notre configuration est de pouvoir utiliser un compte de service pour l'exécution des tâches (en l'occurence, l'exécution de nos scripts). Cela simplifie la définition des droits et le modèle de délégation, car il n'est plus nécessaire de donner des droits administratifs spécifiques à chaque utilisateur.

Nous avons néanmoins le besoin de connaitre l'identité de l'utilisateur à l'origine de l'exécution d'une commande afin de se conformer au pré-requis de sécurité sur la production.

La stratégie pour votre déploiement côté IIS doit donc être la suivante :

Tout d'abord filtrer l'accès au site. Pour cela, il suffit simplement de définir des droits appropriés côté NTFS sur l'emplacement de publication. L'idéal étant de définir un groupe d'accès auquel vous donner les droits de lecture sur le site (côte NTFS), et de rajouter les membres adéquats.

Côté IIS, il suffit de faire une publication classique, en désactivant l'accès "anonymous" au site web, et de sélectionner "Integrated Windows Authentification"

Ensuite, il faut définir un application pool pour déléguer l'exécution du code à un compte de service. Pour cela, créer un nouvel application pool, ouvrez ses propriétés et définissez l'Identité dans l'onget approprié.

Il ne vous reste plus qu'à définir cet application pool dans votre site web :

Modifiez enfin votre web.config pour prendre en charge l'impersonalisation.

Vous devez avoir la ligne "authentication mode", rajoutez en dessous le code suivant :

        <authentication mode="Windows"/>

    <identity impersonate="true"/>

Et voilà, votre site est maintenant prêt pour l'impersonalisation, et l'accès est filtré par les droits NTFS.

En espérant que ce petit tutorial vous aura donner quelques idées, je reviendrai très prochainement sur un concept un peu plus poussé de portail web combinant ASP.NET 3.5, PowerShell, AJAX et Silverlight !

Voici la source de l'exemple de cette partie PowerShellASP2