UAC - Quando definido como "Never notify", ainda tenho um token duplo?

Question

O UAC pode ser definido para nunca notificar, mas isso não é o mesmo que não ter UAC.

O que quero dizer é que o sistema operacional ainda cria um token duplo para usuários administradores, mas apenas eleva tudo automaticamente?

A diferença é importante, pois vários sistemas operacionais de arquivos ainda se comportarão de maneira diferente, digamos, do Windows NT 4.0.

Por exemplo, quando o Explorer visualiza uma pasta com apenas Administrators:Full-Control , ele geralmente solicita que você não tenha acesso e aumente e, em seguida, adiciona automaticamente seu usuário à ACL.

Isso é o que eu pareço observar, e eu realmente não gosto disso. Ao configurar o UAC para não solicitar, suponho que essa ACL elevate-and-modify acontecerá, mas ainda está atrapalhando com as ACLs.

Em geral, desde o UAC, parece que eu gasto muito tempo sem ter direitos sobre as coisas e mexendo nas ACLs, enquanto nos dias do NT 4.0 a vida era simples, a ACL era a verdade.

Eu "obtenho" o UAC para minha sogra, mas em um servidor onde especialistas vagam?

    

Answer 1

Esta não é uma atitude saudável para ter, na minha opinião. Até mesmo especialistas cometem erros. Além disso, existem milhares de administradores de servidores no mundo que eu não chamaria exatamente de "especialistas". Você não ouve muitos admins * nix dizendo coisas como: " homem, o que BS, eu sou um especialista, eu não deveria ter que sudo ! "

Mas de qualquer forma, para sua pergunta.

Primeiro de tudo, você pergunta, (parafraseada) "se eu desabilitar o UAC, ainda terei um token restrito?"

Bem, isso depende. Quem é Você? Nem todos no sistema terão um token restrito. Somente usuários que fazem logon no sistema e que são membros de grupos privilegiados, como Administradores, Administradores de Domínio, etc., ou que têm privilégios confidenciais, como SeTcpPrivilege , etc., receberão tokens restritos além do token completo durante logon.

Consulte Windows Internals, 6a Ed. Parte I, Capítulo 6 para obter uma lista completa de quais grupos e quais privilégios são verificados antes que um token de acesso restrito seja gerado.

Uma citação do livro acima mencionado:

If one or more of these groups or privileges are present, LSASS creates a restricted token for the user (also called a filtered admin token), and it creates a logon session for both. The standard user token is attached to the initial process or processes that Winlogon starts (by default, Userinit .exe) .

Note If UAC has been disabled, administrators run with a token that includes their administrator group memberships and privileges.

E também, do capítulo 2 (a ênfase é minha):

Upon a successful authentication, LSASS calls a function in the security reference monitor (for example, NtCreateToken) to generate an access token object that contains the user’s security profile. If User Account Control (UAC) is used and the user logging on is a member of the administrators group or has administrator privileges, LSASS will create a second, restricted version of the token . This access token is then used by Winlogon to create the initial process(es) in the user’s session .

Você pode testar isso por si mesmo usando whoami /priv . Com o UAC ativado, faça logon como um usuário que seja membro do grupo Administradores. Em um prompt de comando não elevado, você verá que a lista de privilégios é muito menor no prompt de comando não elevado, o que implica a existência de dois tokens separados para o mesmo usuário:

AgoradesligueoUAC(oudefinapara"Nunca notificar"), reinicie a máquina e tente o mesmo teste. Você notará agora que não há diferença entre um processo padrão e um elevado. Não há mais token de acesso restrito.