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

回答

相關問題