У меня простой сценарий. На сервере ServerA есть приложение, которое работает под встроенной учетной записью Network Service. Ему нужно читать и записывать файлы в папке общего доступа на сервере ServerB. Какие разрешения мне нужно установить для папки общего доступа на сервере ServerB?
Я могу заставить его работать, открыв диалоговое окно безопасности общего ресурса, добавив нового пользователя безопасности, нажав «Типы объектов» и убедившись, что «Компьютеры» отмечены, а затем добавив ServerA с доступом на чтение/запись. При этом какие учетные записи получают доступ к общему ресурсу? Только сетевая служба? Все локальные учетные записи на ServerA? ЧтодолженЧто мне нужно сделать, чтобы предоставить учетной записи сетевой службы ServerA доступ к общему ресурсу ServerB?
Примечание:
Я знаю, что это похоже наэтот вопрос. Однако в моем сценарии ServerA и ServerB находятся в одном домене.
решение1
«Разрешения на общий доступ» могут быть «Все/Полный доступ» — только разрешения NTFS имеют значение. (Здесь можно привести религиозные аргументы людей, имеющих нездоровую привязанность к «Разрешениям на общий доступ»…)
В разрешениях NTFS для папки на сервере ServerB можно обойтись либо «DOMAIN\ServerA - Modify», либо «DOMAIN\ServerA - Write», в зависимости от того, требуется ли изменять существующие файлы или нет. (Изменение на самом деле предпочтительнее, поскольку ваше приложение может повторно открыть файл после его создания для дальнейшей записи — Изменение дает ему такое право, а Запись — нет.)
Только контексты "SYSTEM" и "Network Service" на ServerA будут иметь доступ, предполагая, что вы указали "DOMAIN\ServerA" в разрешении. Локальные учетные записи пользователей на компьютере ServerA отличаются от контекста "DOMAIN\ServerA" (и должны быть названы индивидуально, если вы каким-то образом хотите предоставить им доступ).
В качестве отступления: роли серверных компьютеров меняются. Вы можете создать группу в AD для этой роли, поместить ServerA в эту группу и предоставить группе права. Если вы когда-нибудь измените роль ServerA и замените ее, скажем, на ServerC, вам нужно будет только изменить членство в группе, и вам больше никогда не придется трогать разрешения для папки. Многие администраторы думают о таких вещах для пользователей, именуемых в разрешениях, но они забывают, что «компьютеры тоже люди», и их роли иногда меняются. Минимизация вашей работы в будущем (и вашей способности совершать ошибки) — вот что такое эффективность в этой игре...
решение2
Учетная запись сетевой службы компьютера будет сопоставлена с другим доверенным компьютером как учетная запись имени компьютера. Например, если вы работаете как учетная запись сетевой службы на ServerA в MyDomain, она должна отображаться как MyDomain\ServerA$ (да, знак доллара необходим). Вы видите это довольно часто, когда у вас есть приложения IIS, работающие как учетная запись сетевой службы, подключающиеся к SQL Server на другом сервере, например, масштабируемая установка SSRS или Microsoft CRM.
решение3
Я согласен с Эваном. Однако я считаю, что идеальным решением, если безопасность для вас действительно важна, было бы создание учетной записи пользователя специально для этого приложения/службы, которая будет запускаться, и предоставление этой учетной записи необходимых разрешений на общую папку. Таким образом, вы можете быть уверены, что только это приложение/служба имеет доступ к общей папке. Хотя это может быть излишним.