Archives mensuelles : avril 2015

Powershell DSC: Utilisation d’un module du DSC Resource Kit

Microsoft a publié toute une série de modules utilisables (et modifiables) pour DSC.

Ces modules peuvent être trouvés ici.

L’utilisation de ces modules est très intéressante, car on s’appuie sur l’approche de programmation déclarative. C’est à dire qu’on dit ce qu’on voudrait accompli, mais on ne définit pas comment. Le contraire de l’approche déclarative est l’approche impérative, qui définit le comment ou les étapes nécessaires pour accomplir une tâche.

Par exemple, on peut imaginer la création d’une règle de pare-feu ainsi:

Là on décrit ce qu’on veut dans notre règle, mais on ne dit pas comment l’accomplir. C’est DSC qui sait comment créer une règle de pare-feu.

L’avantage de cette approche est qu’on peut se focaliser sur ce qu’on veut accompli sans se soucier des détails techniques, qui eux, peuvent changer avec le temps.

Donc, on met en place notre configuration, tel qu’on l’a décrit dans les articles précédents, mais on voit qu’il y a un problème.

Sur la machine cible où on veut que cette configuration soit appliquée, on constate qu’elle ne peut pas s’appliquer. L’event log (voir ici pour le troubleshooting), nous montre ceci:

dscmodulenotfound

Si on réfléchi, c’est normal, on fait l’import du module xNetworking afin d’utiliser la ressource xFirewall avec  Import-DSCResource -ModuleName xNetworking, mais la machine cible n’a pas ce module, donc DSC ne peut rien faire.

DSC offre le moyen de distribuer les modules sur les machines cible.

Pour ceci on doit placer le fichier ZIP qu’on a téléchargé ici dans le répertoire DSCService\modules: $env:ProgramFiles\WindowsPowershell\DscService\Modules

On doit également créer le checksum du fichier zip avec la commande: New-DscCheckSum:

DscServiceModules

 

Si jamais vous tombez sur l’erreur de type 4104 qui indique à la fin d’une longue phrase:

File C:\Program Files\WindowsPowerShell\Modules\xNetworking\DscResources\MSFT_xFirewall\MSFT_xFirewall.psm1 cannot be loaded because you opted not to run this software now.

4104

Cet événement veut dire que vous avez essayé de copier les fichier manuellement afin de tester la configuration, et Windows a bloqué le fichier car il pense que le fichier vient d’internet. Pour régler ce problème il suffit d’utiliser la cmdlet Unblock-File. Mais le meilleur moyen de régler ce problème est de laisser DSC s’occuper de la copie des modules ;).

On vérifie que la configuration s’est bien appliquée sur la machine cible:

firewallconfig

 

Vérifions le pare-feu:

firewallrule

Et voilà.

 

Powershell DSC: Troubleshooting et Debugging

Comme tout programme, il est nécessaire d’avoir quelques bases en Powershell DSC pour des séances de debugging et régler d’éventuels problèmes dans ses scripts, ou en tout cas comprendre le cheminement des configurations et savoir détecter si elles ne peuvent pas s’appliquer et pourquoi.

La première chose à faire pour vérifier une configuration c’est de la visualiser avec Get-DSCConfiguration. Si elle n’a pas pu s’appliquer, on verra une erreur de type : Get-DscConfiguration : Current configuration does not exist.

ConfigNotFound

Attention, on peut aussi voir une ancienne configuration établie, et la nouvelle n’est pas visible car elle ne peut s’appliquer.

Lorsque on voit ce cas, on doit regarder l’état du Local Configuration Manager avec la commande: Get-DscLocalConfigurationManager:

LCMPendingState

 

Et ici on voit une chose importante, l’état du LCM (LCMState) est en PendingConfiguration. Ça veut dire que le LCM est en attente d’une configuration et que celle-ci à du mal à s’appliquer.

 

