Informations techniques sur les connexions mode sans-agent pour les systèmes Windows

Les connexions mode sans-agent sur les systèmes Windows reposent sur le protocole de connexion à distance WinRM. Celui-ci doit donc être activé sur les actifs à superviser.

Ce protocole utilise par défaut le port 5985 en mode WinRM HTTP et 5986 en mode WinRM HTTPS.

Le bon fonctionnement des connexions mode sans-agent sur Windows peut nécessiter certaines étapes de configuration décrites ci-dessous.

Prérequis nécessaires à l’utilisation des connexions mode sans-agent

L’utilisation d’un compte Administrateur local est indispensable, car les scripts d’analyse font appel à des méthodes nécessitant des privilèges :

  • utilisation de DISM (Deployment Imaging and Servicing Management) - récupération des versions des KB installées -.
  • utilisation de l’API WUA (Windows Update Agent) - suppression / téléchargement / gestion de fichier .cab, gestion des services WUA, déploiement des mises à jour -.
  • accès aux répertoires soumis à privilèges - %APPDATA% de tous les utilisateurs pour la récupération des versions des applications installées -.
  • privilèges potentiellement nécessaires pour l’exécution des scripts d’analyses de Conformité.

Il est donc nécessaire de créer un utilisateur Cyberwatch membre du groupe Administrateurs local, en utilisant par exemple la commande suivante :

$UserPassword = Read-Host -AsSecureString       # Une fois la commande validée, saisir un mot de passe pour l'utilisateur Cyberwatch
New-LocalUser "Cyberwatch" -Password $UserPassword
Add-LocalGroupMember -Group 'Administrateurs' -Member Cyberwatch -Verbose

Administrators doit être utilisé sur un système en langue Anglaise.

Les utilisateurs membres des groupes Protected Users ou gMSA ne peuvent pas utiliser le service WinRM. Il faut donc veiller à ne pas inclure l’utilisateur Cyberwatch dans l’un de ces groupes.

Activation de WinRM

La commande PowerShell ci-dessous active le service WinRM s’il est désactivé, et configure le pare-feu Windows en conséquence :

Enable-PSRemoting -Force

Dans certains cas de figure, l’activation seule de WinRM ne suffit pas : il peut être nécessaire d’autoriser les comptes administrateurs locaux à se connecter via WinRM, ou Cyberwatch remontera l’erreur WinRM::WinRMAuthorizationError lors de la création de la connexion sans-agent.

Pour ce faire, il faut ajouter la clé suivante dans la base de registre :

New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

La commande suivante permet enfin de vérifier que le service WinRM est bien démarré, et le démarre si cela n’a pas été correctement effectué :

winrm quickconfig

Optionnel - Désactiver manuellement le pare-feu pour WinRM

Une désactivation manuelle du pare-feu Windows peut parfois s’avérer nécessaire malgré les précédentes manipulations, notamment sur les machines AWS-EC2. Dans ce cas, l’erreur remontée par Cyberwatch est Connection expired.

La commande PowerShell ci-dessous permet d’autoriser les requêtes TCP entrantes sur le port 5985 au niveau du pare-feu Windows :

netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow

Optionnel - Utilisation de WinRM-Kerberos

Kerberos est un protocole d’authentification basé sur le principe d’un tiers de confiance. Son fonctionnement se base sur un centre de distribution de clés (KDC), permettant d’émettre des tickets autorisant l’utilisateur à accéder aux ressources du réseau. Le fonctionnement se rapproche des systèmes d’authentification SSO.

Le processus d’authentification Kerberos est le suivant :

  • Le client initie une demande d’authentification auprès du KDC ;
  • Si les informations sont validées par le KDC, il émet un ticket d’octroi de ticket (TGT) ;
  • Le client présente ensuite le TGT pour demander l’authentification sur un service ;
  • Le service en question renvoie le TGT au KDC pour validation ;
  • Une fois validé, le KDC émet un ticket final permettant l’authentification du client sur le service.

Pour que l’utilisation de ce protocole soit possible, plusieurs éléments doivent être renseignés :

  • Domaine : domaine dans lequel sont regroupées les ressources Kerberos. Dans le cas d’une authentification WinRM, cela représente le domaine de votre Active Directory.
  • KDC : serveur de confiance permettant la distribution des tickets. Dans un domaine Active Directory, il correspond au FQDN du contrôleur de domaine.
  • Serveur d'administration : serveur de confiance permettant l’octroi des tickets de service aux clients. Dans un domaine Active Directory, il correspond au FQDN du contrôleur de domaine.

Il convient ensuite de fournir un couple utilisateur/mot de passe autorisé à s’authentifier sur le domaine Active Directory renseigné.

Prérequis à l’utilisation de WinRM-Kerberos

Le serveur Cyberwatch doit être capable de résoudre les noms de domaines :

  • du KDC (Key Distribution Center) ;
  • du serveur d’administration ;
  • de chaque actif à superviser.

Retour en haut