У меня есть приложение IIS, работающее на сервере A. Ему нужна возможность записи в папку на общем ресурсе UNC, в настоящее время на сервере B. Я хотел бы сохранить общий ресурс на сервере B, но в этой среде нет Windows Active Directory. домен - до этого момента мы обходили эту проблему, запуская любую данную службу (например, БД) под учетной записью, имя пользователя и пароль которой будут реплицированы на любые другие серверы, к которым службе необходим доступ. До этого момента мы не знали, что приложению IIS необходим доступ «в доменном стиле» к каким-либо другим ресурсам, для которых у него еще не было альтернативных методов аутентификации.
В приложении IIS есть настройка Identity: ApplicationPoolIdentity, что, как я понимаю, заставляет его работать под SID IIS AppPool\AppPoolName
Итак, после некоторых первоначальных исследований и выводов я пришел к следующим возможностям, упорядоченным от наименее к наиболее элегантным. Мои комментарии курсивом.
Переместите общий ресурс на сервер A.
Не совсем то, что я хочу сделать - потребовалось бы множество реконфигураций существующих сервисов, несовместимых с другой инфраструктурой.
Переместите указанную папку в новый общий ресурс на сервере B с доступом для анонимной записи.
Это, по крайней мере, сохранит все мои общие ресурсы на одном сервере, но безопасность посредством неизвестности на самом деле не в моем стиле.
Перенастройте приложение IIS для работы с явным именем пользователя и паролем, чтобы оно было реплицировано на сервере B для предоставления доступа к общей папке.
По крайней мере, я думаю, это достигнет того, что я хочу, но изменение идентификатора кажется рискованным и потенциально чревато непредсказуемыми последствиями для приложения.
Дайте идентификатору пула приложений на сервере A сохраненные учетные данные для имени пользователя и пароля, которые позволят получить доступ к общему ресурсу на сервере B.
Не знаю, сработает ли это на самом деле, или если вы даже можете предоставить сохраненные учетные данные для идентификаторов безопасности, которые изначально не являются полными учетными записями пользователей. Просто идея, но мне она нравится, поскольку она не влияет на существующую конфигурацию приложения IIS.
Используйте ACL на общем ресурсе, чтобы предоставить доступ к «Учетной записи компьютера» на сервере A.
это кажется как Святой Грааль, поскольку это рекомендуемый метод («Удостоверения пула приложений также используют учетную запись компьютера для доступа к сетевым ресурсам»), но, конечно, эти машины не привязаны к домену Windows, что является необходимым условием для использования учетной записи компьютера.
В идеале я хотел бы найти хак или кладж, который бы выполнил пункт 5 или какой-либо другой способ предоставления доступа исключительно путем перенастройки сервера B, опять же без домена AD. В любом случае, я также хотел бы знать, что в этой ситуации будут делать более опытные администраторы Windows Server (кроме простой настройки проклятого домена Active Directory).
Ваш единственный вариант без домена Windows - действительно изменить идентификатор пула приложений на учетную запись, имеющую доступ. Если с существующей идентификацией не происходит ничего особенного, вам просто нужно создать базовую учетную запись пользователя (для нее не нужен профиль) и назначить ее в качестве удостоверения.
Во время выполнения ему будет предоставлено IIS_IUSRS group и имеют такой же доступ, как и идентификатор пула приложений по умолчанию.