Comment désactiver le contrôle de compte d’utilisateur (UAC) sur Windows Server

Cet article explique comment désactiver le contrôle de compte d’utilisateur (UAC) sur Windows Server.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 2526083

Résumé

Dans certaines circonstances limitées, la désactivation de la UAC sur Windows Server peut être une pratique acceptable et recommandée. Ces circonstances se produisent uniquement lorsque les deux conditions suivantes sont remplies :

• Seuls les administrateurs sont autorisés à se connecter au serveur Windows de manière interactive sur la console ou à l’aide des services Bureau à distance.
• Les administrateurs se connectent au serveur Windows uniquement pour effectuer des fonctions d’administration système légitimes sur le serveur.

Si l’une de ces conditions n’est pas vraie, l’UAC doit rester activée. Par exemple, le serveur active le rôle Services Bureau à distance afin que les utilisateurs non administrateurs puissent se connecter au serveur pour exécuter des applications. Le contrôle de compte d’utilisateur doit rester activé dans cette situation. De même, le contrôle de compte d’utilisateur doit rester activé dans les situations suivantes :

• Les administrateurs exécutent des applications à risque sur le serveur. Par exemple, les navigateurs web, les clients de messagerie ou les clients de messagerie instantanée.
• Les administrateurs effectuent d’autres opérations qui doivent être effectuées à partir d’un système d’exploitation client, tel que Windows 7.

Remarque

• Ces conseils s’appliquent uniquement aux systèmes d’exploitation Windows Server.
• La UAC est toujours désactivée sur les éditions Server Core de Windows Server 2008 R2 et versions ultérieures.

Plus d’informations

La UAC a été conçue pour aider les utilisateurs Windows à utiliser les droits d’utilisateur standard par défaut. L’UAC inclut plusieurs technologies pour atteindre cet objectif. Ces technologies sont notamment :

• Virtualisation de fichiers et de registre : lorsqu’une application héritée tente d’écrire dans des zones protégées du système de fichiers ou du Registre, Windows redirige en mode silencieux et transparent l’accès à une partie du système de fichiers ou au registre que l’utilisateur est autorisé à modifier. Il permet à de nombreuses applications qui nécessitaient des droits d’administration sur des versions antérieures de Windows de s’exécuter correctement avec uniquement des droits d’utilisateur standard sur Windows Server 2008 et versions ultérieures.

• Élévation sur le même bureau : lorsqu’un utilisateur autorisé exécute et élève un programme, le processus obtenu reçoit des droits plus puissants que ceux de l’utilisateur de bureau interactif. En combinant l’élévation avec la fonctionnalité de jeton filtré de UAC (voir la puce suivante), les administrateurs peuvent exécuter des programmes avec des droits d’utilisateur standard. Et ils peuvent élever uniquement les programmes qui nécessitent des droits d’administration avec le même compte d’utilisateur. Cette fonctionnalité d’élévation du même utilisateur est également appelée mode d’approbation Administration. Les programmes peuvent également être démarrés avec des droits élevés à l’aide d’un autre compte d’utilisateur afin qu’un administrateur puisse effectuer des tâches d’administration sur le bureau d’un utilisateur standard.

• Jeton filtré : lorsqu’un utilisateur disposant de privilèges administratifs ou puissants ou d’appartenances à un groupe se connecte, Windows crée deux jetons d’accès pour représenter le compte d’utilisateur. Le jeton non filtré possède tous les privilèges et appartenances aux groupes de l’utilisateur. Le jeton filtré représente l’utilisateur avec l’équivalent des droits d’utilisateur standard. Par défaut, ce jeton filtré est utilisé pour exécuter les programmes de l’utilisateur. Le jeton non filtré est associé uniquement aux programmes avec élévation de privilèges. Un compte est appelé compte administrateur protégé dans les conditions suivantes :

  • Il s’agit d’un membre du groupe Administrateurs
  • Il reçoit un jeton filtré lorsque l’utilisateur se connecte

• Isolation des privilèges d’interface utilisateur (UIPI) : UIPI empêche un programme à privilèges inférieurs de contrôler le processus doté de privilèges supérieurs de la manière suivante :
     Envoi de messages de fenêtre, tels que des événements de souris ou de clavier synthétiques, à une fenêtre qui appartient à un processus doté de privilèges plus élevés

