DefaultAppPool работает с поднятым privilegs специального предложения на IIS?
Использование Visual Studio 2008, 2010, 2012:
- Перейти к окну точки останова
- Создать-> Перерыв в функции…
-
Для get, введите:
ClassName.get_CurrentFramesize()Для набора введите:
ClassName.set_CurrentFramesize(int)
Вы получите «Источник недоступен» при достижении точки останова, но вы получите место вызова в стеке вызовов.
Я нашел это решение здесь: http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/b1dd0dc3-e9c1-402a-9c79-a5abf7f7286a
См. Также: Отладка автоматических свойств
.
6 ответов
Вы можете этого не осознавать, но фактическая идентификация, выполняющая ваш код, может отличаться от той, которая указана для w3wp.exe в проводнике процессов. Вы должны установить точку останова или запустить WindowsIdentity.GetCurrent (). Name рядом с ошибочной строкой кода (DirectoryEntry.Parent.Children), которая вызывает нарушение COMException / «Доступ запрещен».
Например, для меня мой процесс пула приложений, w3wp.exe, выполнялся как СЕТЕВАЯ СЛУЖБА в окне диспетчера задач, как вы описали выше. Однако, когда я проверил действительный идентификатор среды выполнения, оказалось, что это новый встроенный пользователь IIS7 IUSR , который отличался от значения, которое я получил в IIS6, который был NETWORK SERVICE .
using System.Security.Principal;
Console.WriteLine(
WindowsIdentity.GetCurrent().Name); // IUSR on IIS7, NETWORKSERVICE on IIS6
foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children))
{
System.Console.WriteLine(de.Name);
}
Похоже, что в IIS6 СЕТЕВАЯ СЛУЖБА имела разрешение на исследование метабазы IIS через интерфейс службы Active Directory ( ADSI ) с классом DirectoryEntry . Однако новый идентификатор IUSR в IIS7 - нет. Чтобы запустить приведенный выше код, вам придется напрямую олицетворять учетную запись с существующими привилегиями чтения ADSI, например:
using (new MyImpersonationWrapper("admin","pass"))
{
foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children))
{
System.Console.WriteLine(de.Name);
}
}
Реализация собственной оболочки олицетворения и обеспечение надлежащей локальной учетной записи - это упражнение I оставлю вам, так как ваши (безопасность) потребности могут отличаться.
В качестве альтернативы вы сможете найти нужную информацию, используя WMI-провайдер для IIS7 , как предлагается в этом сообщении блога MSDN .
Я бы проверил путь, по которому вы обращаетесь к записи каталога. Возможно, у вас может быть конфликтующий сервис. Проверьте вашу программу просмотра событий.
Эта ссылка ведет к человеку, у которого была аналогичная проблема, и он обнаружил, что , поскольку Skype работал на порту 80, он вызывал конфликт с путем.
Но настоящий ответ на ваш вопрос: «Нет, вот так в пуле приложений по умолчанию нет ничего особенного ".
Из вашего описания немного сложно сказать, что именно может происходить, но насколько я понимаю, у вас есть такая настройка :
DefaultWebSite
|
+-- VirtualDirectory
|
+-- ShowIISMetaData.aspx
Я думаю, проблема в том, что страница, на которой должны отображаться метаданные IIS, пытается посмотрите на дочерние элементы своего родителя (другими словами, на его братьев и сестер).
foreach (DirectoryEntry de in iisNode.Parent.Children)
Это будет работать, только если пул приложений для веб-сайта по умолчанию и виртуального каталога одинаковы физический бассейн.
I would check to make sure that the NetWorkServices user has access to the physical directories that it is trying to access. It appears by the error that you are accessing different sites under the one that works and one that does not, is that correct?
As stated by the previous user there is nothing special about the Default AppPool and one you create (unless you change the settings of the custom AppPool. IIS does use the permissions of whatever user is setup to run the AppPool under.
В этом выпуске отсутствует некоторая информация. Обе учетные записи работают под одной и той же учетной записью пользователя, поэтому поведение должно быть одинаковым. Я предлагаю вам попробовать запустить код под стандартной установкой IIS, проблема все еще возникает?
Как упоминали другие, если учетные записи такие же, это потому, что вы внесли некоторые изменения в метабазу.
Учетные данные, связанные с пулом приложений, будут использоваться при попытке запроса AD. Поэтому, если оба пула приложений работают под одними и теми же учетными данными, это не ваша проблема.
Есть ли у вас другие настройки аутентификации на ваших тестовых сайтах? Если, например, вы интегрировали selected на одном, а не на другом ... это может объяснить ваше поведение.