Como desativar o Controle de Conta de Usuário (UAC) no Windows Server

• 09/08/2020
• 8 minutos para ler
• • D
  • s

Este artigo apresenta como desativar o Controle de Conta de Usuário (UAC) no Windows Server.

Versão original do produto: Windows Server 2012 R2
Número KB original: 2526083

Resumo

Sob certas circunstâncias restritas, desabilitar o UAC no Windows Server pode ser uma prática aceitável e recomendada. Essas circunstâncias ocorrem apenas quando todas as seguintes condições são verdadeiras:

• Apenas os administradores têm permissão para entrar no servidor baseado em Windows interativamente no console ou usando os Serviços de Área de Trabalho Remota.
• Os administradores iniciam sessão no servidor baseado em Windows apenas para realizar funções administrativas legítimas do sistema no servidor.

Se alguma dessas condições não for verdadeira, o UAC deve permanecer ativado. Por exemplo, se o servidor habilitar a função de Serviços de Área de Trabalho Remota para que usuários não administrativos possam entrar no servidor para executar aplicativos, o UAC deve permanecer habilitado. Da mesma forma, o UAC deve permanecer habilitado se os administradores executam aplicativos perigosos no servidor, como navegadores da web, e-mail clientes ou clientes de mensagens instantâneas ou se os administradores realizam outras operações que devem ser feitas em um sistema operacional cliente, como o Windows 7.

Mais informações

O UAC foi projetado para ajudar os usuários do Windows a usar o padrão direitos do usuário por padrão. O UAC inclui várias tecnologias para conseguir isso. Essas tecnologias incluem o seguinte:

• Virtualização de arquivos e registros: quando um aplicativo legado tenta gravar em áreas protegidas do sistema de arquivos ou do registro, o Windows redireciona de forma silenciosa e transparente o acesso a uma parte do sistema de arquivos ou do registro que o usuário tem permissão para alterar. Isso permite que muitos aplicativos que exigem direitos administrativos em versões anteriores do Windows sejam executados com êxito apenas com direitos de usuário padrão no Windows Server 2008 e versões posteriores.
• Elevação da mesma área de trabalho: quando um usuário autorizado executa e eleva um programa , o processo resultante recebe direitos mais poderosos do que os do usuário de desktop interativo. Ao combinar a elevação com o recurso Filtered Token do UAC (consulte o ponto a seguir), os administradores podem executar programas com direitos de usuário padrão e, em seguida, elevar apenas os programas que exigem direitos administrativos com a mesma conta de usuário. (Este recurso de elevação do mesmo usuário é também conhecido como Modo de aprovação de administrador.) Os programas também podem ser iniciados com direitos elevados usando uma conta de usuário diferente para que um administrador possa executar tarefas administrativas na área de trabalho de um usuário padrão.
• Token filtrado: quando um usuário que tem privilégios administrativos ou outros privilégios poderosos ou membros de grupo fazem logon, o Windows cria dois tokens de acesso para representar a conta do usuário. O token não filtrado tem todas as associações e privilégios de grupo do usuário, enquanto o token filtrado representa o usuário com o equivalente aos direitos de usuário padrão. Por padrão, esse token filtrado é usado para executar os programas do usuário. O token não filtrado está associado apenas a programas elevados. Uma conta que é membro do grupo Administradores e que recebe um token filtrado quando o usuário faz logon é chamada de conta de administrador protegida.
• Isolamento de privilégio de interface de usuário (UIPI): UIPI impede um programa de privilégios inferiores de enviar mensagens de janela, como eventos de mouse ou teclado sintéticos, para uma janela que pertence a um processo com privilégios mais altos e, ao fazer isso, controlar o processo com privilégios mais altos.
• Internet Explorer (PMIE) de modo protegido: PMIE é um recurso de defesa em profundidade no qual o Windows Internet Explorer opera em modo protegido de baixo privilégio e não pode “gravar na maioria das áreas do sistema de arquivos ou do registro. Por padrão, o modo protegido é ativado quando um usuário navega em sites no Zonas da Internet ou de sites restritos. O PMIE torna mais difícil para o malware que infecta uma instância em execução do Internet Explorer alterar as configurações do usuário, por exemplo, configurando-se para iniciar sempre que o usuário fizer logon. O PMIE não faz parte do UAC. No entanto, depende dos recursos do UAC, como UIPI.
• Detecção do instalador: quando um novo processo está prestes a ser iniciado sem direitos administrativos, o Windows aplica heurísticas para determinar se o novo processo provavelmente é uma instalação legada programa. O Windows pressupõe que os programas de instalação herdados provavelmente falharão sem direitos administrativos.Portanto, o Windows solicita proativamente ao usuário interativo a elevação. Se o usuário não tiver credenciais administrativas, ele não poderá executar o programa.

Se você desabilitar a configuração de política Controle de Conta de Usuário: Executar todos os administradores no Modo de Aprovação de Administrador, isso desabilitará todos os Recursos do UAC descritos nesta seção. Esta configuração de política está disponível por meio da Política de Segurança Local, Configurações de Segurança, Políticas Locais e Opções de Segurança do computador. Os aplicativos legados que possuem direitos de usuário padrão que esperam gravar em pastas protegidas ou chaves de registro falharão. Os tokens filtrados não são criados e todos os programas são executados com todos os direitos do usuário que está conectado ao computador. Isso inclui o Internet Explorer porque o Modo protegido está desabilitado para todas as zonas de segurança.

