我有一个问题在没有可行的解决方案的情况下耗费了我很长时间。我没有使用 Sharepoint 的经验，而且我可能做得过火了，如果解决方案比我预期的简单得多，我不会感到惊讶。
场景如下：
1) 我们在客户端 (A) 上安装了 SharePoint。客户端 (A) 环境由测试和生产环境组成。生产环境为每个 WFE 和 BEDS 提供单独的服务器。测试环境由单个服务器中的 WFE 和 BEDS 组成。两个环境都在同一个域中。
2) Sharepoint 版本是 2013。
3）客户端（A）与客户端（B）域建立双向信任关系。
问题：生产 Sharepoint PeoplePicker 可以成功地从域 (B) 中抓取用户，而无需在 PeoplePicker 上进行任何配置。但是，测试 Sharepoint PeoplePicker 无法获取域 (B) 受信任用户。并因“找不到完全匹配”错误而失败。
我在测试环境（WFE 和 BEDS 位于同一位置）上尝试了以下解决方案来定位问题：
1- 检查所有 PeoplePicker 相关属性（Peoplepicker-searchadcustomquery、Peoplepicker-onlysearchwithinsitecollection、Peoplepicker-searchadforests、setsiteuseraccountdirectorypath 等），什么都没有。此外，我在两种环境（生产和测试）上运行人员选择器端口测试器来比较任何防火墙配置差异，即使某些端口在抱怨并且 UDP 端口（445,135）之间存在差异，但我认为这不是 Wireshark 的问题后面的步骤 (3) 将说明为什么这是不可能的。从我在互联网上阅读的内容来看，我必须在两种方式的信任方案中为人员选择器配置任何内容，仍然尝试进行一种方式的信任配置，没有任何效果并且我恢复了更改。
2- 将 Sharepoint 配置为详细日志记录（所有组件，因为我不知道哪个组件负责 PeoplePicker）收集日志并搜索查询用户的日志。没有有用的信息，从 ULS 查看器中附加了一个屏幕截图，用户被屏蔽了。
3- 收集 Wireshark 流量转储并由 LDAP 过滤。我可以清楚地知道 LDAP 响应包含来自受信任的查询用户以及所有用户属性和域名。这就是为什么我排除了任何人员选择器过滤原因、域搜索限制或网络端口问题。附上截图。
4- 排除网络问题后（因为 LDAP 查询成功返回到 WFE），我决定先看看 Sharepoint 内部的流程如何，然后再在 PeoplePicker 中显示结果。如果从 Microsoft 找到这篇描述 PeoplePicker 工作流程的文章。从下图中，我可以得出结论，LDAP 请求成功通过了步骤 1,2 和 3。我需要检查从 4 到 11 的步骤，这些步骤是 MS-WSSFO 协议握手。我阅读了该协议，发现它由一组从 WFE 到 BEDS 的存储过程调用组成。我尝试通过使用 SQL Server Profile 并搜索 (proc_GetTpWebMetadataAndListMetadata) & (proc_GetListMetadataAndEventReceivers) 存储过程来调试协议，但没有找到。
5- 我的一个朋友建议配置与受信任域（域 B）活动目录的 UPSA（用户配置文件服务应用程序）连接，我授予 Sharepoint 服务用户对（域 B）活动目录所需的权限，配置连接并测试同步正如我从同步服务管理器中看到的那样，它确实加载了用户，但是，PeoplePicker 仍然失败。但是，我认为这一步是不必要的，因为据我所知，PeoplePicker 和 UPS 并不相关，而且生产 Sharepoint PeoplePicker 在不配置 UPSA 的情况下工作正常。请问有什么帮助吗？