Remoting Powershell – Partie 1

Bonjour,

L’avenement de Microsoft Powershell est bien l’arrivée du remoting. La capacité, avec un outil complet, à administrer son parc de son bureau, sans avoir besoin d’utiliser des psexec et consorts.

Dans cette série d’article, je vais tenter de vous apporter une approche ludique et simple afin que vous puissez utiliser ces technologies pour vous faciliter la vie :o)

Tout d’abord, il faut savoir que Powershell utilise plusieurs technologies pour l’accès à des machines distantes :

  • RPC, DCOM
  • WinRM (WS Management)
  • Les Web Services (AD par exemple)

On pourra selon la méthode utilisée :

  • Exécuter une seule commande dans une session temporaire sur une ou plusieurs machines
  • Ouvrir une session Powershell interactive
  • Des sessions persistantes
  • Importer en local un jeux de commandes n’existant que sur une machine distante sous forme de module

Support natif de l’acces distant

 

Les cmdlets natives utilisent des technologies déjà employées par d’autres consoles ou outils d’accès distants : RCP ou DCOM au travers du framework .NET. Elles acceptent le paramètre –ComputerName pour cibler une machine distante peuvent pour certaines accepter le paramètre –Credential pour transmettre des credentials autres que celles de l’utilisateur courant.

[powershell]

 

Get-Command | Where-Object {$_.definition -match ‘computername’ -and $_.definition -notmatch ‘Session’ -and $_.name -notlike “*WS*”} | get-help | fl name, synopsis

 

[/powershell]

Plusieurs topologies de connexions sont possibles:

  • Connexion 1:1
  • Connexion 1:N

Authentification

La majeure partie des cmdlets PowerShell nécessitent l’utilisation d’un compte membre du groupe Administrateur local de la machine distante.  Si l’on ne spécifie pas le paramètre –Credential lors d’un accès à une machine distante, PowerShell essaiera de vous authentifier avec votre compte utilisateur courant

Si les machines ne sont pas membres d’un domaine Active Directory, il est possible de créer un compte local sur votre machine cliente ayant le même login et mot de passe qu’un compte administrateur de la machine distante. Lors de la connexion avec les cmdlets PowerShell à cette machine sous l’identité de ce compte local, vous serez authentifié sur la machine distante avec ce compte de manière transparente.

 

WinRM

 

WinRM est l’implémentation Microsoft du protocole WS-Management (Web Service for Management), qui s’appuie sur SOAP (Simple Object Acces Protocol). Utilisé par PowerShell v2 comme framework de communication,  il fournit un certain nombres de fonctionnalités (sécurité, gestion de sessions…)

Les commandes sont transmises à la machine distante en HTTP (ou HTTPS) en utilisant le port 5985 (ou 5986).

NB : WinRM 2 est utilisé depuis Windows Server 2008 R2, depuis Windows Server 2012 WinRM 3 est disponible

Securite

La communication http entre le poste client et la machine distante est chiffrée avec :

  • Kerberos pour les machines sur domaine
  • NTLM autrement

Il est aussi possible de configurer SSL afin de rajouter une couche de cryptage 😉

Pour pouvoir lancer des scripts ou des cmdlets sur une machine distante, l’utilisateur doit alors  :

  • Soit être membre du groupe administrateurs local de la machine distante
  • Soit pouvoir fournir des credentials administrateur lors de l’exécution à distance
  • Soit avoir accès à la configuration de la session PowerShell sur la machine distante

Sur un OS client (Windows Vista ou Windows 7), la « Network Location » pour toutes les interfaces réseau doit être configurée soit en Home, soit en Work (pas Public donc). Evidement chaque session PowerShell distante tourne dans un processus séparé des autres

Configuration

Lancer la cmdlet ci-dessous sur la machine distante

[powershell]Enable-PSRemoting –force[/powershell]

