Administration à distance

Les principales techniques d’administration à distance Windows en standard.

Introduction

Dans un environnement Windows, l’administration à distance peut être réalisée de différentes manières, cependant le spectre de la sécurité et l’omniprésence des pare-feux peut constituer un obstacle de taille.
Nous allons aborder 4 principales techniques d’administration à distance proposées et insister sur leurs contraintes respectives.
L’adhésion, à un même domaine peut en simplifier la mise en oeuvre alors qu’une gestion dans un groupe de travail n’indurera pas la confiance suffisante par défaut.
Nous n’évoquerons pas les autres techniques « non standard » basées sur un service installé sur la cible (tel que VNC) ou encore monté à la volée via le service de partage (tel que PSEXEC).

1 – Administration via le « Bureau à distance »

Cette technique est probablement la plus simple et la plus appropriée à la gestion d’un serveur mais en redirigeant la session dans un terminal RDP, elle sera beaucoup moins adaptée à l’administration des postes de travail.

 

 

2 – Administration via les outils d’administration « Consoles .MSC »

Cette technique présente l’avantage de préserver les sessions ouvertes sur les cibles mais considère que le réseau est digne de confiance. En effet, les ports ouverts (RPC/DCOM) dans le cadre de cette gestion sont dangereux et tristement réputés pour leurs nombreuses attaques.
Pour information, ces outils d’administration sont disponibles via ADMINPAK.msi (XP/2003) ou RSAT (Vista/Win7) et directement disponibles en tant que fonctionnalités de Win2008 / R2

 

3 – Administration via « WMI »

WMI est une technologie très employée dans le domaine de l’administration à distance, comme par exemple pour interroger le jeu de stratégie résultant GPO, collecter des informations sur le matériel, les programmes, etc.

 

4 – Administration via « WinRM » (WS-Managment)

Cette technique est en train de généraliser. En effet, basé sur une connexion HTTP ou HTTPS (véritable lien de confiance entre le poste d’administration et la cible), cette fonctionnalité a été introduite dans une première version avec Windows Server 2003R2. (WS-Managment v1.0) et offrait un accès à WMI via un écouteur de type Web configuré sur la cible. (Règle prédéfinie du pare-feu W7 = « Gestion à distance de Windows – Mode compatibilité … »)

  • Utilise par défaut les ports http (80) et HTTPS (443)

Depuis Windows 7 et 2008R2, la version 2 est généralisée (Rétroactivement, WinRM v2 est disponible en téléchargement pour XP et 2003)

  • Utilise par défaut les ports http (5985) et HTTPS (5986)

Important : L’utilisation d’une communication sur « HTTP » induit que le trafic n’est pas protégé. De fait, la communication s’appuie donc sur l’authentification Kerberos et implique donc que les machines (Appelante et cible) soient membres d‘un domaine Active Directory.

La console « Gestionnaire de serveur » sous Windows Server 2008 R2 est le premier outil graphique à exploiter cette technique de gestion

 

 

Mise en oeuvre de WinRM v2

WinRM est une commande en ligne servant à configurer et/ou interroger un écouteur HTTP/S. C’est également le nom du service « Gestion à distance de Windows (Gestion WSM)« .

wmic service where "name like 'winrm'" get displayname
  • Activation de WinRM sur HTTP (Fonctionne entre les ordinateurs membres d’un même domaine Active Directory avec authentification Kerberos)
winrm quickconfig

Vérification via la commande :

winrm enum winrm/config/listener

Le port HTTP par défaut est 5985 pour WinRM v2 et 80 pour WinRM v1

 

Bien que cela ne soit pas conseillé pour des raisons évidentes de sécurité, il est possible d’utiliser le protocole HTTP en stipulant les ordinateurs distants autorisés « Trustedhosts ».

winrm set winrm/config/client @{TrustedHosts="*"}

 

  • Activation de WinRM sur HTTPS
winrm quickconfig -transport:https
      Vérification via la commande :
winrm enum winrm/config/listener

Attention, il faut dans ce cas que l’ordinateur dispose d’un certificat valide (Adapté à l’authentification de machine, qui ne soit ni expiré, ni révoqué, ni auto-signé) – Cela implique de disposer d’une autorité de certification, à moins de générer et importer ces certificats manuellement avec les outils appropriés (ie makecert – procédure lourde et délicate)

 

Le port HTTPS par défaut est 5986 pour WinRM v2 et 443 pour WinRM v1

 

Vous pouvez tester et vérifier le fonctionnement:via la commande :

Winrs -r:https:// W7PRO-PC:5985 "cmd.exe"

 

5 – Administration via « PowerShell v2 »

Attention, PowerShell v2 doit être installé sur chaque ordinateur

 

  • Coté client (Configuration de WinRM) – Equivaut à la commande « WinRM QC » via CMD.exe

Via la console Powershell :

 PS> Enable-PSRemoting

 Cette commande réalise les opérations suivantes :

  1. Démarrage ou redémarrage (s’il est déjà démarré) du service WinRM (Gestion à distance de Windows (Gestion WSM).
  2. Affectation du démarrage automatique au service WinRM.
  3. Création d’un écouteur pour accepter les demandes sur n’importe quelle adresse IP.
  4. Activation de l’exception de pare-feu pour le trafic du service Gestion des services Web (sur HTTP uniquement).

Important : Attention aux contraintes du contrôle de compte d’utilisateur (UAC) – Avec Windows 2008 R2 Sp1, cette commande inhibe le filtrage du jeton d’administrateur. Pour les versions antérieures, vous pouvez vérifier la clé du registre « LocalAccountTokenFilterPolicy » ou utiliser la commande Powershell suivante pour positionner cette valeur:

 PS> New-Itemproperty -PathHKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -name LocalAccountTokenFilterPolicy -PropertyType DWord -value 1

 Ou via un script batch traditionnel

cmd /c reg add
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v
LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

 Attention, l’activation de l’écouteur utilise le transport HTTP par défaut qui s’appuie sur Kerberos pour l’authentification (Fonctionnel au sein des ordinateurs membres d’un domaine Active Directory) – Dans un groupe de travail, il est conseillé d’utiliser le transport HTTPS (nécessite l’installation d’un certificat de confiance non auto-signé) – Pour utiliser

HTTP sans Kerberos, vous devez stipuler le nom des ordinateurs habilités « TrustedHosts » dans la configuration de l’écouteur.

 # Autorise l’accès sur cet ordinateur de toute machine distante (!! non sécurisé)
Set-Item wsman:localhost\client\trustedhosts -value *

 

  • Coté poste d’administration :

Attention, seules quelques commandes Powershell utilisent cette technique de communication via l’écouteur web. Autrement dit, des commandes qui disposent du commutateur « -computername » utiliseront toujours une communication RPC.

PS> Enter-PSSession ‘Nomcible’
ou
PS> Invoke-Command -computername ‘Nomcible’ -FilePath ‘NomScriptLocal.ps1’

Remarque : La stratégie d’exécution peut nécessiter que les scripts distants soient signés – Paramétrage possible via les statégies de groupe GPO

PS> Get-ExecutionPolicy
PS> Set-ExecutionPolicy unrestricted

Par défaut, la connexion vers l’ordinateur cible s’effectue avec l’identifiant de la session Powershell du poste d’administration. Pour utiliser un identifiant alternatif , utiliser les commandes suivantes :

PS> $cred = Get-Credential
PS> Enter-PSSession -ComputerName ‘Nomcible’ -Port 5985 -Credential $cred

Pour fermer la session distante, utilisez la commande « Exit »

[Nomcible] PS> Exit
PS>

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *