campus认证问题

1. Workspace平台对接AD域认证
配置Workspace云桌面与微软AD域连接时，需在管理平台“系统-服务器认证-认证服务器”菜单下增加认证服务器，填写认证服务器名称、IP地址、管理员DN及密码即可完成对接。管理员DN可通过在域控服务器上执行dsquery命令查询。

2. 统信集中域管平台对接AD认证源
若涉及UOS桌面对接统信集中域管平台，需添加AD认证源和数据源。认证源配置包括服务器地址（如100.100.16.227）、端口号（默认389）、管理员账号/密码、域名（如***.***）及AD加密方式（NONE/SHA/MD5）；数据源配置需保持基准DN与认证源域名一致，并支持自动同步及密码回写功能。

3. 云桌面域用户登录机制
域用户存储在AD域服务器中，可在整个域环境内客户端登录，系统通过域控服务器活动目录中的数据进行验证。

在H3C AD-Campus解决方案中，一级和二级Access交换机完全可以作为认证点开启dot1x认证，但这属于一种需要明确设计和配置的部署模式。标准方案默认将认证点放在Leaf上，但平台也提供了将认证点下沉到Access的灵活能力。

 两种认证点部署模式对比

 如何在平台中配置Access作为认证点

在AD-Campus平台中，将认证点下沉到Access的关键操作路径如下：

1. 进入接入条件配置：在平台中导航至 “接入服务” > “接入场景” > “接入条件”。

2. 选择接入位置：在“接入位置分组”中，不要选择Leaf设备，而是直接选择你的Access设备，或者更进一步，选择Access设备的具体下行接口。

3. 关键规则：需要注意，同一台设备只能选择一种匹配方式。如果你选择了Access设备作为“接入设备”，就不能再为它指定具体的“接入端口”；反之亦然，这是为了保证接入场景匹配的唯一性。

4. 控制器协同：平台会将认证策略下发到指定的Access设备。Access设备需要具备dot1x认证能力，并与EIA/RADIUS服务器网络可达，以完成认证报文的交互。

 案例参考

虽然没有直接命名为“Access作为认证点”的案例，但H3C官方社区中有用户提出了完全相同的组网和问题：“现在有一级access接leaf，还有二级access接一级access，在campus解决方案中，一级和二级access可以作为认证点，开启dot1x认证吗，还是认证点要在leaf上”。这本身就说明该场景是实际存在的，并且平台设计上支持这种灵活性。另一个关于接入位置分组的讨论也明确提到，接入设备可以选择Leaf、Access或Access多级级联设备，进一步证实了Access作为认证点的可行性。

 注意事项

• 版本支持：Access作为认证点的功能可能依赖于AD-Campus平台的具体版本。建议确认你的平台版本，并查阅对应版本的《AD-Campus 配置指导》中关于“接入位置”或“有线认证”的章节。

• 性能评估：将认证点下沉到Access，意味着dot1x认证处理会占用Access设备的CPU资源。如果Access设备性能有限且下挂终端数量庞大，需要提前评估。

• 策略一致性：无论认证点设在Leaf还是Access，最终的用户授权（VLAN/VSI、安全组）都由EIA统一决策并下发。需要确保Access设备与EIA之间的RADIUS互通正常，否则认证将无法完成。