Cette cmdlet réalise les opérations suivantes :

  • Modifie la configuration du service WinRM en ajoutant le SID du groupe administrateur
  • Démarre ou redémarre le service WinRM, le configure pour démarrer automatiquement
  • Création d’un listener WinRM sur le port 5985 (HTTP)
  • Ajoute une règle de firewall pour autoriser le trafic propre au protocole WS-Management

Il est aussi possible d’utiliser une GPO pour configurer l’accès distant.

  • Computer Configuration   Administrative Template Windows Components Windows Remote Management (WinRM) WinRM Service

 

Editez le parameter “Allow automatic configuration of listeners”

Cliquez sur Enabled

Entrez les IP autorisées à se connecter

Allez ensuite dans

  • Computer Configuration Policies Windows Settings Security Settings System Services

Editez les proprieties de Windows Remote Management (WS-Management)

Cochez la case Define this policy Setting

Cochez Automatic

Il est indispensable d’autoriser une exception dans le firewall du système pour autoriser les ports 5985 et/ou 5986 pour les machines de l’OU

Après avoir lancez un

[powershell]

 

gpupdate /force

 

[/powershell]

Ouvrez une console PS et exécutez

[powershell]

 

Enter-PSSession –Computername localhost

 

[/powershell]

 

Remarques

 

L’authentification par défaut se fait par Kerberos et les credentials sont chiffrés à travers du protocol WS-Management.

Kerberos ne sera pas utilisé si :

  • On utilise –Authentication pour spécifier un autre protocole
  • La machine cliente est en workgroup
  • Le paramètre ComputerName est une IP

Pour utiliser NTLM :

  • Configurer le listerner HTTPS
  • Ajouter la machine distance dans le TrustedHosts

Pour modifier la liste des TrustedHosts :

 [powershell]

 

set-item wsman:localhostClientTrustedHosts -value *

 

[/powershell]

Pour rajouter un host dans une liste:

 [powershell]

 

$TrustedHosts = (get-item wsman:localhostClientTrustedHosts).Value

set-item wsman:localhostClientTrustedHosts –value “$TrustedHosts, DC2.temp.com”

 

 

[/powershell]

Chaque session distante utilize un fichier de configuration, on pourra par session définir :

  • Quelles commandes seront accessibles
  • Quelle version de Powershell utiliser
  • Limiter le volume des données
  • Le nom du script de démarrage

Ci-dessous un exemple de configuration de session. Vous pouvez le stocker dans un fichier *.ps1 à exécuter à chaque lancement de session

[powershell]

 

# cmdlets autorisées

$arrcmdlets = @(“Get-Command”,”Get-Hotfix”,”Get-Process”,”Get-FormatData”,”Out-Default”,”Select-Object”,”Out-file”,”Measure-Object”,”Exit-PSSession”)

# On masque les cmdlets non désirées

Get-Command | Where-Object {$arrcmdlets -notcontains $_.Name} | ForEach-Object{ $_.Visibility = “Private” }

# On désactive les fonctionnalités du langage PowerShell

$ExecutionContext.SessionState.LanguageMode=”NoLanguage”

 

[/powershell]

Ensuite, on enregistre la configuration en spécifiant son nom et on spécifie le script si on a choisit de la stocker.

 [powershell]

 

Register-PSSessionConfiguration -name ConfPerso -StartupScript C:tempConfPerso.PS1

 

[/powershell]

Pour modifier les droits sur cette configuration

[powershell]

 

Set-PSSessionConfiguration ConfPerso –ShowSecurityDescriptorUI -force

 

[/powershell]

Ici vous pourrez modifier à votre guise les droits, rajouter des utilisateurs, etc…

Il est possible de modifier la configuration appelée par défaut en modifiant la variable $PSSessionConfigurationName pour charger une configuration custom.

 

Voilà, c’est tout pour cette première partie, en espérant qu’elle ait éclairé un peu votre lanterne !

Tchô !