Um dos equívocos comuns sobre o UAC e sobre o Same-desktop Elevation em particular é que ele impede que o malware seja instalado ou ganhe direitos administrativos. Primeiro, o malware pode ser escrito para não exigir direitos administrativos e o malware pode ser escrito para escrever apenas para áreas no perfil do usuário. Mais importante, a elevação na mesma área de trabalho no UAC não é um limite de segurança e pode ser sequestrada por software sem privilégios que é executado na mesma área de trabalho. A elevação na mesma área de trabalho deve ser considerada um recurso conveniente e, de uma perspectiva de segurança, o administrador protegido deve ser considerado o equivalente a Administrador. Por outro lado, usar a Troca rápida de usuário para entrar em uma sessão diferente usando uma conta de administrador envolve um limite de segurança entre a conta de administrador e a sessão de usuário padrão.

Para uma sessão baseada no Windows servidor no qual o único motivo para logon interativo é administrar o sistema, o objetivo de menos prompts de elevação não é viável ou desejável. As ferramentas administrativas do sistema exigem legitimamente direitos administrativos. Quando todas as tarefas do usuário administrativo exigem direitos administrativos e cada tarefa pode acionar um prompt de elevação, os prompts são apenas um obstáculo à produtividade. Nesse contexto, tais prompts não podem e não podem promover o objetivo de estimular o desenvolvimento de aplicativos que requerem direitos de usuário padrão. Além disso, tais prompts não melhoram a postura de segurança. Em vez disso, esses prompts apenas incentivam os usuários a clicar nas caixas de diálogo sem lê-las.

Esta orientação se aplica apenas a servidores bem gerenciados nos quais apenas usuários administrativos podem fazer logon interativamente ou por meio de serviços de área de trabalho remota, e apenas para desempenhar funções administrativas legítimas. Se os administradores executam aplicativos arriscados, como navegadores da web, clientes de e-mail ou clientes de mensagens instantâneas, ou realizam outras operações que devem ser realizadas a partir de um sistema operacional cliente, o servidor deve ser considerado equivalente a um sistema cliente. Nesse caso, o UAC deve permanecer ativado como uma medida de defesa profunda.

Além disso, se os usuários padrão fizerem login no servidor no console ou por meio de serviços de área de trabalho remota para executar aplicativos, especialmente navegadores da web, O UAC deve permanecer habilitado para oferecer suporte à virtualização de arquivo e registro e também ao modo protegido do Internet Explorer.

Outra opção para evitar prompts de elevação sem desabilitar o UAC é definir o Controle de conta de usuário: comportamento do prompt de elevação para administradores em Admin Política de segurança do modo de aprovação para elevar sem solicitação. Usando essa configuração, as solicitações de elevação são aprovadas silenciosamente se o usuário for membro do grupo Administradores. Essa opção também deixa o PMIE e outros recursos do UAC habilitados. No entanto, nem todas as operações que exigem direitos administrativos solicitam elevação. Usar esta configuração pode resultar em alguns dos programas do usuário sendo elevados e outros não, sem nenhuma maneira de distingui-los. Por exemplo, a maioria dos utilitários de console que requerem direitos administrativos esperam ser iniciados em um prompt de comando ou outro programa que seja já elevado. Esses utilitários simplesmente falham quando são iniciados em um prompt de comando que não é elevado.

Efeitos adicionais da desativação do UAC

• Se você tentar usar o Windows Explorer para navegue até um diretório no qual você não tenha permissões de Leitura, o Explorer se oferecerá para alterar as permissões do diretório para conceder acesso de conta de usuário a ele permanentemente. Os resultados dependem se o UAC está habilitado. Para obter mais informações, consulte Quando você clique em Continuar para acessar a pasta no Windows Explorer, sua conta de usuário será adicionada à ACL da pasta.
• Se o UAC estiver desativado, o Windows Explorer continuará a exibir ícones de escudo do UAC para itens que requerem elevação e incluir Executar como administrador no menus de contexto de aplicativos e atalhos de aplicativos. Como o mecanismo de elevação do UAC está desabilitado, esses comandos não têm efeito e os aplicativos são executados no mesmo contexto de segurança que o usuário que está conectado.
• Se o UAC estiver habilitado, quando o utilitário de console Runas.exe é usado para iniciar um programa usando uma conta de usuário sujeita à filtragem de token, o programa é executado com o token filtrado do usuário. Se o UAC estiver desabilitado, o programa que é iniciado é executado com o token completo do usuário.
• Se o UAC estiver habilitado, as contas locais que estão sujeitas à filtragem de token não podem ser usadas para administração remota em interfaces de rede que não sejam a área de trabalho remota (por exemplo, através de NET USE ou WinRM). Uma conta local que autentica sobre tal interface obtém apenas os privilégios que são concedidos ao token filtrado da conta. Se o UAC estiver desabilitado, essa restrição será removida. (A restrição também pode ser removida usando a configuração LocalAccountTokenFilterPolicy descrita em KB951016.) A remoção dessa restrição pode aumentar o risco de comprometimento do sistema em um ambiente onde muitos sistemas possuem um local administrativo conta que tem o mesmo nome de usuário e senha. Recomendamos que você certifique-se de que outras atenuações sejam empregadas contra esse risco. Para obter mais informações sobre as atenuações recomendadas, consulte Mitigando ataques Pass-the-Hash (PtH) e outros roubos de credenciais, versão 1 e 2.
• PsExec, controle de conta de usuário e limites de segurança
• Quando você seleciona Continuar para acesso à pasta no Windows Explorer, sua conta de usuário é adicionada à ACL da pasta (KB 950934)