2016-08-23 12 views
0

У меня есть приложение MVC Intranet, которое я недавно обновил с .Net 4 до 4.6.1. Это приложение запрашивает данные пользователя из Active Directory для загрузки данных, которые недоступны в свойстве User.Identity контроллера и до недавнего времени это делало это безупречно. Код выглядит примерно так:UserPrincipal.FindByIdentity приводит к ошибке COM 0x80005000

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 Version = v4.0
  • Идентичность = MyDomain \ MyAppServiceUser (Неинтерактивный AD User Account)
  • нагрузки Профиль пользователя = ложь

Все остальные параметры согласно значениям по умолчанию. Само приложение работает с включенной анонимной и Windows аутентификацией. На сервере установлен .Net 4.6.1 и все остальные элементы приложения интрасети, похоже, работают нормально.

Считая это до смерти, большинство ответов, похоже, указывают на то, что это проблема с разрешениями учетной записи службы для запроса AD. Чтобы подтвердить, что учетная запись службы, в которой работает пул приложений, имеет доступ к запросу Active Directory, я использовал приведенный выше код в консольном приложении и запустил его как сам, так и учетную запись службы на сервере - в обоих случаях экземпляры он работает просто отлично. Он запускается только под управлением IIS.

Я пробовал множество вариаций, создавая PrincipalContext (включая контейнер контейнера OU и т. Д.), Но результаты всегда одинаковы.

Я делаю свой орех на этом, поэтому любая помощь будет принята с благодарностью.

Update - дополнительные детали

  • Исключение Тип: System.Runtime.InteropServices.COMException
  • Сообщение исключения: неизвестная ошибка (0x80005000)
  • Трассировка стека:

в System.DirectoryServices.DirectoryEntry.Bind (Boolean throwIfFail) в System.DirectoryServices.DirectoryEntry.Bind() в System.DirectoryServices.DirectoryEntry.get_AdsObject() в System.DirectoryServices.PropertyValueCollection.PopulateList() в System.DirectoryServices.PropertyValueCollection..ctor (DirectoryEntry входа, String ИмениСвойства) при System.DirectoryServices.PropertyCollection.get_Item (String PropertyName) при System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer() на System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit() в System.DirectoryServices.AccountManagement .PrincipalContext.Initialize() в System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx() в System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper (PrincipalContext контексте, тип principalType, Nullable`1 IdentityType, String identityValue, DateTime refDate) в System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType (PrincipalContext контекст, тип principalType, IdentityType IdentityType, String identityValue) в System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity (PrincipalContext контекст, IdentityType IdentityType, String identityValue) на Ap ollo.Security.ActiveDirectoryUser.Find (String identityName)

+0

ли эта работа для вас? : http://stackoverflow.com/a/1722429/3709746 –

+0

К сожалению, нет - он взрывается с той же ошибкой при вызове DirectorySearcher.FindOne() - код в следующем комментарии – Pete

+0

var de = new DirectoryEntry ("LDAP: // MyDC.MyDomain.com/DC=MyDomain,DC=com "," MyDomain \\ ServiceUser "," password "); \t var ds = new DirectorySearcher (de); \t ds.Filter = $ "(& (objectClass = пользователь) (objectCategory = пользователь) (sAMAccountName = {userName}))"; \t ds.PropertiesToLoad.Add ("physicalDeliveryOfficeName"); \t var result = ds.FindOne(); // Blows here – Pete

ответ

0

Разговор о головном царапине. Я потратил большую часть дня на это по кругу.

Спасибо Рахулу за помощь. В конце концов, по его предложению, я создал новый пул приложений, работающий как Network Service, и поисковые запросы AD отлично работали под этим. К сожалению, поскольку мое приложение получает доступ к сетевым ресурсам, он должен запускаться как пользователь AD, поэтому просто для этого я изменил учетные данные на учетную запись службы AD, которую я использовал ранее, и ЭТО ВСЕ ЕЩЕ РАБОТАЕТ.

?!?

Я понятия не имею, почему это должно быть так - оба пула приложений имеют точно такую ​​же настройку, но каждый может выполнять поиск, а другой не может. Я включил тестовые и производственные экземпляры в новый пул приложений и удалил старый, и все идет хорошо.

+0

Похоже, что это, возможно, решило вашу проблему (хотя, как вы) Я не знаю, почему. У меня такая же ошибка, но она более постоянна. В случае, если это помогает кому-то другому, код ошибки 0x80005000 относится к недопустимому пути ADSI. Путь извлекается во время инициализации PrincipalContext и исходит из атрибута wellKnownObjects RootDSE. В моем случае подразделение содержало косую черту «/», которая мешала пути LDAP. В Microsoft имеется неполный список кодов ошибок ADSI: https://msdn.microsoft.com/en-us/library/aa705940(v=vs.85).aspx – ARP

0

Для нас это было связано с обслуживанием HIPS McAfee блокирует исходящие/входящие соединения WMI через порт TCP 135