Учетная запись сетевой службы для доступа к общей папке

У меня простой сценарий. На сервере A есть приложение, которое работает под встроенной учетной записью сетевой службы. Он должен читать и записывать файлы в общую папку на ServerB. Какие разрешения мне нужно установить для общего ресурса папки на ServerB?

Я могу заставить его работать, открыв диалоговое окно безопасности общего ресурса, добавив нового пользователя безопасности, нажав «Типы объектов» и убедившись, что «Компьютеры» отмечены, а затем добавив ServerA с доступом для чтения / записи. Таким образом, какие учетные записи получают доступ к общему ресурсу? Только сетевой сервис? Все локальные учетные записи на сервере А? Что должен я делать , чтобы предоставить доступ к учетной записи Network Service SERVERA, чтобы поделиться ServerB в?

Примечание:
я знаю, что это похоже на этот вопрос . Однако в моем сценарии ServerA и ServerB находятся в одном домене.

«Разрешения общего доступа» могут быть «Все / Полный доступ» - действительно имеют значение только разрешения NTFS. (Здесь приводятся религиозные аргументы людей, которые имеют нездоровую привязанность к «Разрешению на доступ») ...

В разрешениях NTFS для папки на ServerB вы могли обойтись либо «DOMAIN \ ServerA - Modify», либо «DOMAIN \ ServerA - Write», в зависимости от того, нужно ли было иметь возможность изменять существующие файлы или нет. (Модификация действительно предпочтительна, потому что ваше приложение может повторно открыть файл после того, как оно создаст его для дальнейшей записи - Модификация дает ему это право, а запись - нет.)

Только контексты «SYSTEM» и «Network Service» на ServerA будут иметь доступ, при условии, что в разрешении вы укажете «DOMAIN \ ServerA». Учетные записи локальных пользователей на компьютере ServerA отличаются от контекста «DOMAIN \ ServerA» (и должны были бы называться по отдельности, если бы вы каким-то образом хотели предоставить им доступ).

Как в стороне: серверные роли компьютера меняются. Возможно, вы захотите создать группу в AD для этой роли, поместить ServerA в эту группу и предоставить права группы. Если вы когда-нибудь измените роль ServerA и замените ее, скажем, ServerC, вам нужно всего лишь изменить членство в группе, и вам больше не нужно снова трогать разрешение на доступ к папке. Многие администраторы думают о таких вещах для пользователей, которых называют в разрешениях, но они забывают, что «компьютеры тоже люди» и их роли иногда меняются. Минимизация вашей работы в будущем (и вашей способности делать ошибки) - вот что значит быть эффективным в этой игре ...

Учетная запись сетевой службы компьютера будет сопоставлена ​​с другим доверенным компьютером в качестве учетной записи имени компьютера. Например, если вы работаете в качестве учетной записи сетевой службы на сервере ServerA в MyDomain, она должна отображаться как MyDomain \ ServerA $ (да, знак доллара необходим). Это довольно заметно, когда у вас есть приложения IIS, работающие в качестве учетной записи сетевой службы, подключающейся к SQL Server на другом сервере, например, при уменьшенной установке SSRS или Microsoft CRM.

Я согласен с Эваном. Однако я считаю, что идеальным решением, если безопасность представляет для вас реальную проблему, было бы создание учетной записи пользователя, специально предназначенной для этого приложения / службы, и предоставление этой учетной записи необходимых разрешений для общей папки. Таким образом, вы можете быть уверены, что только это приложение / служба имеет доступ к общему ресурсу. Это может быть излишним, хотя.