Les valeurs de LCMState sont les suivantes (j’en ai vu 3, peut-être qu’il y en a d’autres):

  • Idle: Le LCM ne fait rien, il attend
  • Busy: Le LCM est en train d’appliquer une configuration.
  • PendingState: Le LCM est bloqué, il sait qu’une configuration est disponible, soit il attend la période de refresh, soit il ne peut pas l’appliquer à cause d’une erreur dans la configuration.

Direction, l’Event Log.

Le log qu’on veut voir se trouve dans:

  • Applications and Services Logs
    • Microsoft
      • Windows
        • Desired State Configuration
          • Operational

EventLogError

 

Et là on voit qu’une ressource de type script appelé TestPorts a un problème. TestPorts est le nom de la ressource Script que j’ai écrit, donc ça me parle, la voici:

Le message d’erreur est : Exception calling « Connect » with « 2 » argument(s): « Cannot access a disposed object.
Object name: ‘System.Net.Sockets.TcpClient’. »

Ça veut dire que j’utilise un objet mal initialisé. La command $socket.close() rend mon objet $socket non-disponible pour une nouvelle connexion.

Je vais modifier mon script pour qu’il n’utilise qu’une seule instance de System.Net.Sockets.TcpClient à chaque fois:

Après avoir réappliqué ma configuration, je vérifie le LCM avec la commande Get-DscConfigurationManager:

LCMIdle

Et on voit que le LCM est passé en mode Idle. Il a du appliquer la configuration, allons vérifier avec Get-DscConfiguration

configOKLa configuration est bien présente, et on voit qu’elle se base sur quatre ressources, dont deux de registre et deux de script.

Tout ça nous montre deux choses intéressantes:

  1. L’automatisation est fantastique, elle nous permet de gérer des centaines voire des milliers de machines comme s’il y en avait qu’une seule. Lorsque je déploie une configuration, je sais que toutes ces machines l’appliqueront et seront exactement les mêmes. Ça veut dire aussi que si je fais une erreur, je peux mettre en carafe toutes ces machines d’un coup. DSC n’est pas le seul à induire un tel risque, les applications telles que SCCM ou Altiris ou même des GPO peuvent avoir les mêmes conséquences.
    Donc il faut un processus de mise en production en béton. Il faut un environnement de Développement et d’Intégration le plus proche de la Production que possible. Voire même un environnement de Pré-Prod, qui sera le dernier rempart de test. Il faudra aussi des processus de test pour valider les configurations avant de les mettre en production.
  2. Les scripts de génération de configurations sont des programmes, et ces programmes ont un cycle de vie, ils peuvent évoluer, des variantes peuvent être créées. Les admins qui utiliseront Powershell DSC doivent se familiariser avec des logiciels de gestion de version tels que SVN ou GIT. Ainsi on pourra développer et distribuer des configurations tout en étant capables de revenir en arrière si besoin.

L’erreur no Runspace available

Lors de l’installation d’un serveur pull sur une nouvelle machine Windows 2012 R2, nous avons eu l’erreur suivante lorsque nous exécutons Get-DscConfiguration:

 

Nous avions pensé tout d’abord à un problème de certificat, car ce problème ne se produit que si nous configurons le PULL serveur avec HTTPS.

La solution à ce problème est de s’assurer que le hotfix KB3000850 est bien installé. On voit tout de suite si ce hotfix n’est pas installé car lors de l’exécution de Get-DscLocalConfigurationManager montre qu’il manque des informations relatives au LCM (LCMstate, LCMCompatibleVersions, LCMVersion).

Faire Get-Hotfix KB3000850 et voir si le KB est bien installé.

Ce KB3000850 en requiert d’autres, avec quelques essais j’ai trouvé que les KB nécéssaires au minimum sont les suivants (avoir une machine complètement à jour est bien mieux bien sur) :

