Потребителски права, необходими за потребител на набор от приложения на IIS 7.5 (потребител на домейн, не AppPoolIdentity)

Имаме домейн на активна директория (да го наречем foodomain) и потребителски акаунт на домейн (foodomain\fooAppPoolUser), използвани за идентичност на групата приложения на IIS.

Искаме да стартираме набора от приложения под този потребителски акаунт, а не под Network Service или новия AppPoolIdentity, тъй като трябва да имаме достъп до SQL сървър и да имаме множество приложения в IIS (със собствени набори от приложения), които имат достъп до различни бази данни.

Проблемът е, че не мога да намеря ясно обяснение КАК ДА, кои потребителски права трябва да бъдат зададени за този потребителски акаунт и как IIS трябва да бъде настроен, така че това да работи.

Първо получих грешки (за съжаление не мога да си спомня кои), след това добавих fooAppPoolUser към локалната администраторска група (Administrators, знам, беше само за тестване), след което проработи. Сега премахнах потребителя отново, рестартирах IIS и все още работи.

Така че съм малко объркан и бих искал да знам каква трябва да бъде конфигурацията/настройката, за да работи.

Някъде прочетох, че акаунтът трябва да има потребителско право „Имитиране на клиент след удостоверяване“. Това е причината, поради която добавих акаунта към групата на администраторите (присвояването на потребителски права е блокирано чрез групови правила, но това със сигурност може да бъде променено, ако наистина е необходимо).

Надявам се, че бях достатъчно ясен какъв е въпросът и се надявам някой да има отговор.


configuration iis-7.5 application-pool windowsdomainaccount
person Arjen    schedule 01.07.2011    source източник

Отговори (4)


arrow_upward
8
arrow_downward

Разочароващо е, че тази информация е толкова трудна за намиране, тъй като някои администратори по сигурността изглежда се радват на жестокото и необичайно наказание да променят настройките на правилата по подразбиране, за да осуетят инсталирането на приложения в IIS.

Ето какво смятам, че трябва да направите, за да активирате даден акаунт да работи като самоличност на ApplicationPool:

  • Изпълнете aspnet_regiis -ga DOMAIN\USER, за да добавите разрешения за достъп до метабазата на IIS. (Точно какво означава това, кой знае?) aspnet_regiis reference
  • Добавете потребителя към групата IIS_IUSRS. Това може да стане автоматично в зависимост от конфигурационната настройка на IIS processmodel.manualGroupMembership, но най-лесно е да го добавите сами.
  • If security policy is using windows defaults that's about it. If the security policy is locked down you may need to enable specific user rights for the account. The ones you have by default for ApplicationPoolIdentities (which seems a good place to start but not necessarily all required):
    • Access this computer from the network
    • Регулирайте квотите на паметта за процес
    • Разрешете влизане локално
    • Проверка на байпаса
    • Генерирайте подробности за одита на сигурността
    • Имитиране на клиент след удостоверяване - (Често не е налично по подразбиране в заключени среди)
    • Влезте като пакетно задание - (Често не е налично по подразбиране в заключени среди)
    • Влезте като услуга - (не съм сигурен, че е необходимо)
    • Заменете токен на ниво процес
  • Ако използвате удостоверяване на Windows и Kerberos (доставчик=Negotiate), тогава в зависимост от URL адреса и ако удостоверяването в режим на ядрото е включено, може да се наложи да настроите SPN. Предлагам да преминете към NTLM, ако е възможно. В противен случай вижте статиите по-долу за SPN и намерете приятелски настроен администратор на домейн, който да ги добави вместо вас.

Забавно четене:

person Rory    schedule 06.01.2016

arrow_upward
4
arrow_downward

Причината, поради която вашето приложение работи СЛЕД премахването на администраторските права, е, че вашето приложение е компилирано във временната папка на Framework с помощта на администраторските права - Вашето приложение работи след премахване на администраторските права, тъй като приложението е компилирано. Ако актуализирате приложението си и то изисква повторно компилиране, акаунтът на пула от приложения отново ще се нуждае от доверие.

Първо получих грешки (за съжаление не мога да си спомня кои), след това добавих fooAppPoolUser към локалната администраторска група (Администратори, знам, беше само за тестване), след което проработи. Сега премахнах потребителя отново, рестартирах IIS и все още работи.

person I.T. Action    schedule 17.02.2013

arrow_upward
1
arrow_downward

Ариен,

За стъпките за конфигуриране в IIS бих погледнал Посочете самоличност за група приложения (IIS 7) в TechNet.

person timamm    schedule 15.02.2012

arrow_upward
-1
arrow_downward

Открих, че следната връзка отговаря на подобен въпрос, който имах: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

По принцип ApplicationPoolIdentity е виртуален потребителски акаунт, който все още се държи като NETWORK SERVICE, но без някои от недостатъците; всеки набор от приложения има свой собствен акаунт в ApplicationPoolIdenity, създаден с него.

Може да се намери и по-подробна информация, която също е специфична за Идентичности на набор от приложения на IIS 7.5.

person Ryan Riehle    schedule 04.01.2013