Conta de serviço de rede acessando um compartilhamento de pasta

Eu tenho um cenário simples. Há um aplicativo no ServerA que é executado na 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 pastas no ServerB?

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, em seguida, adicionando o ServidorA 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 fazer 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.

As "Permissões de compartilhamento" podem ser "Todos / Controle total" - somente as permissões NTFS são realmente importantes. (Sugira argumentos religiosos de pessoas que têm um apego prejudicial a "Compartilhar Permissões" aqui ...)

Nas permissões NTFS na pasta no ServerB, você pode conviver com "DOMAIN \ ServerA - Modify" ou "DOMAIN \ ServerA - Write", dependendo se é necessário modificar os arquivos existentes ou não. (Modificar é realmente o preferido, porque seu aplicativo pode reabrir um arquivo depois que ele for criado para ser gravado ainda mais - o Modify concede esse direito, mas o Write não.)

Somente os contextos "SISTEMA" e "Serviço de rede" no ServerA terão acesso, assumindo que você nomeie "DOMAIN \ ServerA" na permissão. As contas de usuário local no computador ServerA são diferentes do contexto "DOMAIN \ ServerA" (e precisariam ser nomeadas individualmente se você, de alguma forma, quisesse conceder acesso a elas).

Como um aparte: As funções do computador servidor mudam. Você pode criar um grupo no AD para essa função, colocar ServerA nesse grupo e conceder direitos ao grupo. Se você mudar a função do ServerA e substituí-la por, digamos, ServerC, precisará alterar apenas as participações no grupo e nunca precisará tocar na permissão da 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 suas funções às vezes mudam. Minimizar o seu trabalho no futuro (e sua capacidade de cometer erros) é o que é eficiente neste jogo.

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 no MyDomain, isso deve ser mapeado como MyDomain \ ServerA $ (sim, o cifrão é necessário). Você vê isso bastante quando tem aplicativos do IIS em execução como a conta do Serviço de Rede conectando-se a um SQL Server em um servidor diferente, como uma instalação em escala reduzida do SSRS ou do Microsoft CRM.

Eu concordo com 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 a execução desse aplicativo / serviço 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 embora.