Mise à jour Lien
KB2883200 https://www.microsoft.com/en-us/download/details.aspx?id=40774
KB2884846 https://www.microsoft.com/en-us/download/details.aspx?id=40771
KB2919442 https://www.microsoft.com/en-us/download/details.aspx?id=42153
KB2938439 https://www.microsoft.com/en-us/download/details.aspx?id=42334
KB2954879 https://www.microsoft.com/en-us/download/details.aspx?id=42380
KB2919355 https://www.microsoft.com/en-us/download/details.aspx?id=42334
KB3000850 https://www.microsoft.com/en-us/download/details.aspx?id=44975

Powershell DSC: Le serveur de conformité

Dans les articles précédents, nous avons configuré un serveur Powershell DSC de type PULL. Nous l’avons ensuite sécurisé avec HTTPS pour chiffrer les échanges avec les machines recevant les configurations.

Nous allons maintenant regarder de plus près la deuxième application qui est installée lors de la configuration du serveur PULL:  PSDSCComplianceServer.svc.

Je me suis basé sur un blog de l’équipe Powershell à ce sujet pour comprendre le cheminement des commandes à passer, et j’ai adapté le script fourni avec un output en html (j’utilise beaucoup le HTML pour générer des tableaux de rapports afin des les envoyer par email ou les publier sur un site).

Nous allons utiliser les cmdlets Invoke-WebRequest et ConvertFrom-Json pour récupérer le statut de conformité des machines configurées par notre serveur PULL.

Nous allons ensuite convertir ces informations en format HTML et sauvegarder dans le Path fourni.

Voici le script:

A noter que j’ai eu initialement des erreurs de type Access Denied en essayant d’accéder au serveur. Dans les commentaires du blog mentionné plus haut, un internaute a donné la réponse à ce problème que j’indique ici:

« After some digging I finally discovered that this section is missing in Complience service web.config:
<modules>
<remove name= »WebDAVModule » />
<remove name= »AuthenticationModule » />
<add type= »Microsoft.Powershell.DesiredStateConfiguration.PullServer.AuthenticationPlugin, Microsoft.Powershell.DesiredStateConfiguration.Service » name= »AuthenticationModule » />
</modules>

It should be added under <system.webServer> configuration section. You can check Pull service web.config for example. »

Attention aux guillemets (« ) en copiant le code.

J’ai fait la modification et ça a bien fonctionné, voici le résultat:

DSCcompliance

 

Powershell DSC: Installation d’un serveur Pull avec HTTPS 2/2

Dans l’article précédent, nous avons mis en place Powershell DSC avec un serveur de type PULL afin que les nouveaux systèmes puissent récupérer leurs configurations.

Le service Web fonctionne bien, la génération des configurations se fait sans problème.

Nous allons dans cet article modifier le serveur Web pour qu’il puisse chiffrer les configurations envoyées aux nouveaux systèmes. Pour cela nous allons mettre en place le rôle Active Directory Certificate Services (AD CS) sur le DC actif du domaine ad.local.

Nous démarrons l’outil Server Manager. Puis Add Roles and features. Nous laissons le wizard nous guider jusqu’à la liste des Roles et sélectionnons Certification Authority:

ADCSrole

On le laisse terminer son installation, puis nous continuons sur la configuration post installation.

Lors de cette étape j’ai créé un Root Certificate, puis j’ai exécuté certsrv pour vérifier que mon serveur de certificats était bien configuré et démarré:

certsrv

 

Je me suis ensuite connecté sur mon serveur PULL et j’ai démarré l’application (MMC snap-in) qui gère les certificats locaux. J’ai selectionné Personal, puis right-click All Tasks puis Request New Certificate…

newcert

Une fois le Wizard démarré, nous allons sélectionner le enrollment disponible Active Directory Enrollement Policy:newcert2

Puis nous allons sélectionner PULL Server (J’ai au préalable créé une template de ce nom avec la particularité de pouvoir exporter la clé privée) et clicker sur Enroll:

certsrv2

Vérifions que notre certificat est bien installé:

newcert4Issued to PULL.ad.local et Issued by ad-DC1-CA, qui est notre root CA installé sur DC1. Tout va bien.

