Études de cas

1. Problématique

Il existe bien souvent un grand nombre de comptes d’ordinateurs inutiles qui sont présents dans le service d’annuaire Active Directory. La raison est simple : dans bien des entreprises, il manque une procédure de mise au rebut du matériel, ou si elle existe pour la gestion du matériel physique rien n’est prévu en revanche pour supprimer les comptes d’ordinateurs. Ainsi au bout de quelques années, il n’est pas rare d’avoir 50 % de comptes machine en trop. Par conséquent, il peut devenir difficile pour un administrateur de bien gérer son parc de machines. Pour tenter de remettre un peu d’ordre dans l’AD DS, nous allons développer un script qui se connectera sur un contrôleur de domaine et récupérera la liste des comptes machine. Pour chaque compte machine, nous regarderons quelle a été la date de dernier logon ou autrement dit la date de dernière ouverture de session. Car oui, même les comptes machine ouvrent des sessions ! Un compte machine ouvre une session sur un domaine en s’authentifiant auprès d’un contrôleur de domaine, tout comme un utilisateur. À la différence près que les mots de passe des comptes d’ordinateurs s’autogèrent.

Un mot de passe est généré aléatoirement la première fois lorsqu’un ordinateur adhère...

1. Problématique

Le constat est assez similaire aux comptes machines : les administrateurs sont toujours au courant dès lors qu’il s’agit de créer un compte utilisateur mais jamais lorsqu’il s’agit de le fermer. Cela entraîne forcément des dérives qui peuvent finir par coûter cher. En effet, le nombre d’objets dans l’annuaire Active Directory Domain Services ne cesse de croître et des ressources restent monopolisées pour rien (espace disque hébergeant les « home directories », boîtes aux lettres, etc.).

D’autre part, une mauvaise gestion des comptes utilisateurs peut causer des problèmes de sécurité car nous savons tous qu’un mot de passe qui ne change pas peut facilement se faire « casser »...

2. Solution : faire du ménage !

Faire du ménage, l’intention est louable mais sans script point de salut ! Dans l’étude de cas précédente, nous avons focalisé notre attention sur les comptes d’ordinateurs. Eh bien sachez que la gestion des comptes utilisateurs s’effectue sur le même principe, et nos explications autour des attributs LastLogon et LastLogonTimeStamp restent vraies. À savoir que l’attribut LastLogon n’est pas répliqué entre les contrôleurs de domaine et que LastLogonTimeStamp l’est mais se met à jour que tous les quatorze jours environ. Pour nous simplifier la vie, comme pour les comptes machines, nous nous contenterons d’utiliser LastLogonTimeStamp ; nous pourrons donc avoir au pire des cas une différence maximum de quatorze jours par rapport à la réalité du terrain. Mais est-ce vraiment important ?

Le script que nous allons développer...

1. Problématique

Lorsque l’on a un important parc de serveurs à administrer et que l’on souhaite garantir à son entreprise un certain degré de sécurité, il faut s’astreindre à changer régulièrement les mots de passe des comptes ayant des privilèges d’administration. Lorsqu’il s’agit de changer le mot de passe d’un compte du domaine, c’est facile car on ne le change qu’une fois en un seul endroit. Mais lorsqu’il s’agit de changer le mot de passe du compte Administrateur local de chaque serveur membre du domaine, c’est une tout autre paire de manches!

2. Difficultés à surmonter

Toute la difficulté va être ici liée au fait...

1. Problématique

Nous avons des troubles du sommeil car des problèmes de sécurité informatique nous empêchent de dormir, parfois des cauchemars nous envahissent durant la nuit et nous réveillent en sursaut. Si cela vous arrive aussi, alors lisez attentivement ce qui va suivre…

Dans l’espoir de détecter une intrusion dans le système ou tout simplement pour savoir si de nouveaux administrateurs du domaine ont été nommés à votre insu, il peut être particulièrement intéressant de surveiller les ajouts de comptes au groupe « Admins du domaine ». Nous souhaitons donc être prévenus par e-mail dès qu’un ajout de ce genre se produit, et ce dans la mesure du possible, en temps réel ou presque !

2. Solution

