TL; DR: Crie outro grupo em paralelo com o grupo Administradores local e adicione todos os que estiverem autorizados a ser administradores em ambos os grupos. Em seguida, permita que o segundo grupo esteja na ACL para todos os arquivos e pastas. Não faça logon ou opere como o usuário Administrador interno.
Este problema tem me incomodado por um bom tempo. É frustrante ter que me remover constantemente de ACLs de pasta (assim como de outros usuários que não se limparam) enquanto eu navego por várias estruturas de pastas. Então, eu li o artigo mencionado na pergunta. Isso me deu o entendimento que eu precisava para escrever essa resposta, e eu recomendo lê-la antes de continuar.
O ponto da pergunta original que me incomodou foi a afirmação dos autores de que "torna o gerenciamento central de permissões efetivamente impossível". Inicialmente, eu concordei com isso, mas depois de pensar sobre isso, lembrei-me do ponto principal do princípio de
"Menor Privilégio" . Um dos propósitos da conta de Administrador local, bem como do grupo Administradores local, é violar esse Princípio. Em última análise, você não pode tirar nada desse usuário ou membros desse grupo. Sim, no termo imediato eles podem ser negados, mas eles ainda têm a capacidade (sem usar explorações) para derrotar a negação, concedendo-se acesso a qualquer recurso que foi negado. Assim, parece que a Microsoft acredita que sempre deve haver pelo menos um usuário que sempre possa acessar tudo, de alguma forma. Justo. Esse argumento está além do escopo desta resposta.
Então, como isso afeta o "gerenciamento central de permissões"? Parece que para estar em conformidade com o Princípio, você precisa fingir (eu explicarei a metade depois) que o Administrador local e o grupo de Administradores locais não existem. Lembre-se, eles não podem ter seus privilégios limitados, o que significa que eles violam o Princípio. É por isso que a senha dessa conta é mantida secretamente e a participação nesse grupo é tão cobiçada. Então, se você quiser o mesmo acesso efetivo, na raiz de cada unidade, você precisa ter seu próprio usuário ou grupo que tenha Controle Total, que seria (idealmente) herdado por todas as subpastas e arquivos.
Sabemos, no entanto, que na prática esse usuário ou grupo será rotineiramente negado o acesso, mas isso faz parte do ponto. O "Administrador" deve ser o árbitro final de quem tem ou não acesso a qualquer arquivo ou pasta. O "Administrador" é incorporado nesse usuário fixo. Sim, muitos de nós operamos como "Administrador" como uma questão de conveniência, mas quando fazemos isso, estamos violando o Princípio. Então, para lidar com isso, podemos convenientemente lembrar (esta é a metade da parte fingida) que o grupo Administradores existe e que podemos ser membros dele. Podemos conceder ao grupo (ou usuário) mencionado acima (que pode ser nós mesmos) acesso ao recurso (que deveria ter herdado a permissão em primeiro lugar) e não se preocupar com requisitos de conformidade ou segurança porque esse grupo (ou usuário) já autorização para esse recurso, porque eles já estão autorizados a agir como "Administrador".
Há uma pegadinha nisso, no entanto. Eu ainda não queria desistir da conveniência de fazer login como "Administrador", então adicionei esse usuário ao grupo - e ele ainda não funcionou. Esse usuário é um usuário fixo e é especial, e sem desabilitar o UAC, não há como remover essa qualidade "especial" dele. Mas esse é o ponto. A Microsoft está tentando nos direcionar mais para a conformidade com o Princípio. Ao adicionar meu usuário a ambos os grupos, consegui me conceder acesso ao recurso, permanecer em conformidade e seguro e evitar o diálogo irritante.