• Mode protégé Internet Explorer (PMIE) : L’Explorer Internet en mode protégé (PMIE) est une fonctionnalité de défense en profondeur. Windows Internet Explorer fonctionne en mode protégé à faibles privilèges et ne peut pas écrire dans la plupart des zones du système de fichiers ou du Registre. Par défaut, le mode protégé est activé lorsqu’un utilisateur navigue sur des sites dans les zones Internet ou Sites restreints. La fonction PMIE rend plus difficile la modification des paramètres de l’utilisateur pour les programmes malveillants qui infectent un Explorer instance Internet en cours d’exécution. Par exemple, il se configure pour démarrer chaque fois que l’utilisateur se connecte. L’indice PMIE ne fait pas réellement partie de l’UAC. Mais cela dépend des fonctionnalités UAC, telles que UIPI.

• Détection du programme d’installation : lorsqu’un nouveau processus est sur le point d’être démarré sans droits d’administration, Windows applique une heuristique pour déterminer si le nouveau processus est susceptible d’être un programme d’installation hérité. Windows suppose que les programmes d’installation hérités sont susceptibles d’échouer sans droits d’administration. Par conséquent, Windows invite de manière proactive l’utilisateur interactif à effectuer une élévation. Si l’utilisateur n’a pas d’informations d’identification administratives, il ne peut pas exécuter le programme.

Si vous désactivez le paramètre de stratégie Contrôle de compte d’utilisateur : Exécuter tous les administrateurs en mode d’approbation Administration. Il désactive toutes les fonctionnalités UAC décrites dans cette section. Ce paramètre de stratégie est disponible via la stratégie de sécurité locale, les paramètres de sécurité, les stratégies locales, puis les options de sécurité de l’ordinateur. Les applications héritées qui disposent de droits d’utilisateur standard qui s’attendent à écrire dans des dossiers protégés ou des clés de Registre échouent. Les jetons filtrés ne sont pas créés. Et tous les programmes s’exécutent avec les droits complets de l’utilisateur qui est connecté à l’ordinateur. Il inclut les Explorer Internet, car le mode protégé est désactivé pour toutes les zones de sécurité.

L’une des idées fausses courantes concernant l’UAC et l’élévation du même bureau en particulier est la suivante : elle empêche l’installation de programmes malveillants ou l’obtention de droits d’administration. Tout d’abord, les programmes malveillants peuvent être écrits pour ne pas exiger de droits d’administration. Et les programmes malveillants peuvent être écrits pour écrire uniquement dans les zones du profil de l’utilisateur. Plus important encore, l’élévation du même bureau dans UAC n’est pas une limite de sécurité. Il peut être détourné par un logiciel non privilégié qui s’exécute sur le même bureau. L’élévation du même bureau doit être considérée comme une fonctionnalité pratique. Du point de vue de la sécurité, l’administrateur protégé doit être considéré comme l’équivalent de l’administrateur. En revanche, l’utilisation du basculement rapide de l’utilisateur pour se connecter à une autre session à l’aide d’un compte d’administrateur implique une limite de sécurité entre le compte administrateur et la session utilisateur standard.

Pour un serveur Windows sur lequel la seule raison de l’ouverture de session interactive est d’administrer le système, l’objectif de moins d’invites d’élévation n’est pas réalisable ou souhaitable. Les outils d’administration système nécessitent légitimement des droits d’administration. Lorsque toutes les tâches de l’utilisateur administratif nécessitent des droits d’administration et que chaque tâche peut déclencher une invite d’élévation, les invites ne sont qu’un obstacle à la productivité. Dans ce contexte, ces invites ne peuvent pas/ne peuvent pas promouvoir l’objectif d’encourager le développement d’applications qui nécessitent des droits d’utilisateur standard. Ces invites n’améliorent pas la posture de sécurité. Ces invites encouragent simplement les utilisateurs à cliquer dans les boîtes de dialogue sans les lire.

Ces conseils s’appliquent uniquement aux serveurs bien gérés. Cela signifie que seuls les utilisateurs administratifs peuvent se connecter de manière interactive ou via les services Bureau à distance. Et ils peuvent uniquement effectuer des fonctions administratives légitimes. Le serveur doit être considéré comme équivalent à un système client dans les situations suivantes :

• Les administrateurs exécutent des applications à risque, telles que des navigateurs web, des clients de messagerie ou des clients de messagerie instantanée.
• Les administrateurs effectuent d’autres opérations qui doivent être effectuées à partir d’un système d’exploitation client.