Écrire un script basé sur les événements CIM/WMI fonctionnant en permanence en arrière-plan sous forme de travail planifié (scheduled job). Celui-ci surveille l’arrivée d’un événement particulier dans le journal de sécurité. Cet événement est l’événement d’ajout de membres à un groupe global de sécurité et porte l’ID 4728. En effet, lorsqu’une modification d’un groupe de sécurité a lieu et si la stratégie d’audit a été activée alors des événements sont automatiquement consignés dans le journal de sécurité des contrôleurs de domaine. Ce script doit donc fonctionner sur un contrôleur de domaine.

Nous devrons veiller à ce qu’un e-mail soit envoyé uniquement en cas d’ajout de membres au groupe « Admins du domaine » et seulement celui-là sous peine de crouler sous les messages.

Principe de mise en œuvre

La première chose à faire consiste à activer l’audit de sécurité via les stratégies de groupes appliquées aux contrôleurs de domaine. Ensuite, il faut réaliser quelques tests manuels d’ajout de membres au groupe « Admins du domaine » et observer le numéro...

1. Problématique

C’est bientôt la rentrée scolaire, et rentrée scolaire rime avec galère ! Comme chaque année, nous allons avoir plusieurs centaines de comptes utilisateurs à créer pour les étudiants. Mais cette année ne sera plus une année comme les autres, car cette fois nous automatiserons cette tâche ingrate ! Même si la mise au point du script peut être longue, il y a de très fortes chances que nous gagnions notre temps par rapport à une opération manuelle. Et quand bien même ce ne serait pas le cas, au moins nous en tirerions une certaine satisfaction personnelle et intellectuelle. D’autre part, nous serons sûrs que tous les comptes seront créés exactement de la même façon, ce qui évitera un grand nombre potentiel d’erreurs manuelles. De plus, nous pourrons réutiliser ce script l’année prochaine ; ce qui nous laissera le temps d’aller à la plage…

L’idéal serait qu’à partir d’un fichier texte nous puissions importer les utilisateurs ainsi que tous leurs paramètres associés ; c’est ce que nous allons tenter de faire.

2. Solution

Pour répondre à cette problématique, le plus simple sera de créer un fichier Excel où chaque ligne contiendra la description d’un compte utilisateur. Pour ce faire, il sera nécessaire de commencer notre fichier par une ligne d’entête. Chaque valeur de cette ligne devra porter le nom exact de la propriété à créer tel qu’il existe dans Active Directory Domain...

1. Problématique

Un matin, votre supérieur vient vous voir et vous demande de dresser un inventaire sur les différentes versions d’un applicatif déployé sur un important parc de machines. C’est normalement à ce moment-là que vous réalisez que vous ne disposez ni d’un outil de rapports applicatifs, ni d’un inventaire de déploiement logiciel à jour.

2. Solution

Pour tenter de répondre à cette problématique nous créerons un script qui, pour chaque compte d’ordinateur présent dans Active Directory Domain Services, ira ouvrir la base de registre à distance à la recherche du numéro de version pour une application donnée. Pour notre exemple, nous prendrons comme application test le lecteur Windows Media Player.

Voici le script :