Nous allons maintenant chercher l’empreinte digitale (thumbprint), ou la clé publique de notre certificat. Pour cela, un peu de Powershell:

Bingo!

Exécuter (dot-sourcer) $env:programFiles\WindowsPowershell\Modules\xPSDesiredStateConfiguration\Examples\Sample_xDscWebService.ps1 afin de charger la fonction du même nom.

Nous allons tout simplement exécuter Sample_xDscWebService à nouveau en passant comme paramètre le thumbprint du certificat:

puis charger la nouvelle configuration à travers DSC:

ATTENTION: Si vous avez créé les applications Web avec l’exemple utilisant le trafic non-chiffré, il faudra enlever les deux applications, et laisser DSC en créer de nouvelles. Normalement je n’aurais pas du avoir à effectuer cette étape, mais ne voyant pas mes applications utilisant HTTPS arriver, j’ai voulu accélérer un peu le mouvement.

Il ne nous reste plus qu’à modifier le script de découverte de configurations (DiscoverConfiguration.ps1) et modifier la ligne 15 qui contient l’URL et le mode de connexion

Voici le script complet:

J’ai enlevé les fichiers du répertoire c:\temp\dsctest ainsi que la clé de registre, et ils sont bien revenus à leur place.

 

PS. Bien s’assurer que la KB3000850 est bien installé, voir la fin de cet article à ce propos.

 

Powershell DSC: Installation d’un serveur Pull 1/2

Quelques mots sur Powershell DSC

Dans le monde de l’IT nous avons souvent le problème suivant: nous définissons des architectures et des processus d’exploitation de systèmes qui, avec le temps, commencent à varier d’un système à un autre. Les standards initiaux n’étaient valables qu’au début des mises en production, car ils ont évolués, d’autres besoins sont venus se greffer aux prérequis initiaux, et divers groupes d’exploitation les ont appliqués à leur façon. Et petit à petit, les standards et best practice laissent place aux exceptions.

Powershell Desired State Configuration (DSC) permet de garder une complète possession de son parc informatique, en appliquant des standards d’entreprise à travers la programmation de procédures et configurations, de s’assurer qu’ils sont appliqués. Et lorsque ces standards évoluent et que ces configurations sont mis à jour, le parc évolue aussi, le tout avec la stabilité nécessaire à toute Production car lorsque c’est mis en place, ce sont les systèmes qui viennent chercher leurs configurations, et si quelqu’un les modifie, les systèmes reviennent aux configurations définies par DSC. Et ça, mes amis, c’est le Graal de tout Sysadmin.

Powershell DSC est une extension de Powershell qui permet de:

  • Créer des configurations à travers la programmation sous Powershell et en utilisant des standards tels que MOF.
  • Définir des configurations simples comme l’ajout d’un fichier à un endroit donné, ou compliquée, comme l’exécution de scripts si des conditions sont réunies ou gérer des comptes et groupes locaux ou encore changer des clés de registre ou encore configurer des cartes réseau, activer ou désactiver des services, des parefeux, des règles de sécurité… la liste est longue.
  • Appliquer des configurations sur des serveurs ou postes de travail façon ciblée ou générique, soit en poussant ces configurations, soit en faisant en sorte que ces machines viennent chercher leurs configuration sur un serveur dédié. Ceci de façon répétitive.
  • S’assurer que si un serveur change de configuration, il revient à sa configuration initiale.
  • Créer des rapports de conformité.

Dans cet article nous allons voir comment on met en place un serveur qui contiendra toutes les configurations à appliquer à d’autres serveurs.

Nous allons mettre en place le serveur qu’on appelle PULL, y installer Powershell DSC, IIS, et configurer les modules d’extension pour le service Web Pull.

pullserver

Ce serveur sera en relation avec un contrôleur de domaine Active Directory car dans un des exemples il s’y appuiera pour récurer les noms des serveurs existants.

