做企业WiFi项目的时候，有一个问题几乎是绕不过去的：WiFi认证系统到底怎么和现有的身份系统对接？一个企业可能用了AD域做员工身份管理、用了钉钉或企业微信做组织架构、还有一个独立的访客管理系统。如果认证系统不能把这些身份源串起来，上线之后运维人员就得在多个系统之间手动同步账号，工作量远超预期。

LDAP/AD对接的几种实际做法

WiFi认证系统和AD域对接是最常见的场景。员工用域账号连WiFi，不需要单独记一套密码，IT也不需要维护两套账号库。技术上的对接方式主要有两种：一种是设备直接配LDAP查询，把AD作为外部认证源；另一种是搭建一台RADIUS服务器，RADIUS再通过LDAP协议去查AD。

两种方式各有优劣。设备直连LDAP的好处是架构简单，少了一台中间服务器的维护成本。但坏处也很明显：大多数网络设备对LDAP的支持是"能用"级别，功能相对受限——比如搜索过滤器写不了复杂的嵌套条件，用户组映射做起来比较费劲，而且排查认证失败原因的时候日志信息经常不够详细。

通过RADIUS转发的方案灵活性高很多。RADIUS服务器可以做更细致的认证策略——验证用户是否属于特定安全组、检查账号是否被禁用、甚至可以根据用户OU来下发不同的网络权限策略。代价是多了一台服务器需要维护，并且RADIUS服务器本身的高可用也要考虑。实际落地中，规模稍微大一点的企业——几百人以上——基本都会走RADIUS转发方案，因为运维灵活度带来的收益远远覆盖那台服务器的成本。

直接对接和同步对接的区别

这是一个很多方案文档里不会明说但实际影响很大的问题。所谓直接对接，就是WiFi认证系统每次认证时实时去查身份源，不保存本地用户数据。所谓同步对接，是定期从身份源把用户数据同步到认证系统本地，认证时查本地库。

直接对接看起来简单优雅，但有一个致命问题：身份源挂了或者网络断了，WiFi就全部认证不了。如果认证系统依赖的AD服务器部署在总部机房，而总部到分支机构的专线断了，分支机构的员工就连WiFi都上不了。这在实际运维中是一个不能接受的风险。

同步对接解决了这个问题——本地库里有用户数据的副本，即使源系统暂时不可达，认证不受影响。代价是需要维护同步任务，并且要考虑数据一致性：当员工离职、账号在AD里被禁用后，同步任务多久能把这个变更传递到认证系统的本地库？如果同步周期是4小时，那么离职员工在同步完成前还能连WiFi，这在安全管理上是一个需要评估的风险窗口。

实际项目中，大部分场景建议走同步对接模式，同步周期控制在30分钟到1小时以内，并且在认证系统本地保留一定时间的缓冲——比如AD里状态为禁用的账号，在认证系统本地也立刻标记为不可认证。

多身份源合并时需要注意的账号冲突问题

有些企业的场景更复杂：总部用AD，但生产基地用另一套系统；或者国内站点用AD，海外站点用Azure AD。WiFi认证系统需要同时对接多个身份源，这时候最容易出现的问题就是账号冲突。

比如"zhangsan"这个账号在国内AD里存在，在海外Azure AD里也存在，但实际是两个不同的人。如果认证系统不做命名空间隔离，这两个人中的一个人可能会登录到另一个人应该使用的WiFi网段里。处理方式通常是在认证系统里给每个身份源加一个标识前缀，比如"ad-zhangsan"和"azure-zhangsan"，并在认证策略里根据前缀来决定下发哪些网络权限。

另外还有一个常见的坑：某些身份系统的账号唯一标识不是用户名，而是其他字段——比如AD的sAMAccountName和userPrincipalName可能不一致，或者企业微信用的是CorpId加UserId的组合做唯一标识。对接之前必须确认好用哪个字段做主键，并且全链路所有系统对这个字段的理解保持一致。否则就会出现"认证服务器说这个账号不存在，但AD管理员说这账号明明就在库里"的扯皮场面。

云端身份源的对接可行性评估

越来越多的企业把身份系统搬到了云端，比如Azure AD、Okta、或者飞书/钉钉的组织架构。WiFi认证系统要和云端身份源对接，需要评估几个技术条件：首先，认证系统本身能不能出公网？很多企业网的安全策略不允许网络设备直接访问公网，这时候WiFi认证系统如果部署在内网，就无法直接调云端身份系统的API。其次，云端身份系统有没有提供标准的LDAPS接口？如果没有、只有REST API，那认证系统是否支持自定义API对接？

一个折中方案是部署一台本地的代理服务器，由这台代理去和云端身份系统通信，WiFi认证系统只和本地代理交互。这个方案能兼顾安全策略和功能需求，但多了一层代理也就多了一个故障点，架构设计时需要明确这个代理节点的部署位置、网络路径和高可用方案。

WiFi认证系统的身份对接不是什么高大上的技术难题，但它的复杂之处在于：对接的不是技术标准，是每一个企业实际的信息化现状。把现状摸清楚，比选一个理论最优的对接方案更重要。