# Get-MediaPlayerVersion.ps1 
function Get-Key 
{  
   #Accès à la base de registre 
   $Version = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\MediaPlayer\PlayerUpgrade ` 
-Name "PlayerVersion" -ea silentlycontinue).PlayerVersion 
  
   if ($Version...

1. Problématique

Nous venons d’effectuer une migration de nos serveurs DNS et nous avons dû installer de nouvelles machines à la place des anciennes. Par conséquent pour terminer cette migration, il va falloir mettre à jour la configuration réseau de tous nos serveurs pour prendre en compte ce changement. Nos serveurs ayant une configuration réseau statique, un script sera le bienvenu pour automatiser ce changement de configuration. Cela nous évitera de modifier manuellement le paramétrage sur chacun de nos serveurs, et nous fera gagner un temps précieux. Dans cette étude de cas, nous supposerons que le pare-feu réseau et ceux des machines distantes laissent passer le protocole ICMP ainsi que les requêtes WMI.

Voici dans l’interface graphique les champs qu’il nous faut mettre à jour :

Paramètres réseau à modifier

2. Solution

Utiliser WMI pour interroger et modifier à distance le paramétrage de la configuration réseau.

Dans un premier temps, nous allons nous attacher à faire une fonction qui récupère la configuration DNS d’une machine et qui retourne un objet personnalisé. Nous la nommerons Get-DNSConfiguration. Puis dans un second temps, nous en ferons une seconde afin de modifier la configuration DNS, nous l’appellerons Set-DNSConfiguration. Toutes deux prendront en entrée un paramètre pour indiquer le nom de la machine sur laquelle agir.

Voici le travail :

Fonction Get-DNSConfiguration

function Get-DNSConfiguration  
{  
    [CmdletBinding()]  
    Param (  
        [Parameter(Mandatory=$true, ValueFromPipeline=$true)]  
        [String[]]$ComputerName  
    )  
  
    Process   
    {  
      foreach ($computer in $ComputerName)  ...

1. Problématique

En entreprise, nombreuses sont les applications utilisant des certificats pour sécuriser leurs communications. Que ce soient les applications métiers (Web, etc.) ou les composants d’infrastructure (agent de supervision, de déploiement, etc.) tous sont susceptibles d’être à l’origine d’un déploiement de certificats sur les serveurs. Seulement qui dit certificat, dit date d’expiration. Et bien sûr, se rendre compte après coup qu’un certificat a expiré ne fait pas bon genre, surtout si cela a engendré un arrêt de service. C’est pourquoi nous allons vous montrer comment PowerShell peut vous prémunir de ce genre de mésaventure.

2. Solution 1 : Job PowerShell planifié local

Pour répondre à cette problématique, nous pourrions imaginer un script exécuté localement sur chaque machine sous forme de tâche planifiée et qui retourne le résultat dans le journal d’événement ou par e-mail. Commençons par créer notre script qui va parcourir le magasin de certificat Personnel de l’ordinateur local et lister ceux expirés.

Comme nous l’avons vu au cours de cet ouvrage, un fournisseur PowerShell existe pour parcourir les magasins de certificats, il s’agit du fournisseur Cert:.

PS > Gci Cert:\LocalMachine\My
 

Reste à notre charge de lister ceux dont la date d’expiration est inférieure à une limite que nous fixerons à 30 jours. Pour cela, nous allons utiliser la propriété NotAfter des certificats qui correspond à fin de validité. 03/01/2013 sur notre exemple ci-après.

Certificat avec date d’expiration au 03/01/2013

Voici notre script qui prend vie :

$DateLimite = (Get-Date).AddDays(30) 
Gci Cert:\LocalMachine\My | Where {$_.notafter -lt $DateLimite}
 

Le résultat obtenu est sous la forme suivante :

    Répertoire : Microsoft.PowerShell.Security\Certificate::LocalMachine\my ...

1. Problématique

Imaginez le scénario où nous serions dans un environnement ultra restrictif. Dans un tel environnement, nous souhaiterions déléguer la gestion de quelques commandes PowerShell à une seule personne, voire à un groupe restreint d’individus. En effet, nous n’avons pas envie que cette personne soit administrateur local du serveur car elle pourrait avoir accès à des données sensibles et cela n’est pas envisageable.

Pour illustrer concrètement ce scénario, nous allons imaginer que nous disposons d’un serveur d’impression dont nous voulons déléguer la gestion des travaux d’impression et uniquement des travaux d’impression. Comment faire cela ?

2. Solution

Créer une session de configuration (endpoint) restreinte qui ne donnera accès qu’aux commandes de la famille PrintJob (Get-PrintJob, Remove-PrintJob, Restart-PrintJob, Resume-PrintJob, Suspend-PrintJob).

Création du fichier de configuration

La première chose à faire, sur le serveur d’impression, est de créer une configuration de session. Pour ce faire, nous créerons d’abord un fichier de configuration que nous importerons dans une seconde phase.

La création d’un fichier de configuration s’effectue avec la commande : New-PSSessionConfigurationFile

Nous allons en profiter pour indiquer l’auteur de ce fichier, une description, le nom du module à charger, et la liste des fonctions avancées auxquelles nous permettons l’accès. Enfin, grâce au paramètre -SessionType nous indiquons que nous voulons limiter le jeu de commandes PowerShell au strict minimum.

PS > New-PSSessionConfigurationFile ` 
           -Path $home\PrintMgmt.pssc ` 
           -Author 'A. Petitjean' ` 
           -Description "Endpoint contraint pour la gestion des jobs d'impression" ` 
           -CompanyName "www.PowerShell-Scripting.com"...