Partager via

Contrôle de compte d’utilisateur et WMI

  • Article

Le contrôle de compte d’utilisateur (UAC) affecte les données WMI retournées par un outil en ligne de commande, un accès à distance et la façon dont les scripts doivent s’exécuter. Pour plus d’informations sur l’UAC, consultez Prise en main du contrôle de compte d’utilisateur.

Les sections suivantes décrivent les fonctionnalités UAC :

Contrôle de compte d’utilisateur

Sous UAC, les comptes du groupe Administrateurs locaux 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 UAC, un script est normalement exécuté sous le jeton utilisateur standard, sauf s’il est exécuté « en tant qu’administrateur » en mode privilège élevé. Tous les scripts n’ont pas besoin de privilèges d’administration.

Les scripts ne peuvent pas déterminer par programme s’ils s’exécutent sous un jeton de sécurité utilisateur standard ou un jeton Administrateur. Le script peut échouer avec une erreur d’accès refusée. Si le script nécessite des privilèges d’administrateur, il doit être exécuté en mode avec élévation de privilèges. L’accès aux espaces de noms WMI diffère selon que le script est exécuté en mode avec élévation de privilèges. Certaines opérations WMI, telles que l’obtention de données ou l’exécution de la plupart des méthodes, ne nécessitent pas que le compte s’exécute 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 se trouver dans le 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 effectuant l’une des méthodes suivantes :

pour exécuter un script en mode avec élévation de privilèges

  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 avec élévation de privilèges à l’aide du Planificateur de tâches. Pour plus d’informations, consultez contextes de sécurité pour l’exécution de tâches.
  3. Exécutez le script à l’aide du compte Administrateur intégré.

Compte nécessaire pour exécuter les outils WMI Command-Line

Pour exécuter les WMI Command-Line Toolssuivants, votre compte doit se trouver dans le groupe Administrateurs et l’outil doit être exécuté à partir d’une invite de commandes avec élévation de privilèges. Le compte d’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, elle doit être exécutée à partir d’une invite de commandes avec élévation de privilèges. Le mode avec élévation de privilèges peut ne pas être requis pour les exécutions suivantes de Wmic, sauf si les opérations WMI nécessitent des privilèges d’administrateur.

  • winmgmt

  • wmiadap

Pour exécuter le contrôle WMI (Wmimgmt.msc) et apporter des modifications aux paramètres de sécurité ou d’audit de l’espace de noms WMI, votre compte doit disposer du droit de modification de sécurité explicitement accordé ou se trouver dans le groupe Administrateurs 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 de support technique Microsoft, peut être exécuté par des comptes qui ne se trouvent pas dans le groupe Administrateurs local, sauf si une opération spécifique nécessite des privilèges qui sont normalement accordés aux comptes d’administrateur.

Gestion des connexions à distance sous UAC

Que vous vous connectiez à un ordinateur distant dans un domaine ou dans un groupe de travail détermine si le filtrage UAC se produit.

Si votre ordinateur fait partie d’un domaine, connectez-vous à l’ordinateur cible à l’aide d’un compte de domaine qui se trouve dans le groupe Administrateurs local de l’ordinateur distant. Ensuite, le filtrage des jetons d’accès UAC n’affecte pas les comptes de domaine dans le groupe Administrateurs local. N’utilisez pas de compte local, non-domaine sur l’ordinateur distant, même si le compte se trouve dans le groupe Administrateurs.

Dans un groupe de travail, le compte se connectant à l’ordinateur distant est un utilisateur local sur cet ordinateur. Même si le compte se trouve dans le groupe Administrateurs, le filtrage UAC signifie qu’un script s’exécute en tant qu’utilisateur standard. Une bonne pratique consiste à créer un groupe d’utilisateurs local dédié ou un compte d’utilisateur sur l’ordinateur cible spécifiquement pour les connexions à distance.

La sécurité doit être ajustée pour pouvoir utiliser ce compte, car le compte n’a jamais eu de privilèges administratifs. Donnez à l’utilisateur local :

  • Lancement à distance et activation des droits pour accéder à DCOM. Pour plus d’informations, consultez Connexion à WMI sur un ordinateur distant.
  • Droits d’accès à distance à l’espace de noms WMI (Activation à distance). Pour plus d’informations, consultez Accès aux espaces de noms WMI.
  • Droit d’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 ou 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 via la commande SC.exe, l'GetSecurityDescriptor et SetSecurityDescriptor méthodes de Win32_Service, ou via la stratégie de groupe à l’aide de Gpedit.msc. Certains objets sécurisables peuvent ne pas permettre à un utilisateur standard d’effectuer des tâches et d’offrir aucun moyen de modifier la sécurité par défaut. Dans ce cas, vous devrez peut-être désactiver l’UAC afin que le compte d’utilisateur local ne soit pas filtré et devient à la place un administrateur complet. N’oubliez pas que pour des raisons de sécurité, la désactivation de l’UAC doit être un dernier recours.

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

Effet UAC sur les données WMI retournées aux scripts ou aux applications

Si un script ou une application s’exécute sous un compte dans le groupe Administrateurs, mais pas avec un privilège élevé, vous risquez de ne pas obtenir toutes les données retournées, car ce compte s’exécute en tant qu’utilisateur standard. Les fournisseurs WMI pour certaines classes ne retournent pas toutes les instances à un compte d’utilisateur standard ou à un compte d’administrateur qui ne s’exécute pas en tant qu’administrateur complet en raison du filtrage UAC.

Les classes suivantes ne retournent pas certaines instances lorsque le compte est filtré par UAC :

Les classes suivantes ne retournent pas certaines propriétés lorsque le compte est filtré par UAC :

À propos de WMI

l’accès aux objets sécurisables WMI

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