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 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 objetos" e certificando-se de que "Computadores" esteja 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 quedeveO que estou fazendo para conceder à conta de serviço de rede do ServerA acesso ao compartilhamento do ServerB?
Observação:
Eu sei que isso é semelhante aessa questão. No entanto, no meu cenário, ServerA e ServerB estão no mesmo domínio.
Responder1
As "Permissões de compartilhamento" podem ser "Todos/Controle total" - apenas as permissões NTFS realmente importam. (Veja argumentos religiosos de pessoas que têm um apego prejudicial às "Permissões de compartilhamento" aqui...)
Nas permissões NTFS na pasta no ServerB você pode usar "DOMAIN\ServerA - Modify" ou "DOMAIN\ServerA - Write", dependendo se é necessário modificar 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.)
Somente os contextos "SYSTEM" e "Network Service" no ServerA terão acesso, desde 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 teriam que ser nomeadas individualmente se você de alguma forma desejasse conceder-lhes acesso).
Como um aparte: as funções do computador servidor mudam. Você pode querer criar um grupo no AD para esta função, colocar o ServidorA nesse grupo e conceder direitos ao grupo. Se você alterar a função do ServerA e substituí-la por, digamos, ServerC, precisará apenas alterar as associações ao grupo e nunca mais precisará tocar na permissão da pasta. Muitos administradores pensam nesse tipo de coisa para usuários sendo nomeados em permissões, mas esquecem que “computadores também são pessoas” e suas funções às vezes mudam. Minimizar seu trabalho no futuro (e sua capacidade de cometer erros) é o que significa ser eficiente neste jogo...
Responder2
A conta de serviço de rede de um computador será mapeada para outro computador confiável como a conta do nome do computador. Por exemplo, se você estiver executando como 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 bastante quando tem aplicativos IIS em execução como a conta de serviço de rede conectando-se a um SQL Server em um servidor diferente, como uma instalação ampliada do SSRS ou do Microsoft CRM.
Responder3
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 esse aplicativo/serviço ser executado e conceder a essa conta as permissões necessárias para a pasta compartilhada. Dessa forma, você pode ter certeza de que apenas aquele aplicativo/serviço está acessando o compartilhamento. Isso pode ser um exagero.