Conta do Serviço de Rede acessando um compartilhamento de pasta

Question

Eu tenho um cenário simples. Há um aplicativo no ServerA que é executado sob a conta interna do Serviço de Rede. Ele precisa ler e gravar arquivos em um compartilhamento de pasta no ServerB. Quais permissões eu preciso definir no compartilhamento de pasta no ServerB?

Eu posso fazê-lo funcionar abrindo a caixa de diálogo de segurança do compartilhamento, adicionando um novo usuário de segurança, clicando em "Tipos de objeto" e verificando se "Computadores" está marcado e adicionando ServerA com acesso de leitura / gravação. Ao fazer isso, quais contas estão obtendo acesso ao compartilhamento? Apenas serviço de rede? Todas as contas locais no ServerA? O que devo estar fazendo para conceder acesso à conta do Serviço de Rede do ServerA ao compartilhamento do ServerB?

Nota:
Eu sei que isso é semelhante a esta pergunta . No entanto, no meu cenário ServerA e ServerB estão no mesmo domínio.

    

Answer 1

As "Permissões de Compartilhamento" podem ser "Todos / Controle Total" - somente as permissões NTFS realmente importam. (Cue argumentos religiosos de pessoas que têm um anexo insalubre a "Permissões de compartilhamento" aqui ...)

Nas permissões de NTFS na pasta no ServerB, você poderia obter "DOMAIN \ ServerA - Modify" ou "DOMAIN \ ServerA - Write", dependendo se precisava modificar os arquivos existentes ou não. (Modificar é realmente o preferido porque seu aplicativo pode reabrir um arquivo depois de criá-lo para gravar mais - Modificar, mas Write não.)

Apenas os contextos "SYSTEM" e "Network Service" no ServerA terão acesso, supondo que você nomeie "DOMAIN \ ServerA" na permissão. As contas de usuários locais no computador ServerA são diferentes do contexto "DOMAIN \ ServerA" (e teriam de ser nomeadas individualmente se você, de alguma forma, quisesse conceder acesso a elas).

Como um aparte: as funções do computador servidor são alteradas. Você pode querer criar um grupo no AD para essa função, colocar ServerA nesse grupo e conceder os direitos de grupo. Se você alterar a função do ServerA e substituí-la por, digamos, ServerC, só precisará alterar as associações de grupo e nunca mais precisar tocar na permissão de pasta novamente. Muitos administradores pensam sobre esse tipo de coisa para os usuários serem nomeados em permissões, mas esquecem que "os computadores também são pessoas" e seus papéis às vezes mudam. Minimizar o seu trabalho no futuro (e sua capacidade de cometer erros) é o objetivo de ser eficiente neste jogo ...

    

Answer 2

A conta de serviço de rede de um computador será mapeada para outro computador confiável como a conta de nome do computador. Por exemplo, se você estiver executando como a conta do serviço de rede no ServerA em MyDomain, isso deve mapear como MyDomain \ ServerA $ (sim, o sinal de dólar é necessário). Você vê isso um pouco quando você tem aplicativos IIS sendo executados como a conta do Serviço de Rede conectando-se a um SQL Server em um servidor diferente, como uma instalação reduzida do SSRS ou do Microsoft CRM.

    

Answer 3

Eu concordo com o Evan. No entanto, acredito que a solução ideal, se a segurança é uma preocupação real para você, seria criar uma conta de usuário especificamente para que o aplicativo / serviço seja executado e conceder a essa conta as permissões necessárias para a pasta compartilhada. Dessa forma, você pode ter certeza de que apenas esse aplicativo / serviço está acessando o compartilhamento. Isso pode ser um exagero.