Usando o ICACLS para definir permissões nos diretórios do usuário


16

Estou tentando redefinir as permissões nos diretórios do usuário e tendo alguns problemas com a última etapa do meu script. Meu script basicamente toma posse de todo o diretório do usuário, redefine as permissões em todos os arquivos e pastas do diretório, concede explicitamente as permissões necessárias, interrompe toda a herança de permissões das pastas pai, define o proprietário legítimo (usuário especificado) para todos os arquivos e pastas e, em seguida, remove a permissão que dei a mim mesmo para poder operar com os arquivos. Preciso desta última etapa para me remover de TODOS os arquivos e subpastas, mas no momento isso me remove do% userDir% e deixa todas as permissões herdadas abaixo. Essa é uma aparente deficiência no ICACLS. Alguém sabe de outra maneira de conseguir isso?

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /inheritance:r
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%"

Estou brincando com o script XCACLS.vbs não suportado criado pela Microsoft e tive sorte em empregá-lo na última linha do meu script. Em vez deste ICACLS "E: \ Diretórios Domésticos \% userDir%" / remova "MYDOMAIN \% username%", substituí-lo por cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username% "Isso funciona, mas eu realmente gostaria de evitar o uso do XCACLS.vbs, pois há problemas graves de desempenho. Alguma outra ideia?
pk.

Respostas:


18

Uma observação primeiro: toda vez que você bloqueia a herança, está se afastando da flexibilidade futura. Evito bloquear a herança a todo custo.

Se você precisar que os usuários possam listar o conteúdo da pasta "E: \ Home Directories" de nível superior, por exemplo, considere a seguinte permissão:

  • SISTEMA - Controle total - Aplicado a esta pasta, subpastas e arquivos
  • BUILTIN \ Administradores - Controle total - Aplicado a esta pasta, subpastas e arquivos
  • BUILTIN \ Usuários autenticados - Leitura e execução - Aplicados somente a esta pasta

A última permissão não herda as subpastas. Em cada subpasta, a herança permanece ativada e você simplesmente especifica o usuário com os direitos "Modificar" ou "Controle total" (dependendo de como se sente sobre os usuários poderem definir permissões dentro do diretório inicial). (Normalmente, defino essa última permissão adicionando "Usuários autenticados" na folha de propriedades de segurança não "Avançada", desmarcando as caixas de seleção "Ler" e "Ler e executar". Em seguida, prossigo na caixa de diálogo "Avançado" e altero o Configuração "Aplicar em" para esse ACE como "Somente esta pasta". Essa é a maneira mais fácil, em termos de número de cliques, de defini-la.)

Então, seu script se torna:

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%" /setowner "MYDOMAIN\%userDir%" /T

Eu suspeito fortemente que a adição da permissão "Usuários autenticados" que descrevi acima com a herança definida como "Somente esta pasta" fornecerá o que você procura em funcionalidade e flexibilidade futura se descobrir que você precisa definir uma permissão que talvez precise herdar em todos os diretórios pessoais do usuário no futuro.

Este é o meu SOP para diretórios pessoais do usuário, redirecionados "Meus Documentos", "Área de Trabalho", pastas etc, e para diretórios de perfil de usuário móvel. Isso funciona muito bem.

Editar

re: seu comentário sobre BUILTIN \ Administrators access

Eu tive vários argumentos com pessoas sobre minha opinião sobre a concessão de acesso BUILTIN \ Administrators ao longo dos anos, e minha opinião é a seguinte:

  • É mais fácil resolver uma determinada classe de problemas do usuário se você puder acessar os arquivos deles. É difícil "tomar posse" e pode ser bastante lento se houver um grande número de arquivos também.

  • Como você viu no ICACLS, BUILTIN \ Administrators pode "atribuir" propriedade (além de "tomá-la"), para que não haja "segurança" adicionada por não ter os arquivos acessíveis para BUILTIN \ Administrators em primeiro lugar.

  • A menos que você esteja usando auditoria (e examinando um número potencialmente grande de entradas falso-positivas), não haverá uma trilha de auditoria quando um usuário BUILTIN \ Administrators se apropriar dos arquivos que eles não deveriam acessar, copiá-los e depois retorna os arquivos de volta ao proprietário e à permissão "adequados".

  • No mundo da Microsoft, o sistema de arquivos com criptografia (EFS) visa solucionar o problema de impedir que o acesso não autorizado ao BUILTIN \ Administrators ocorra. As ACLs NTFS não resolvem esse problema. (Obviamente, o EFS não é o único programa da cidade. A criptografia é a resposta real para resolver o problema "limitar o acesso do administrador da rede", não importa como você o divide.)

Na minha opinião, não especificar BUILTIN \ Administrators com acesso aos diretórios pessoais do usuário (e, de fato, a qualquer pasta) significa que você está aumentando a complexidade e o tempo necessário para resolver problemas, fornecendo menos do que nenhuma segurança real ("menos que nenhum "porque transmite uma falsa sensação de segurança onde não há).

