У меня есть набор веб-сайтов и приложений с их собственными пулами приложений, все использование AppPoolIdentity. Идентификационные данные пула приложений хороши, потому что можно установить полномочия файловой системы и добавить пользователей SQL Server на основе их, не имея необходимость управлять любыми паролями.
Моя установка работала хорошо, пока не было решено, чтобы этим веб-сайтам добавили стандартную аутентификацию к ним. Это было бы прекрасно, за исключением того, что IIS абсолютно настаивает на том, чтобы использовать идентификационные данные, которые Вы представляете, а не настроенные идентификационные данные пула приложений, независимо от любых настроек на самом пуле приложений.
Проблема, кажется, лежит в Connect As
диалоговое окно. У меня был он набор для использования Application user (pass-through authentication)
. Путая называющий в стороне, эта опция, очевидно, не будет работать на меня. Таким образом, я пытаюсь использовать Specific user
вместо этого.
Set Credentials
диалоговое окно обманчиво, в котором оно примет пользователя пула приложений формы IIS AppPool\[appPool]
без пароля, но когда Вы идете для доступа к сайту, Вы получаете это сообщение об ошибке:
HTTP Error 500.19 - Internal Server
The requested page cannot be accessed because the related configuration data for the page is invalid.
Config Error: Can not log on locally to `[websitePath]` as user `IIS AppPool\[appPool]` with virtual directory password
Config File: `\\?\C:\inetpub\temp\apppools\[appPool]\[websiteName].config`
Config Source
153: `<application path="/" applicationPool="[appPool]">`
154: `<virtualDirectory path="/" physicalPath="[websitePath]" userName="IIS AppPool\[appPool]" />`
155: `</application>`
Это - ссылка Microsoft для <virtualDirectory>
элемент. Открытие этого файла конфигурации не показывает ничего полезного. Я пытался добавить password=""
напрасно.
Есть ли какой-либо путь вообще для достижения того, что я пытаюсь выполнить? Идеально не добавляя модуль или другой специальный код на каждый сайт.
В итоге я решил свою проблему, создав урезанный пользовательский модуль на основе CustomBasicAuth и добавив его на уровне сервера (никаких возможностей конфигурирования, поскольку добавление пользовательской конфигурации на уровне машины на границах onerous-вы не можете просто сослаться на раздел конфигурирования из сборки, как вы можете это сделать в файлах web.config). Для этого требовалось нацелиться на .NET 2.0, присвоить сборке строгое имя и добавить ее в GAC. Я модифицировал код только для выполнения аутентификации, а не для установки принципа пользователя
.