Contrôle de compte d’utilisateur et WMI

  • Article

Le contrôle de compte d’utilisateur (UAC) impacte les données WMI qui sont retournées par un outil en ligne de commande, l’accès à distance ainsi que le mode d’exécution des scripts. Pour plus d’informations sur le contrôle de compte d’utilisateur, consultez Bien démarrer avec le contrôle de compte d’utilisateur.

Les sections suivantes décrivent la fonctionnalité de contrôle de compte d’utilisateur :

Contrôle de compte d'utilisateur

Sous le contrôle de compte d’utilisateur, les comptes du groupe Administrateurs local ont deux jetons d’accès : un avec des privilèges d’utilisateur standard et un avec des privilèges d’administrateur. En raison du filtrage des jetons d’accès par le contrôle de compte d’utilisateur, un script s’exécute normalement sous le jeton d’utilisateur standard, sauf s’il est exécuté « en tant qu’administrateur » avec des privilèges élevés. Les scripts ne nécessitent pas tous des privilèges d’administrateur.

Les scripts ne peuvent pas déterminer programmatiquement s’ils s’exécutent sous un jeton de sécurité d’utilisateur standard ou sous un jeton d’administrateur. Le script peut échouer avec une erreur d’accès refusé. Si le script nécessite des privilèges d’administrateur, il doit être exécuté en mode élevé. L’accès aux espaces de noms WMI varie selon que le script est exécuté ou non en mode élevé. Certaines opérations WMI, telles que l’obtention de données ou l’exécution de la plupart des méthodes, n’exigent pas l’exécution du compte en tant qu’administrateur. Pour plus d’informations sur les autorisations d’accès par défaut, consultez Accès aux espaces de noms WMI et Exécution d’opérations privilégiées.

En raison du contrôle de compte d’utilisateur, le compte exécutant le script doit être membre du groupe Administrateurs sur l’ordinateur local pour pouvoir s’exécuter avec des droits élevés.

Vous pouvez exécuter un script ou une application avec des droits élevés en appliquant l’une des méthodes suivantes :

Pour exécuter un script en mode élevé

  1. Ouvrez une fenêtre d’invite de commandes en cliquant avec le bouton droit sur Invite de commandes dans le menu Démarrer, puis en cliquant sur Exécuter en tant qu’administrateur.
  2. Planifiez l’exécution du script en mode élevé à partir du Planificateur de tâches. Pour plus d’informations, consultez Contextes de sécurité pour l’exécution des tâches.
  3. Exécutez le script en utilisant le compte Administrateur intégré.

Compte nécessaire pour exécuter les outils en ligne de commande WMI

Pour exécuter les outils en ligne de commande WMI suivants, votre compte doit être membre du groupe Administrateurs, et l’outil doit être exécuté à partir d’une invite de commandes élevée. Le compte Administrateur intégré peut également exécuter ces outils.

  • mofcomp

  • wmic

    La première fois que vous exécutez Wmic après l’installation du système, vous devez le faire à partir d’une invite de commandes élevée. Le mode élevé n’est pas toujours requis pour les exécutions ultérieures de Wmic, sauf si les opérations WMI exigent des privilèges d’administrateur.

  • winmgmt

  • wmiadap

Pour exécuter le contrôle WMI (Wmimgmt.msc) et modifier les paramètres d’audit ou de sécurité des espaces de noms WMI, votre compte doit avoir explicitement reçu le droit Modifier la sécurité ou bien être membre du groupe Administrateurs sur l’ordinateur local. Le compte Administrateur intégré peut également modifier la sécurité ou l’audit d’un espace de noms.

Wbemtest.exe, un outil en ligne de commande qui n’est pas pris en charge par les services du support technique Microsoft, peut être exécuté par les comptes qui ne sont pas membres du groupe Administrateurs local, sauf si une opération spécifique nécessite les privilèges habituellement accordés aux comptes Administrateur.

Gestion des connexions à distance sous contrôle de compte d’utilisateur

Le fait de vous connecter à un ordinateur distant dans un domaine ou dans un groupe de travail détermine si le contrôle de compte d’utilisateur effectue ou non un filtrage.

