UserPrincipal.FindByIdentity中的.NET 4.5错误（System.DirectoryServices.AccountManagement）
在.NET 4.5下测试我们的.NET 4.0应用程序时，我们遇到了FindByIdentity方法的UserPrincipal 。 以下代码在.NET 4.0运行时运行时有效，但在.NET 4.5下失败：
[Test] public void TestIsAccountLockedOut() { const string activeDirectoryServer = "MyActiveDirectoryServer"; const string activeDirectoryLogin = "MyADAccount@MyDomain"; const string activeDirectoryPassword = "MyADAccountPassword"; const string userAccountToTest = "TestUser@MyDomain"; const string userPasswordToTest = "WRONGPASSWORD"; var principalContext = new PrincipalContext(ContextType.Domain, activeDirectoryServer, activeDirectoryLogin, activeDirectoryPassword); var isAccountLockedOut = false; var isAuthenticated = principalContext.ValidateCredentials(userAccountToTest, userPasswordToTest, principalContext.Options); if (!isAuthenticated) { // System.DirectoryServices.AccountManagement.PrincipalOperationException : Information about the domain could not be retrieved (1355). using (var user = UserPrincipal.FindByIdentity(principalContext, IdentityType.UserPrincipalName, userAccountToTest)) { isAccountLockedOut = (user != null) && user.IsAccountLockedOut(); } } Assert.False(isAuthenticated); Assert.False(isAccountLockedOut); }
这是exception堆栈跟踪：
System.DirectoryServices.AccountManagement.PrincipalOperationException : Information about the domain could not be retrieved (1355). at System.DirectoryServices.AccountManagement.Utils.GetDcName(String computerName, String domainName, String siteName, Int32 flags) at System.DirectoryServices.AccountManagement.ADStoreCtx.LoadDomainInfo() at System.DirectoryServices.AccountManagement.ADStoreCtx.get_DnsDomainName() at System.DirectoryServices.AccountManagement.ADStoreCtx.GetAsPrincipal(Object storeObject, Object discriminant) at System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRefHelper(Type principalType, String urnScheme, String urnValue, DateTime referenceDate, Boolean useSidHistory) at System.DirectoryServices.AccountManagement.ADStoreCtx.FindPrincipalByIdentRef(Type principalType, String urnScheme, String urnValue, DateTime referenceDate) 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)
有没有其他人看到并解决了这个问题？ 如果没有，我们是否有更好的方法来检查Active Directory帐户的IsAccountLockedOut状态？
作为参考，我们所有的测试机器都在同一个子网内。 运行Windows Server 2003,2008和2012的单独ActiveDirectory服务器具有多种域function模式（见下文）。 该代码适用于运行.NET 4.0的计算机，但是运行.NET 4.5的计算机无法运行。
我们运行代码的三台.NET机器是：
– 运行.NET 4.0的Windows 7
– 运行.NET 4.5的Windows Vista
– 运行.NET 4.5的Windows Server 2012
我们尝试过的Active Directory服务器是：
– 将AD域function模式设置为Windows 2000本机的Windows 2003
– 将AD域function模式设置为Windows Server 2003的Windows 2003
– 将Windows域function模式设置为Windows 2000本机的Windows 2008
– 将Windows域function模式设置为Windows Server 2003的Windows 2008
– 将Windows域function模式设置为Windows Server 2008的Windows 2008
– 将Windows域function模式设置为Windows 2012的Windows 2012
所有这些Active Directory服务器都配置为简单的单林，客户端计算机不属于域。 它们不用于测试此行为的任何其他function，并且不运行除Active Directory之外的任何其他function。
编辑 – 2012年10月9日
感谢所有回复的人。 下面是一个演示此问题的C＃命令行客户端，以及我们发现的一个短期解决方法，它不需要我们更改有关Active Directory和DNS配置的任何内容。 似乎只有PrincipalContext的实例抛出exception一次。 我们包括.NET 4.0机器（Windows 7）和.NET 4.5机器（Windows Vista）的输出。
using System; using System.DirectoryServices.AccountManagement; namespace ADBug { class Program { static void Main(string[] args) { const string activeDirectoryServer = "MyActiveDirectoryServer"; const string activeDirectoryLogin = "MyADAccount"; const string activeDirectoryPassword = "MyADAccountPassword"; const string validUserAccount = "TestUser@MyDomain.com"; const string unknownUserAccount = "UnknownUser@MyDomain.com"; var principalContext = new PrincipalContext(ContextType.Domain, activeDirectoryServer, activeDirectoryLogin, activeDirectoryPassword); // .NET 4.0 - First attempt with a valid account finds the user // .NET 4.5 - First attempt with a valid account fails with a PrincipalOperationException TestFindByIdentity(principalContext, validUserAccount, "Valid Account - First Attempt"); // Second attempt with a valid account finds the user TestFindByIdentity(principalContext, validUserAccount, "Valid Account - Second Attempt"); // First attempt with an unknown account does not find the user TestFindByIdentity(principalContext, unknownUserAccount, "Unknown Account - First Attempt"); // Second attempt with an unknown account does not find the user (testing false positive) TestFindByIdentity(principalContext, unknownUserAccount, "Unknown Account - Second Attempt"); // Subsequent attempt with a valid account still finds the user TestFindByIdentity(principalContext, validUserAccount, "Valid Account - Third Attempt"); } private static void TestFindByIdentity(PrincipalContext principalContext, string userAccountToTest, string message) { var exceptionThrown = false; var userFound = false; try { using (var user = UserPrincipal.FindByIdentity(principalContext, IdentityType.UserPrincipalName, userAccountToTest)) { userFound = (user != null); } } catch (PrincipalOperationException) { exceptionThrown = true; } Console.Out.WriteLine(message + " - Exception Thrown = {0}", exceptionThrown); Console.Out.WriteLine(message + " - User Found = {1}", userAccountToTest, userFound); } } }
.NET 4.0输出
Valid Account - First Attempt - Exception Thrown = False Valid Account - First Attempt - User Found = True Valid Account - Second Attempt - Exception Thrown = False Valid Account - Second Attempt - User Found = True Unknown Account - First Attempt - Exception Thrown = False Unknown Account - First Attempt - User Found = False Unknown Account - Second Attempt - Exception Thrown = False Unknown Account - Second Attempt - User Found = False Valid Account - Third Attempt - Exception Thrown = False Valid Account - Third Attempt - User Found = True
.NET 4.5输出
Valid Account - First Attempt - Exception Thrown = True Valid Account - First Attempt - User Found = False Valid Account - Second Attempt - Exception Thrown = False Valid Account - Second Attempt - User Found = True Unknown Account - First Attempt - Exception Thrown = False Unknown Account - First Attempt - User Found = False Unknown Account - Second Attempt - Exception Thrown = False Unknown Account - Second Attempt - User Found = False Valid Account - Third Attempt - Exception Thrown = False Valid Account - Third Attempt - User Found = True
我们遇到了完全相同的问题（跨域查询无法更新到4.5） – 我认为这是一个错误，因为它打破了现有的（4.0）代码。
但是，为了使它工作 – 看看其中一个（现在）失败的客户端，我注意到有一堆DNS请求失败的SRV记录，forms如下：
_ldap._tcp.MYSERVER1.mydomain.com,INet,Srv _ldap._tcp.dc._msdcs.mydomain.com,INet,Srv
修改我们的DNS服务器（故障客户端使用的DNS）为所有mydomain.com流量的前向区域到域中的一个DC确实解决了该问题。
使用nslookup，从之前（失败时）到现在（工作）的行为是在这些查询返回“不存在的域”之前的行为，而现在它们返回“ *没有服务位置（SRV）记录可用于…” 。 失败点似乎是域的感知不存在而不是缺少SRV记录。 希望MS恢复此行为，但与此同时，如果您可以控制发生故障的客户端的DNS，则可能会有一些运气创建DNS转发区域。
对于OP（以及其他任何帮助回复的人），我们已经（有）同样的问题。 在我们的开发环境中，安装VS2012和我们的应用程序在登录期间在运行时中断（AD问题如上所述）。 因此，我的系统已经擦除并继续使用2010年，每次我都读到一篇关于2012年是多么糟糕的博客文章的时候会流下眼泪。
所以我发现这个post归功于Scott Hanselman。 我在我的开发盒上安装了一个VM，Windows 8开发人员90天预览，以及VS2012。 让我们的应用程序启动并运行，并立即被登录AD障碍命中。 简单地将我们的FindByIdentity包裹在try catch中，并强制它在第一次捕获后再次尝试 – 并且中提琴工作！ 所以，多亏那些想出那个小技巧的人！
因此，它是一个小修复，以及适用于本地开发的“黑客”，并且不应该影响生产，因为我们不会很快将4.5投入生产。
但缺点是在本地，登录现在需要2分钟而不是秒，当我们在2010年运行时:(
我真的不知道我还能提供什么来帮助解决这个问题，但无论如何都认为我分享了2美分，因为这仍然是一个主要问题。
将.net框架从4.0升级到4.5之后有同样的问题我已经将.net 4.5.1 ugpraded框架用到了它。