Replicação DFS e o usuário SYSTEM (permissões NTFS)

Pergunta para a qual estou tendo problemas para encontrar uma resposta no Google ou no Technet ...

A concessão de SYSTEMpermissões de usuário para arquivos e pastas compartilhados pelo DFS afeta a replicação do DFS? (E enquanto estamos nisso, existe algum bom motivo para não permitir SYSTEMpermissões para arquivos compartilhados pelo DFS?)

Aparece porque eu tenho uma coleção de namespaces e pastas do DFS que não consigo solucionar o problema de outra pessoa e, enquanto solucionava um problema em que uma réplica do DFS simplesmente não estava se replicando por outra sem motivo aparente, observei que o SYSTEMA conta não possui permissões concedidas a nenhum dos arquivos ou pastas da pasta em questão.

Então, eu decidi SYSTEMter o controle total e propagá-lo para baixo, e nossos relatórios de diagnóstico de integridade do DFS passaram de mostrar uma lista de pendências de ~ 80 arquivos para uma lista de pendências de ~ 100.000 ... e as coisas começaram a ser replicadas, incluindo vários arquivos que estavam faltando em um servidor ou no outro (mais do que apenas as alterações de permissões começaram a se replicar).

Naturalmente, isso me deixou curioso para saber se o DFS precisa ou não da SYSTEMconta para ter permissão para executar seu trabalho ou se foi apenas alguma alteração na árvore de pastas em questão que levou o DFS a entrar em ação. Se isso for importante, nossos namespaces do DFS foram configurados em 2000/2003, e acabei de atualizar recentemente todos os servidores para 2008 R2 ou 2012 (com o UAC ativado, blech), mas ainda não consegui elevar o namespace do DFS funcional níveis para o Server 2008.

(E pontos de bônus se alguém tiver um artigo oficial da Microsoft sobre permissões de arquivo NTFS e a SYSTEMconta no que diz respeito ao DFS ou aos arquivos de rede.)

Este tópico no technet diz que SYSTEM precisa de controle total. No entanto, não é uma fonte muito oficial, e mais testes provam que está errado .

Serviço de Replicação DFS

Examinei os serviços DFS na minha máquina Server 2008R2 com o Process Explorer. O dfsrs.exe, o serviço de Replicação do Sistema de Arquivos Distribuídos, é executado como "NT Authority \ SYSTEM". No entanto, ele possui SeBackupPrivilege e SeRestorePrivilege :

Das constantes de privilégio da Microsoft :

SeBackupPrivilege - Necessário para executar operações de backup. Esse privilégio faz com que o sistema conceda todo o controle de acesso de leitura a qualquer arquivo, independentemente da lista de controle de acesso (ACL) especificada para o arquivo. Qualquer solicitação de acesso que não seja de leitura ainda é avaliada com a ACL. 3

SeRestorePrivilege - Necessário para executar operações de restauração. Esse privilégio faz com que o sistema conceda todo o controle de acesso de gravação a qualquer arquivo, independentemente da ACL especificada para o arquivo. Qualquer solicitação de acesso que não seja gravação ainda é avaliada com a ACL. Além disso, esse privilégio permite definir qualquer SID de usuário ou grupo válido como o proprietário de um arquivo.

Com essas permissões, o Serviço de Replicação DFS pode ignorar todas as permissões de arquivo - recebe permissão para ler, gravar e definir permissões em qualquer arquivo que desejar.

Teste

Criei uma pasta em um dos meus compartilhamentos DFS com alguns arquivos, defini minha conta como proprietário e removi todas as permissões, exceto a minha conta.

O DFS o replicou para todos os outros servidores sem problemas, e todas as réplicas tinham as mesmas permissões.

Portanto, o DFS não depende de nenhuma permissão do sistema de arquivos para replicar.

Eu suspeito que, no seu caso, simplesmente fazer alterações nos arquivos faria com que o DFS fosse ativado e verifique se eles precisavam ser replicados. Não faço ideia do que teria causado essa situação em primeiro lugar.

De acordo com este artigo da Microsoft http://support.microsoft.com/kb/120929 "A conta do sistema e a conta de administrador (grupo Administradores) têm os mesmos privilégios de arquivo, mas têm funções diferentes."

Isso significa que a conta do sistema é igual a um administrador local e existe com a finalidade de executar serviços do sistema com os privilégios de um administrador sem exigir uma senha. O processo de replicação no DFS-R é realizado com esta conta.

O usuário do sistema não tem significado especial no sistema de arquivos ou na configuração do DFS, diferente de um administrador comum. No entanto, isso pode se tornar confuso porque os administradores do Windows nem sempre estão operando com privilégios administrativos, dependendo de como o programa ou shell foi chamado, enquanto uma conta do sistema provavelmente sempre funcionaria com o token de administrador / escalado. Suponho que sua configuração do DFS estivesse apenas com erros e a modificação de ACLs talvez tenha causado alguns syscalls ou a abertura / atualização de identificadores de arquivos que sacudiram as proverbiais teias de aranha.