Si votre ordinateur fait partie d’un domaine, connectez-vous à l’ordinateur cible avec un compte de domaine qui est membre du groupe Administrateurs local sur l’ordinateur distant. Le filtrage des jetons d’accès par le contrôle de compte d’utilisateur n’impacte pas les comptes du domaine dans le groupe Administrateurs local. N’utilisez pas de compte local hors domaine sur l’ordinateur distant, même si le compte appartient au groupe Administrateurs.

Dans un groupe de travail, le compte qui se connecte à l’ordinateur distant est un utilisateur local sur cet ordinateur. Même si le compte est membre du groupe Administrateurs, le filtrage du contrôle de compte d’utilisateur fait qu’un script s’exécute en tant qu’utilisateur standard. Une bonne pratique consiste à créer un compte d’utilisateur ou de groupe d’utilisateurs local sur l’ordinateur cible, et de le dédier aux connexions à distance.

La sécurité doit être modifiée afin d’autoriser l’utilisation de ce compte, car celui-ci n’a jamais eu de privilèges d’administrateur. Accordez à l’utilisateur local les droits suivants :

  • Démarrage et activation à distance pour accéder à DCOM. Pour plus d’informations, consultez Connexion à WMI sur un ordinateur distant.
  • Accès à distance à l’espace de noms WMI (activation à distance). Pour plus d’informations, consultez Accès aux espaces de noms WMI.
  • Accéder à l’objet sécurisable spécifique, en fonction de la sécurité requise par l’objet.

Si vous utilisez un compte local, soit parce que vous êtes dans un groupe de travail, soit parce qu’il s’agit d’un compte d’ordinateur local, vous pouvez être obligé d’attribuer des tâches spécifiques à un utilisateur local. Par exemple, vous pouvez accorder à l’utilisateur le droit d’arrêter ou de démarrer un service spécifique en utilisant la commande SC.exe, les méthodes GetSecurityDescriptor et SetSecurityDescriptor de Win32_Service, ou une stratégie de groupe avec Gpedit.msc. Il arrive que certains objets sécurisables n’autorisent pas un utilisateur standard à effectuer des tâches, et n’offrent aucune possibilité de modifier la sécurité par défaut. Dans ce cas, vous devrez peut-être désactiver le contrôle de compte d’utilisateur afin que le compte d’utilisateur local ne soit pas filtré et qu’il s’exécute en tant qu’administrateur complet. N’oubliez pas que, pour des raisons de sécurité, la désactivation du contrôle de compte d’utilisateur est une solution de dernier recours.

La désactivation du contrôle de compte d’utilisateur à distance en modifiant l’entrée de Registre qui contrôle le contrôle de compte d’utilisateur à distance n’est pas recommandée, mais peut être nécessaire dans un groupe de travail. L’entrée de Registre est la suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy. Lorsque la valeur de cette entrée est égale à zéro (0), le filtrage des jetons d’accès de contrôle de compte d’utilisateur à distance est activé. Lorsque la valeur est 1, le contrôle de compte d’utilisateur distant est désactivé.

Impact du contrôle de compte d’utilisateur sur les données WMI retournées aux scripts ou aux applications

Si un script ou une application s’exécute sous un compte appartenant au groupe Administrateurs, mais qu’il ne s’exécute pas en mode élevé, vous risquez de ne pas obtenir toutes les données retournées, du fait que ce compte s’exécute en tant qu’utilisateur standard. Les fournisseurs WMI de certaines classes ne retournent pas toutes les instances à un compte d’utilisateur standard ou à un compte administrateur qui ne s’exécute pas en tant qu’administrateur complet en raison du filtrage par le contrôle de compte d’utilisateur.

Les classes suivantes ne retournent pas certaines instances lorsque le compte est filtré par le contrôle de compte d’utilisateur :

Les classes suivantes ne retournent pas certaines propriétés lorsque le compte est filtré par le contrôle de compte d’utilisateur :

À propos de WMI

Accès aux objets sécurisables WMI

Modification de la sécurité d’accès sur les objets sécurisables