Redirecionamento de pastas GP e herança / escopo CREATOR OWNER

1

Usamos a política de grupo de redirecionamento de pastas para colocar as pastas Meus documentos dos usuários em um compartilhamento de rede.

Configuramos o compartilhamento com as permissões NTFS recomendadas pela Microsoft, conforme definido aqui: link . Especificamente:

  • CREATOR OWNER - Full Control (Apply onto: Subfolders and Files Only)
  • System - Full Control (Apply onto: This Folder, Subfolders and Files)
  • Domain Admins - Full Control (Apply onto: This Folder, Subfolders and Files)
  • Everyone - Create Folder/Append Data (Apply onto: This Folder Only)
  • Everyone - List Folder/Read Data (Apply onto: This Folder Only)
  • Everyone - Read Attributes (Apply onto: This Folder Only)
  • Everyone - Traverse Folder/Execute File (Apply onto: This Folder Only)

No entanto, esse artigo da base de conhecimento também declara (pontos-chave em negrito):

By the end of May 2017, all supported operating systems converted the CREATOR OWNER ACE to:

    <Folder-User> - Full Control (Apply onto: This Object only)

Whereas this does not affect the daily operations of the folders for the users, it makes a difference when the administrator has to work on the contents of the home folders or redirected folders.

If you want to make sure the user to get the inheritable full control on all child objects, you have to:

Create the folder matching for the users samaccountname by yourself. Set the permissions that are needed for the folder, omit the Everyone ACEs above, and make sure that you have the ACE:

    <Folder-User> - Full Control (Apply onto: This Folder, Subfolders and Files)

Em outras palavras, se SYSTEM criar uma subpasta na pasta de um usuário, o usuário não poderá acessar essa subpasta porque não herdará mais o controle total, como costumava fazer.

A solução alternativa da Microsoft para isso é criar manualmente a pasta raiz do usuário e definir manualmente as permissões do usuário com o escopo necessário.

Existe alguma maneira de automatizar isso via política de grupo, ou a única opção aqui é o script?

    
por morbiD 05.07.2018 / 14:24

1 resposta

0

Esse é o comportamento esperado para o PROPRIETÁRIO CRIADOR, e é improvável que tenha sido diferente; Eu acho que o adendo ao artigo é enganoso a esse respeito. Na minha experiência, normalmente não seria um problema, porque geralmente você não quer adicionar coisas à pasta do usuário. É provavelmente por isso que o artigo original nunca mencionou isso.

Se você não for criar o diretório de cada usuário antecipadamente com permissões explicitamente escolhidas, no que se refere à diretiva de grupo, você terá apenas duas opções: se você definir a opção "Conceder direitos exclusivos do usuário", elas acesso total a toda a pasta e conteúdo, mas ninguém mais faz isso; se você não definir, eles só terão acesso ao conteúdo criado por eles mesmos.

Se você escolher a primeira opção, poderá usar o privilégio de backup para ignorar as permissões sempre que quiser adicionar conteúdo. Isso é elegante, mas pode ser inconveniente porque as ferramentas internas para usar o privilégio de backup são bastante limitadas.

Se você escolher a segunda opção, poderá alterar as permissões na pasta do usuário antes de adicionar conteúdo; ou você pode definir explicitamente as permissões no conteúdo que você está adicionando.

Outra abordagem (como você sugere) é usar um script de logon de política de grupo para alterar as permissões na pasta do usuário quando o usuário fizer login pela primeira vez. Essa pode ser a opção mais conveniente se o processo estiver adicionando conteúdo à pasta do usuário não está sob seu controle.

    
por 06.07.2018 / 12:50