使用UserPrincipal从AD获取AuthorizationGroups时遇错误(5)的优化咨询

我在.NET 6环境下，尝试使用UserPrincipal遍历约11000名Active Directory用户，通过以下代码获取其授权组：

PrincipalSearchResult<Principal> groups = up.GetAuthorizationGroups();

发现部分用户会触发如下错误：

An error (5) occurred

且每次运行时，出现错误的用户不固定。此外，up.GetGroups()始终可正常运行。

我推测GetAuthorizationGroups耗时更长，遍历11K用户时可能出现超时类问题。为确保流程在30分钟内完成，我已对20个用户批量使用Parallel.Foreach，现寻求更高效的优化方案，我的推测是否正确？

你的推测部分正确，但Error 5的核心原因不止超时 #

Error 5本质是访问拒绝（Access Denied），但随机性出现的原因和GetAuthorizationGroups的特性强相关：

• GetGroups()仅查询用户直接加入的组，逻辑简单，AD服务器负载低，不易触发权限或超时问题；
• GetAuthorizationGroups()会递归查询用户所有嵌套安全组（含跨域组），查询链路更长、复杂度更高：
  1. 高并发下（比如你用20个并行任务），AD服务器负载陡增，部分请求的权限校验流程可能因资源不足出现异常；
  2. 部分组的权限配置特殊，你的服务账号无读取权限，而并发请求的执行顺序随机，导致每次报错的用户不固定；
  3. 超时确实是诱因之一，AD服务器响应缓慢时，部分请求会被终止，表现为模糊的Error 5。

优化方案（解决报错+确保30分钟内完成） #

• 合理控制并发数，避免过度施压AD：
  不要固定20个并发，建议先测试5-10个并发数，通过ParallelOptions限制最大并行任务数：

  var parallelOptions = new ParallelOptions { MaxDegreeOfParallelism = 8 };
  Parallel.ForEach(userList, parallelOptions, userPrincipal => {
      // 用户组查询逻辑
  });
  

• 改用原生LDAP查询替代封装方法：
  UserPrincipal的封装方法效率偏低，直接读取AD预计算的tokenGroups属性（存储用户所有授权组的SID集合），再批量转换为组对象，速度能提升数倍：

  // 获取用户对应的DirectoryEntry
  using var directoryEntry = userPrincipal.GetUnderlyingObject() as DirectoryEntry;
  // 读取预计算的tokenGroups属性（仅包含安全组，和GetAuthorizationGroups范围一致）
  var tokenGroups = directoryEntry.Properties["tokenGroups"];
  foreach (byte[] sidBytes in tokenGroups)
  {
      var groupSid = new SecurityIdentifier(sidBytes, 0);
      // 通过SID查询组信息
      using var groupPrincipal = GroupPrincipal.FindByIdentity(principalContext, groupSid.Value);
      // 处理组数据
  }
  

• 添加重试机制处理随机报错：
  对Error 5添加指数退避重试，避免单次随机失败中断流程：

  const int maxRetries = 3;
  for (int retry = 0; retry < maxRetries; retry++)
  {
      try
      {
          var authorizationGroups = userPrincipal.GetAuthorizationGroups();
          // 处理组数据
          break;
      }
      catch (PrincipalOperationException ex) when (ex.Message.Contains("error (5)"))
      {
          if (retry == maxRetries - 1) throw;
          // 指数退避等待
          Thread.Sleep((int)Math.Pow(2, retry) * 1000);
      }
  }
  

• 批量预查询组信息：
  先收集所有用户的tokenGroups SID，再批量查询组的属性，减少重复的AD请求，进一步提升效率。

总结 #

你的超时推测是合理的，但随机Error 5是高并发下AD权限校验异常+超时共同作用的结果。通过调整并发数、改用原生LDAP查询、添加重试机制，既能解决随机报错问题，又能大幅提升遍历效率，确保在30分钟内完成11K用户的处理。

内容的提问来源于stack exchange，提问作者Itay Perri