Eu tenho um cenário simples. Há um aplicativo no ServerA que é executado na conta de serviço de rede integrada. 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?

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 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 fazer para conceder acesso à conta de 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

As "Permissões de compartilhamento" podem ser "Todos / Controle total" - apenas as permissões de NTFS realmente importam. (Deixe os argumentos religiosos de pessoas que têm um apego doentio em "Permissões de compartilhamento" aqui ...)

Nas permissões NTFS na pasta no ServerB, você poderia usar "DOMÍNIO \ ServidorA - Modificar" ou "DOMÍNIO \ ServidorA - Gravar", dependendo se precisava ser capaz de modificar os arquivos existentes ou não. (Modify é realmente o preferido porque seu aplicativo pode reabrir um arquivo depois de criá-lo para escrever mais-- Modify dá esse direito, mas Write não.)

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

À parte: as funções do computador servidor mudam. Você pode querer criar um grupo no AD para esta função, colocar ServerA nesse grupo e conceder direitos ao grupo. Se você alterar a função do ServerA e substituí-la por, digamos, ServerC, você só precisa alterar as associações de grupo e nunca mais precisa tocar na permissão da pasta. Muitos administradores pensam sobre esse tipo de coisa para usuários sendo nomeados nas permissões, mas eles esquecem que "computadores são pessoas também" e suas funções às vezes mudam. Minimizar o seu trabalho no futuro (e sua capacidade de cometer erros) é o que significa ser 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 de serviço de rede no ServerA em MyDomain, isso deve ser mapeado como MyDomain \ ServerA $ (sim, o cifrão é necessário). Você vê isso com bastante frequência quando tem aplicativos 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 for uma preocupação real para você, seria criar uma conta de usuário especificamente para que esse 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. No entanto, isso pode ser um exagero.