Le serveur Pull aura également un dossier partagé contenant des sources à appliquer aux nouveaux serveurs.

Nous avons ensuite des serveurs fraîchement installés, appelés dans l’exemple DC2 et SERVEUR1.

 Mise en place d’un serveur Pull

Pour démarrer la configuration de ce serveur en serveur Pull pour Powershell DSC, j’ai installé Windows 2012R2 en y ajoutant Powershell DSC comme fonctionnalité Windows:

DSCfeature

A noter qu’en ajoutant Powershell DSC, le serveur ajoute également les composants de IIS.

Récupérer le module de configuration pour DSC.

Extraire ce fichier zip dans $env:programFiles\WindowsPowershell\Modules

 

Vérifier que DSC est bien disponible à travers la commande Get-DSCResource:

 

 

Exécuter $env:programFiles\WindowsPowershell\Modules\xPSDesiredStateConfiguration\Examples\Sample_xDscWebService.ps1 afin de charger la fonction du même nom (bien mettre le point (.) devant pour invoquer le script :

execxDscload

Exécuter Sample_xDscWebService:

La commande crée un fichier mof qui contient toutes les configurations nécessaires pour créer nos services web. A noter que l’exemple s’appuie sur du trafic non chiffré.

Maintenant nous pouvons configurer notre serveur web avec DSC:

Vérification de ce qui s’est produit:

 

Vérifions si l’application web répond:IE

Afin d’utiliser les cmdlets Active Directory, nous devons charger le module servermanager et ajouter la feature RSAT-AD-Powershell. Ceci simplement parce que notre serveur PULL n’est pas un contrôleur de domaine:

 

Génération des configurations pour les nouveaux serveurs

Voici le script pour générer les configurations. Dans l’exemple nous allons:

  • Copier une arborescence de fichiers
  • Modifier une clé de registre

L’exemple va d’abord demander la liste des DCs à Active Directory. Et ensuite compléter cette liste avec un array de nouveaux serveurs. Finalement les configurations de chaque serveur et son checksum seront générés et placés dans le répertoire des configurations de DSC.

L’exemple va également créer un fichier CSV contenant les binômes Nom de serveur et GUID. Ce fichier sera utilisé lors de la découverte par les serveurs de leur propre configuration. DSC saura quelle configuration sera à appliquer à quel serveur.

Exécution du script de découverte des configurations à appliquer

Sur le nouveau serveur, nous allons simplement exécuter un script générique DiscoverConfiguration.ps1.

Voici le script:

Le script configure le Local Configuration Manager avec la règle d’aller chercher les configurations MOF depuis un serveur IIS.

Il indique aussi de vérifier si les configurations existantes sont conformes toutes les 30 mins. Et si c’est pas le cas, de ré-appliquer les configurations.

Voici l’exécution du script:

Vérification du Local Configuration Manager:

A noter que la configuration se mettra en place au bout de 30 minutes comme indiqué, que le mode choisi est ApplyAndAutoCorrect et finalement que la méthode de Refresh se fait à travers un Pull à travers un download sur un service Web.

Voici la clé et les fichiers créés sur le nouveau serveur:

regkey files

J’ai quand même essayé de supprimer les deux fichiers pour voir si DSC allait ré-appliquer la configuration, et 30 minutes plus tard ils ont réapparu. Puissant!

Attention quand même a ne pas mélanger DSC avec d’autres outils de configuration management. Si par exemple une GPO dit « 1 », et que DSC dit « 0 », les deux outils vont se livrer à une bataille sans fin pour appliquer leurs configurations respectives.

La révolution des DevOps a bien commencé.

L’article suivant va modifier le serveur PULL pour utiliser HTTPS et chiffrer ainsi le trafic.

Liens et références:

Article de Bruno Saille sur Technet. Cet article était parmi les plus clairs que j’ai pu lire à propos des serveurs Pull, et a grandement influencé mon article.

Local Configuration Manager

Built-In Windows PowerShell Desired State Configuration Resources