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