Права пользователя для приложения IIS 7.5 пул пользователей (пользователей домена, не AppPoolIdentity)
у нас есть домен active directory (назовем его foodomain
) и учетная запись пользователя домена (foodomainfooAppPoolUser
) используется для удостоверения пула приложений IIS.
мы хотим запустить пул приложений под этой учетной записью пользователя, а не под Network Service
или новый AppPoolIdentity
поскольку мы должны получить доступ к SQL server и иметь несколько приложений на IIS (с собственными пулами приложений), обращающихся к различным базам данных.
проблема в том, что я не могу найти четкое объяснение, какие права пользователя должны быть установите для этой учетной записи пользователя и как должен быть настроен IIS, чтобы это работало.
сначала я получил ошибки (к сожалению, я не могу вспомнить, какие из них), затем я добавил fooAppPoolUser
в группу администрирования (Administrators
, Я знаю, было только проверить), тогда это сработало. Теперь я снова удалил пользователя, перезапустил IIS, и он все еще работает.
поэтому я немного запутался и хотел бы знать, как должна работать конфигурация/настройка.
где-то я читал, что учетная запись должна иметь "олицетворение клиента после аутентификации" право пользователя. Вот почему я добавил учетную запись в группу Admin (назначение прав пользователя блокируется с помощью групповой политики, но это может быть изменено, если это действительно необходимо.
надеюсь, я был достаточно ясен, в чем вопрос, и надеюсь, что у кого-то есть ответ.
4 ответов
это расстраивает, что эту информацию так трудно найти, так как некоторые администраторы безопасности, похоже, пользуются жестоким и необычным наказанием изменения параметров политики по умолчанию, чтобы помешать установке приложений в IIS.
вот что я считаю, что вы должны сделать, чтобы учетная запись работала как идентификатор ApplicationPool:
- Run
aspnet_regiis -ga DOMAIN\USER
для добавления разрешений на доступ к Метабазе IIS. (ровно что это значит, кто знает?) команду aspnet_regiis ссылка - Добавить пользователя
IIS_IUSRS
группы. Это может быть сделано автоматически в зависимости от параметра конфигурации IIS processmodel.manualGroupMembership но проще всего добавить его самостоятельно. - если политика безопасности использует Windows по умолчанию, это все. Если политика безопасности заблокирована, может потребоваться включить определенные права пользователя для учетной записи. Те, которые у вас есть по умолчанию для ApplicationPoolIdentities (что кажется хорошим местом для начала, но не обязательно все необходимое):
- доступ к компьютеру из сети
- настройка квот памяти для процесса
- локальный вход в систему
- обход перекрестной проверки
- создание сведений аудита безопасности
- олицетворение клиента после аутентификации - (часто недоступно по умолчанию в заблокированных средах)
- войдите в систему как пакетное задание - (часто недоступно по умолчанию в заблокированных средах)
- войдите в систему как сервис -(Я не уверен, что это необходимо)
- замена маркера уровня процесса
- если вы используете Windows auth и Kerberos (provider=
Negotiate
), то в зависимости от URL-адреса и если аутентификация в режиме ядра включена, вам может потребоваться настроить SPN. Я предлагаю переключиться на NTLM, если это возможно. В противном случае см. статьи ниже о SPNs и найдите дружественный домен админ, чтобы добавить их для вас.
Fun чтение:
- по умолчанию разрешения и права пользователей для IIS 7.0, 7.5, 8.0. Это лучшая ссылка, см. права пользователя внизу.
- Прав Пользователей (на Windows Server 2008, но все еще интересно и полезно, как это длинная статья вы можете CTRL+F, чтобы найти комментарии, связанные с IIS)
- Назначение Прав Пользователя на сервере 2008 R2+. Вы нужно углубиться в каждое право, чтобы увидеть, что он упоминает о IIS.
- как создать учетную запись службы для ASP.NET 2.0 применение - жаль, что нет более поздней версии этой статьи.
- контрольный список SPN для Kerberos на IIS7 / 7.5
- как использовать SPNs - применяется к IIS6 или 7/8, если аутентификация в режиме ядра отключена.
причина, по которой приложение работало после удаления прав администратора, заключается в том, что ваше приложение было скомпилировано во временную папку Framework с использованием прав администратора - ваше приложение работало после удаления прав администратора, потому что приложение было скомпилировано. Если вы обновите приложение и для этого потребуется перекомпиляция, учетной записи пула приложений снова потребуется доверие.
сначала я получил ошибки (к сожалению я не помню какие), потом Я добавлен fooAppPoolUser в локальную группу администраторов (администраторы, I знаете, было только проверить), тогда это сработало. Теперь я снова удалил пользователя, перезапустить IIS и он все еще работает.
Арьен,
для шагов конфигурации в IIS я бы посмотрел на укажите удостоверение для пула приложений (IIS 7) на TechNet.
Я нашел следующую ссылку, отвечал на подобный вопрос: http://www.iis.net/learn/manage/configuring-security/application-pool-identities
по сути, ApplicationPoolIdentity это виртуальная учетная запись пользователя, которая по-прежнему ведет себя как сетевая служба, но без некоторых из нижних сторон; каждый пул приложений имеет свою собственную учетную запись ApplicationPoolIdenity, созданную с ним.
более подробную информацию также можно найти, что также характерные для идентификаторы пула приложений IIS 7.5.