Возможно, вы этого не понимаете, но фактическая идентификация вашего кода может отличаться от той, что указана для w3wp.exe в Process Explorer. Вам следует установить точку останова или запустить WindowsIdentity.GetCurrent().Name рядом с ошибочной строкой кода (DirectoryEntry.Parent.Children), которая вызывает исключение COMException / «Отказ в доступе».
Например, для меня мой процесс пула приложений, w3wp.exe, выполнялся как NETWORK SERVICE в окне диспетчера задач, как вы также описали выше. Однако, когда я проверил фактическую идентификацию во время выполнения, оказалось, что это был новый встроенный пользователь 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 NETWORK SERVICE было разрешено исследовать метабазу 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);
}
}
Внедрение вашей собственной оболочки для олицетворения и обеспечение надлежащей локальной учетной записи - это упражнение, которое я оставлю вам, поскольку ваши потребности в области безопасности могут различаться.
В качестве альтернативы вы можете найти нужную информацию, используя вместо этого * WMI-провайдер для IIS7 , как предложено в этом сообщении блога MSDN .