Dans ce cas, la UAC doit rester activée en tant que mesure de défense en profondeur.

En outre, si les utilisateurs standard se connectent au serveur sur la console ou via les services Bureau à distance pour exécuter des applications, en particulier des navigateurs web, le contrôle de compte d’utilisateur doit rester activé pour prendre en charge la virtualisation de fichiers et de registre, ainsi que le mode Internet en mode protégé Explorer.

Une autre option pour éviter les invites d’élévation sans désactiver le contrôle de compte d’utilisateur consiste à définir le contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs dans Administration stratégie de sécurité en mode d’approbation sur Élever sans invite. À l’aide de ce paramètre, les demandes d’élévation sont approuvées en mode silencieux si l’utilisateur est membre du groupe Administrateurs. Cette option laisse également l’option PMIE et d’autres fonctionnalités UAC activées. Toutefois, toutes les opérations qui nécessitent des droits d’administration ne demandent pas une élévation. L’utilisation de ce paramètre peut entraîner la élévation de privilèges de certains programmes de l’utilisateur et d’autres non, sans aucun moyen de les distinguer. Par exemple, la plupart des utilitaires de console qui nécessitent des droits d’administration s’attendent à être démarrés à une invite de commandes ou à un autre programme déjà élevé. Ces utilitaires échouent simplement lorsqu’ils sont démarrés à une invite de commandes qui n’est pas élevée.

Effets supplémentaires de la désactivation du contrôle de compte d’utilisateur

• Si vous essayez d’utiliser Windows Explorer pour accéder à un répertoire dans lequel vous ne disposez pas des autorisations de lecture, Explorer proposez de modifier les autorisations de l’annuaire pour accorder à votre compte d’utilisateur l’accès permanent à celui-ci. Les résultats varient selon que le contrôle de compte d’utilisateur est activé ou non. Pour plus d’informations, consultez Lorsque vous cliquez sur Continuer pour l’accès aux dossiers dans Windows Explorer, votre compte d’utilisateur est ajouté à la liste de contrôle d’accès du dossier.
• Si le contrôle de compte d’utilisateur est désactivé, Windows Explorer continue d’afficher des icônes de bouclier UAC pour les éléments qui nécessitent une élévation. Et Windows Explorer continue d’inclure Exécuter en tant qu’administrateur dans les menus contextuels des applications et des raccourcis d’application. Étant donné que le mécanisme d’élévation de contrôle de compte d’utilisateur est désactivé, ces commandes n’ont aucun effet. Et les applications s’exécutent dans le même contexte de sécurité que l’utilisateur connecté.
• Si le contrôle de contrôle de compte d’utilisateur est activé, lorsque l’utilitaire de console Runas.exe est utilisé pour démarrer un programme à l’aide d’un compte d’utilisateur soumis au filtrage de jetons, le programme s’exécute avec le jeton filtré de l’utilisateur. Si le contrôle de compte d’utilisateur est désactivé, le programme démarré s’exécute avec le jeton complet de l’utilisateur.
• Si la UAC est activée, les comptes locaux soumis au filtrage de jetons ne peuvent pas être utilisés pour l’administration à distance sur des interfaces réseau autres que le Bureau à distance. Par exemple, via NET USE ou WinRM. Un compte local qui s’authentifie sur une telle interface obtient uniquement les privilèges accordés au jeton filtré du compte. Si le contrôle de contrôle de compte d’utilisateur est désactivé, cette restriction est supprimée. La restriction peut également être supprimée à l’aide du LocalAccountTokenFilterPolicy paramètre décrit dans KB951016. La suppression de cette restriction peut augmenter le risque de compromission du système dans un environnement où de nombreux systèmes ont un compte local d’administration avec le même nom d’utilisateur et le même mot de passe. Nous vous recommandons de vous assurer que d’autres mesures d’atténuation sont utilisées contre ce risque. Pour plus d’informations sur les atténuations recommandées, consultez Atténuation des attaques Pass-the-Hash (PtH) et autres vols d’informations d’identification, version 1 et 2.
• PsExec, contrôle de compte d’utilisateur et limites de sécurité
• Lorsque vous sélectionnez Continuer pour l’accès aux dossiers dans Windows Explorer, votre compte d’utilisateur est ajouté à la liste de contrôle d’accès pour le dossier (Kb 950934)