У меня есть приложение MVC Intranet, которое я недавно обновил с .Net 4 до 4.6.1. Это приложение запрашивает сведения о пользователе из Active Directory для загрузки сведений, которые недоступны в свойстве User.Identity контроллера, и до недавнего времени это делалось безупречно. Код выглядит примерно так:
public static void foo()
{
var usr = LookupUser("MyDomain", "jbloggs");
...
}
private static UserPrincipal LookupUser(string domain, string username)
{
Console.WriteLine($"Lookup {domain}\\{username}");
using (var ctx = new PrincipalContext(ContextType.Domain, domain))
{
using (var user = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, username))
{
if (user == null)
{
Console.WriteLine("User not found");
return;
}
Console.WriteLine($"Found {domain}\\{username}");
Console.WriteLine($"DisplayName = {user.DisplayName}");
Console.WriteLine($"Office = {user.GetString("physicalDeliveryOfficeName")}");
Console.WriteLine("");
return user;
}
}
}
Код работает нормально при отладке в Visual Studio 2015, но когда он выполняется в поле IIS (v6.1 SP1 в Windows Server 2008 R2), выдает исключение COMException (0x80005000) при вызове UserPrincipal.FindByIdentity ()
Веб-приложение работает в выделенном пуле приложений, настройки которого следующие:
- .Net Framework Версия = v4.0
- Identity = MyDomain \ MyAppServiceUser (неинтерактивная учетная запись пользователя AD)
- Загрузить профиль пользователя = false
Все остальные настройки соответствуют значениям по умолчанию. Само приложение работает с включенной анонимной аутентификацией и аутентификацией Windows. На сервере установлен .Net 4.6.1, и все остальные элементы приложения интрасети, похоже, работают нормально.
Погуглив это до смерти, большинство ответов, похоже, указывают на то, что это проблема с разрешениями учетной записи службы на запрос AD. Чтобы подтвердить, что учетная запись службы, в которой запущен пул приложений, имеет доступ к запросам Active Directory, я использовал приведенный выше код в консольном приложении и запустил его как для себя, так и для учетной записи службы на сервере - в обоих случаях. экземпляров он работает нормально. Он срывается только при работе под IIS.
Я пробовал множество вариантов создания PrincipalContext (включая путь контейнера OU и т. Д.), Но результаты всегда одни и те же.
Я делаю это с моей точки зрения, поэтому любая помощь будет принята с благодарностью.
Обновление - дополнительные сведения
- Тип исключения: System.Runtime.InteropServices.COMException
- Сообщение об исключении: неизвестная ошибка (0x80005000)
- Трассировки стека:
в System.DirectoryServices.DirectoryEntry.Bind (Boolean throwIfFail) в System.DirectoryServices.DirectoryEntry.Bind () в System.DirectoryServices.DirectoryEntry.get_AdsObject () в System.DirectoryServices.PropertyValueCollection.PopulateVervices .. ctor (запись DirectoryEntry, String propertyName) в System.DirectoryServices.PropertyCollection.get_Item (String propertyName) в System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer () в System.DirectoryDirectoryInitNoContainer () в System.DirectoryDirectoryInitNoContainer () в System.DirectoryDirectoryAccountManagementServices.AccountManagement.PackageServices. .PrincipalContext.Initialize () в System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx () в System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper (контекст основного контекста, идентификатор System.DirecueableType, идентификатор System.Direcueal`ype1 toryServices.AccountManagement.Principal.FindByIdentityWithType (контекст PrincipalContext, тип PrincipalType, IdentityType identityType, String identityValue) в System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity. identityName)
