【问题标题】:FindByIdentity failing with PricipalOperationException in ASP.NET webappFindByIdentity 在 ASP.NET webapp 中因 PricipalOperationException 而失败
【发布时间】:2010-12-24 05:49:53
【问题描述】:

我在内部 Web 应用程序中使用 System.DirectoryServices.AccountManagement 时遇到问题。该错误不是很具有描述性,但这是发生了什么:

当我尝试验证 AD 中是否存在提供的用户 ID 时,我使用以下代码进行验证:

private bool IsWindowsIDValid(string strWindowsID) 
{ 
var context = new PrincipalContext(ContextType.Domain, "DOMAINSERVER", "DC=DOMAINNAME,DC=net"); 
var userPrincipal = UserPrincipal.FindByIdentity(context, strWindowsID); 
return (userPrincipal != null); 
} 

但是,在调用 FindByIdentity 的第二行会引发异常。以下是异常详情:

消息: “发生操作错误。”

堆栈跟踪:

在 System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInit() 在 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,字符串 identityValue,DateTime refDate) 在 System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext 上下文,类型 principalType,字符串 identityValue) 在 System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext 上下文,字符串 identityValue) 在 *****.IsWindowsIDValid(String strWindowsID) in *****.ascx.cs:line 193

如果我也尝试检查 PrincipalContext 的 ConnectedServer 属性,也会出现同样的错误。但是,我可以尝试根据上下文验证凭据(使用 context.ValidateCredentials()),它会很好地通过。

对可能发生的事情有任何想法吗?我可以在我的机器上的独立控制台脚本中很好地运行此代码 - 当我尝试调试 webapp 时,这发生在我的本地开发环境中,在 VisualStudio 中。这是权限问题还是其他问题?在这一点上我很迷茫。

感谢您的帮助!

-帕特里克

【问题讨论】:

    标签: c# asp.net visual-studio active-directory


    【解决方案1】:

    一个老问题,但我遇到了同样的错误。对我来说,问题是PrincipalContext 在其构造函数中没有用户名和密码就无法工作......每当我调用UserPrincipal(或@987654323)的任何方法或属性时,我都会收到完全相同的错误消息@ 对于这个问题)。

    如果您指定对您指定的容器具有 Active Directory 权限的域用户的用户名和密码,则对 FindByIdentity 的调用应该会成功:

    var context = new PrincipalContext(ContextType.Domain, "DOMAINSERVER",
                                       "DC=DOMAINNAME,DC=net", userName, pw); 
    var userPrincipal = UserPrincipal.FindByIdentity(context, strWindowsID); 
    

    对我来说,这不是一个解决方案,因为我不会有这两个参数。但这就是为什么你会得到你得到的错误。

    根据 Microsoft 的帮助,按照您的方式执行此操作应该在调用进程的凭据下运行......但无论我在谁下运行(并且我已经验证了模拟)对 UserPrincipal 对象的调用都没有在其PrincipalContext 上指定用户名和密码是行不通的。

    希望迟来的帮助, 詹姆斯

    【讨论】:

      【解决方案2】:

      对一个老问题的另一个迟来的答案,但这篇文章帮助我解决了我的问题:http://support.microsoft.com/kb/329986

      我收到了类似于本文中的“操作错误”。

      线索是建议在您的网络应用程序之外对其进行测试。于是我创建了一个控制台应用,添加了对 System.DirectoryServices.AccountManagement 的引用,并输入了以下代码:

      private static void Main(string[] args)
          {
      
              var adGroups = new List<string>();
      
              using (var principalContext = new PrincipalContext(ContextType.Domain))
              {
                  using (var user = UserPrincipal.FindByIdentity(principalContext, @"MYDOMAIN\MYUSERNAME"))
                  {
                      if (user == null) return;
      
                      var groups = user.GetAuthorizationGroups();
                      adGroups.AddRange(from @group in groups
                                        where @group.Name.ToUpper().Contains("SOME-STRING-COMMON-TO-ALL-THE-AD-GROUPS-PERTINENT-TO-MY-MVC-APP")
                                        select @group.Name);
                  }
              }
          }
      

      这很有效,因此我确信我的问题是 MS 文章中描述的“双跳”问题。

      解决方案是确保在我的 web.config 文件中启用模拟。 (这是一个内网应用,所以我打开了 Windows 身份验证模式,并打开了模拟;这样就解决了。

      <system.web>
          <httpRuntime targetFramework="4.5" />
          <compilation debug="true" targetFramework="4.5" />
          <authentication mode="Windows" />
          <identity impersonate="true" />
          <authorization>
                  <deny users="?" />
          </authorization>
      

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2019-01-10
        • 2011-03-31
        • 2010-09-17
        • 1970-01-01
        • 2018-02-16
        • 1970-01-01
        相关资源
        最近更新 更多