UserPrincipal.FindByIdentity导致COM错误0x80005000

我有一个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时（）

的Web应用程序是在一个专用的应用程序池运行时，设置，内容如下：

支持.Net Framework Version = V4.0
身份= MYDOMAIN \ MyAppServiceUser （非交互式AD用户帐户）
加载用户资料=假

所有其他设置是按照默认值。应用程序本身在启用匿名和Windows身份验证的情况下运行。该服务器安装了.NET 4.6.1，并且Intranet应用程序的所有其他元素似乎都运行良好。

已将此Google搜索结果导致死亡，大多数答案似乎表明这是服务帐户查询AD的权限问题。为了确认应用程序池运行的服务帐户可以访问Active Directory，我已经在控制台应用程序中使用了上述代码，并将其作为服务器上的自己和服务帐户运行 - 两种它工作的实例很好。它只在IIS下运行时弹出。

我已经尝试过创建PrincipalContext（包括OU容器路径等）的众多变体，但结果总是相同的。

我正在做这个坚果，所以任何帮助将不胜感激。

更新 - 附加细节

异常类型信息：System.Runtime.InteropServices.COMException
异常消息：未知错误（0x80005000）
堆栈跟踪：

at System.DirectoryServices.DirectoryEntry.Bind（Boolean throwIfFail）在System.DirectoryServices.DirectoryEntry.Bind（）处 System.DirectoryServices.PropertyValueCollection.PopulateList（） System.DirectoryServices.DirectoryEntry.get_AdsObject（）在 System.DirectoryServices.PropertyValueCollection..ctor（的DirectoryEntry 条目，字符串propertyName的）在 System.DirectoryServices.PropertyCollection.get_Item（字符串 propertyName的）在 System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer（）在 System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit（）在 System.DirectoryServices.AccountManagement .PrincipalContext。初始化（）在 System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx（）在 System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper（PrincipalContext 上下文中，类型principalType，Nullable`1 identityType，字符串 identityValue，日期时间refDate）在 System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType（PrincipalContext 上下文中，类型principalType，identityType identityType，字符串 identityValue）在 System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity（PrincipalContext 上下文，identityType identityType，字符串identityValue）在鸭ollo.Security.ActiveDirectoryUser.Find（String identityName）

来源

2016-08-23 Pete

这是否对你的工作？：http://stackoverflow.com/a/1722429/3709746 –

可惜不是 - 它调用DirectorySearcher.FindOne（）时相同的错误炸毁 - 在接下来的评论 – Pete

VAR DE =新的DirectoryEntry（“LDAP代码：// MyDC.MyDomain.com/DC=MyDomain,DC=com“，”MyDomain \\ ServiceUser“，”password“）; \t var ds = new DirectorySearcher（de）; （＆（objectClass = user）（objectCategory = user）（sAMAccountName = {userName}））“; \t ds.PropertiesToLoad.Add（“physicalDeliveryOfficeName”）; \t var result = ds.FindOne（）; //在这里爆炸 – Pete

谈论头部划痕。我花了一天的最佳时间在这个圈子里进行。

感谢拉胡尔的所有帮助。最后，在他的建议下，我创建了一个作为网络服务运行的新应用程序池，AD查找在此之下完美运行。不幸的是，因为我的应用程序访问网络资源，它需要为AD用户运行，所以只为它赫克我改变了凭证交给我一直在使用之前的广告服务帐户和IT仍然工作。

？！？

我不知道为什么这应该是这样的 - 无论是应用程序池具有完全相同的设置还可以进行查询和其他不能。我已经将测试和生产实例都切换到了新的应用程序池，并删除了旧的应用程序池，并且所有事情都很顺利。

来源

2016-08-24 08:36:53 Pete

它看起来像这可能已经解决了您的问题，但（像你）我不知道为什么。我遇到了同样的错误，但它更加稳定。如果它帮助别人，错误代码0x80005000引用无效的ADSI路径名。该路径在PrincipalContext初始化期间检索，并来自RootDSE的wellKnownObjects属性。在我的情况下，OU包含一个斜杠“/”，它干扰了LDAP路径。微软的ADSI错误代码的部分列表这里：https://msdn.microsoft.com/en-us/library/aa705940(v=vs.85).aspx – ARP

对我们来说，这是由于与McAfee HIPS服务通过TCP端口阻止出境/入境WMI连接135

来源

2018-01-30 09:53:30 Aaron

UserPrincipal.FindByIdentity导致COM错误0x80005000

回答

相关问题