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

Les connexions 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 sans-agent sur Windows peut nécessiter certaines étapes de configuration décrites ci-dessous.

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

Le compte utilisé par Cyberwatch doit être membre du groupe Administrateurs local des actifs, 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é

Utiliser un compte de domaine (recommandé)

Sur les actifs joints à un domaine Active Directory, utiliser un compte de domaine dédié à Cyberwatch, membre du groupe Administrateurs local des actifs à superviser. Cette appartenance peut être déployée par une GPO, avec les « Groupes restreints » ou avec les préférences de stratégie de groupe « Utilisateurs et groupes locaux ».

Dans l’identifiant enregistré WinRM avec HTTP Negotiate, saisir le compte au format DOMAINE\utilisateur. Ce connecteur s’authentifie en NTLM. Si le domaine restreint NTLM, utiliser le connecteur WinRM avec Kerberos décrit dans la section « Utilisation de WinRM-Kerberos » ci-dessous.

Un compte de domaine présente deux avantages par rapport à un compte local :

• il reste utilisable sur les actifs qui refusent la connexion réseau aux comptes locaux
• il ne nécessite pas la clé de registre LocalAccountTokenFilterPolicy, car l’UAC ne filtre pas le jeton d’un compte de domaine lors d’une connexion à distance

Utiliser un compte local

Sur les actifs hors domaine (groupe de travail), créer un utilisateur local 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.

Un compte local nécessite en plus la clé de registre LocalAccountTokenFilterPolicy, décrite dans la section Activation de WinRM.

Un actif peut refuser toute connexion réseau aux comptes locaux, avec le droit utilisateur « Interdire l’accès à cet ordinateur à partir du réseau » (SeDenyNetworkLogonRight) contenant Compte local ou Compte local et membre du groupe Administrateurs. Ce réglage est demandé par la règle SBP-WIN-04-007 du référentiel Security_Best_Practice_Windows, ainsi que par les baselines de sécurité Microsoft et CIS. Sur ces actifs, une connexion sans-agent avec un compte local échoue : utiliser un compte de domaine ou l’agent Cyberwatch.

Les utilisateurs membres des groupes Protected Users ou gMSA ne peuvent pas utiliser le service WinRM. Il faut donc veiller à ne pas inclure le compte utilisé par Cyberwatch, de domaine ou local, 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

Avec un compte local, l’activation seule de WinRM ne suffit pas : il faut 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. Cette étape est inutile avec un compte de domaine.

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

Cette clé désactive le filtrage du jeton par l’UAC pour les connexions réseau des comptes locaux. Elle fait échouer la règle SBP-WIN-05-005 « Ensure UAC token filtering is not disabled for network logons » du référentiel Security_Best_Practice_Windows. Un compte de domaine évite ce réglage.

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

Le connecteur WinRM avec Kerberos nécessite un compte de domaine. Il remplace le connecteur WinRM avec HTTP Negotiate lorsque le domaine restreint l’authentification NTLM.

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