Eu desisti de tentar ganhar a discussão com as pessoas por meio da lógica. Parece ser um problema emocional com algumas pessoas. É como o ACE bobo "Negar / Receber como" que é colocado na raiz de uma organização do Exchange para impedir que certos grupos privilegiados abram as caixas de correio dos usuários. Ele não oferece segurança real (já que sem a auditoria pode-se remover / reaplicar o ACE conforme necessário), uma falsa sensação de segurança e atrapalha a solução de problemas reais.

Mesmo que você não goste do meu argumento sobre o acesso de BUILTIN \ Administrators, você deseja manter intacta a hierarquia de herança usando a herança "Somente esta pasta", quando apropriado. Bloquear a herança nas hierarquias de permissão é um sinal claro de que algo no design está "quebrado" (invertido, etc.).


11
Você recomenda conceder ao BUILTIN \ Administrators acesso total a toda a estrutura de diretórios? Sou da opinião de que nós (administradores) realmente não devemos ter acesso total aos diretórios / perfis de usuários de todos sem nos apropriarmos.
pk.

+1, amo os pontos sobre a falsa sensação de segurança ...
DCookie

1

Primeiro, obrigado pelo trecho do roteiro. Eu tenho trabalhado na mesma coisa, mas estava preso em um lugar diferente. Na minha caixa do SBS 2008, o código abaixo funciona para mim (supondo que sua execução seja elevada, é claro). Fiz um icacls% userdir% / t de uma pasta de usuário nova (padrão) criada pelo sistema operacional e a comparei com icacls% userdir% / t de uma pasta depois de executar esse script e parece com todos os "O's e Eu "está correto. Espero que funcione para você também.

set /p userDir=Enter the login of the user's directory you're modifying permissions for. (i.e. jDoe)
TAKEOWN /f "E:\Home Directories\%userDir%" /r /d y
ICACLS "E:\Home Directories\%userDir%" /reset /T
ICACLS "E:\Home Directories\%userDir%" /grant:r "MYDOMAIN\%userDir%":(oi)(ci)f
ICACLS "E:\Home Directories\%userDir%\*.*" /grant:r "SYSTEM":(OI)(CI)F /grant:r "MYDOMAIN\%userDir%":(OI)(CI)F /grant:r "MYDOMAIN\%username%":(OI)(CI)F
ICACLS "E:\Home Directories\%userDir%\*.*" /inheritance:r
ICACLS "E:\Home Directories\%userDir%\*.*" /setowner "MYDOMAIN\%userDir%" /T
ICACLS "E:\Home Directories\%userDir%" /remove "MYDOMAIN\%username%" /t

Cumprimentos,

 -d

Certifique-se de verificar a linha final do seu script. Foi minha experiência que o ICACLS não removerá com êxito as permissões herdadas. Ele remove a entrada na pasta "MYDOMAIN \% username%", mas as permissões das subpastas são intocadas. Portanto, "MYDOMAIN \% username%" ainda terá acesso às subpastas se acessadas diretamente, você não poderá navegar nelas. XCACLS.vbs resolveu isso para mim. cscript.exe xcacls.vbs "e: \ Test" / E / R "MYDOMAIN \% username%"
pk.

É aí que o . parte entrou na minha edição. doing / herança: r na pasta pai, tive o mesmo problema. mas fazendo isso . na pasta pai parecia fazer o truque. Após executar o procedimento acima,% userdir% possui% nome de usuário%, sistema e administradores, mas tudo abaixo dele é apenas% nome de usuário% e sistema, que é como o servidor os configurou inicialmente - exatamente o que eu queria.

-1

Preciso da sua ajuda para modificar este comando de acordo com meus requisitos, se isso for tecnicamente possível.

Aqui está a estrutura

\ Server \ Parent \ UserA \ unix

\ Server \ Parent \ UserB \ unix

\ Server \ Parent \ UserC \ unix .... e assim por diante ..

Em cada pasta do usuário $, há uma pasta chamada "unix".

Desejo adicionar um usuário ou grupo com permissões completas em todas as pastas User $ listadas na pasta "Pai" (nomes tirados da estrutura acima), mas quero excluir permissões apenas na pasta "unix".

Eu tenho esse comando que funciona bem para mim na perspectiva da aplicabilidade das permissões necessárias, mas não posso adicionar a função de exclusão nisso.

icacls "\\ Servidor \ Pai \ UsuárioA" / conceder Domínio \ Grupo: (OI) (CI) F / T

Você será capaz de orientar nesse cenário?


11
Olá e bem-vindo à falha do servidor! Por favor, não faça perguntas via resposta. Use o botão Fazer pergunta para postar sua solicitação.
Sr. Shunz 18/09/18
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.