UserPrincipal.FindByIdentity导致COM错误0x80005000 [英] UserPrincipal.FindByIdentity results in COM error 0x80005000
问题描述
我有一个MVC Intranet应用程序，最近将其从.Net 4升级到4.6.1.该应用程序从Active Directory中查询用户详细信息，以加载Controller的User.Identity属性中不可用的详细信息，直到最近为止都做到了这一点.代码看起来像这样:
I've an MVC Intranet app that I've recently upgraded from .Net 4 to 4.6.1. This app queries user details from Active Directory to load details that aren't available in the Controller's User.Identity property and until lately has done so flawlessly. The code looks something like this:
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框(Windows Server 2008 R2上的v6.1 SP1)上运行时，在调用UserPrincipal.FindByIdentity()时抛出COMException(0x80005000)
The code runs fine when debugging in Visual Studio 2015, but when it's running on the IIS box (v6.1 SP1 on Windows Server 2008 R2), throws a COMException (0x80005000) when calling UserPrincipal.FindByIdentity()
该Web应用程序正在专用的应用程序池上运行，其设置如下:
The web app is running on a dedicated App Pool, the settings for which are as follows:
- .Net Framework版本= v4.0
- 身份= MyDomain \ MyAppServiceUser(非交互式AD用户帐户)
- 加载用户个人资料= false
所有其他设置均为默认设置.该应用程序本身在启用匿名和Windows身份验证的情况下运行.该服务器已安装.Net 4.6.1，Intranet应用程序的所有其他元素似乎都运行良好.
All other settings are as per the defaults. The application itself is running with both Anonymous and Windows Authentication enabled. The server has .Net 4.6.1 installed and all other elements of the intranet app seem to be running just fine.
对此进行了搜索，大多数答案似乎表明该服务帐户的查询AD权限存在问题.为了确认应用程序池以DOES身份运行的服务帐户有权查询Active Directory，我在控制台应用程序中使用了上面的代码，并以我本人和服务器上的服务帐户身份运行了它们-在这两者中实例工作正常.它只有在IIS下运行时才会爆炸.
Having googled this to death, most of the answers seem to indicate that it's a problem with the service account's permissions to query AD. In order to confirm that the service account that the App Pool is running as DOES have access to query Active Directory, I've used the above code in a console app and run it as both myself and the service account on the server - in both instances it works just fine. It only bombs out when running under IIS.
我尝试了多种创建PrincipalContext的变体(包括OU容器路径等)，但结果始终相同.
I've tried numerous variations creating the PrincipalContext (including the OU container path, etc) but the results are always the same.
我正在为此做些努力，因此任何帮助将不胜感激.
I'm doing my nut on this, so any help would be greatly appreciated.
更新-其他详细信息
- 异常类型:System.Runtime.InteropServices.COMException
- 异常消息:未知错误(0x80005000)
- 堆栈跟踪:
at System.DirectoryServices.DirectoryEntry.Bind(布尔throwIfFail)在System.DirectoryServices.DirectoryEntry.Bind()在System.DirectoryServices.DirectoryEntry.get_AdsObject()在System.DirectoryServices.PropertyValueCollection.PopulateList()在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.Initialize()在System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()在System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext上下文，类型principalType，可为空的1 identityType，字符串identityValue，DateTime refDate)System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext上下文，类型PrincipalType，IdentityType identityType，字符串identityValue)System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext上下文，IdentityTypeidentityType，字符串identityValue)位于Apollo.Security.ActiveDirectoryUser.Find(字符串identityName)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) at System.DirectoryServices.DirectoryEntry.Bind() at System.DirectoryServices.DirectoryEntry.get_AdsObject() at System.DirectoryServices.PropertyValueCollection.PopulateList() at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) at System.DirectoryServices.PropertyCollection.get_Item(String propertyName) at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer() at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit() at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize() at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx() at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate) at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, IdentityType identityType, String identityValue) at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, IdentityType identityType, String identityValue) at Apollo.Security.ActiveDirectoryUser.Find(String identityName)
推荐答案
谈论一个令人头疼的问题.我花了一天的大部分时间在圈子里逛逛.
Talk about a head-scratcher. I've spent the best part of a day on this going around in circles.
感谢拉胡尔提供的所有帮助.最后，在他的建议下，我创建了一个作为网络服务运行的新应用程序池，在此条件下，AD查找工作正常.不幸的是，由于我的应用访问网络资源，因此它需要以AD用户身份运行，因此，就我而言，我将凭据更改为以前使用的AD服务帐户，并且 它仍然有效 .
Thanks to Rahul for all the help. In the end, at his suggestion, I created a new app pool running as Network Service and the AD lookups worked perfectly under that. Unfortunately, because my app accesses networked resources it needs to run as an AD User, so just for the heck of it I changed the credentials over to the AD Service Account I'd been using before and IT STILL WORKED.
?！?
我不知道为什么会这样-两个应用程序池都具有完全相同的设置，但是一个可以执行查找，而另一个则不能.我已经将测试和生产实例都切换到了新的应用程序池，并删除了旧的应用程序池，一切进展顺利.
I have no idea why this should be the case - both app pools have exactly the same setup yet one can perform the lookups and the other can't. I've switched both the test and production instances over to the new app pool and deleted the old one and everything is ticking along nicely.
这篇关于UserPrincipal.FindByIdentity导致COM错误0x80005000的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
