很多单位在部署WiFi无线认证系统时才发现，自己其实已经有一套身份体系了：员工有工号、学生有学工号、会员有手机号、办公有AD域账号。新上的认证系统如果另起炉灶再建一套账号，不仅用户要记两套密码，IT也要维护两套数据，时间一长就成了谁都对不上的烂摊子。能不能和现有身份系统打通，直接决定了这套认证是省心还是添乱。

先盘点手里有哪几类身份源

动手对接之前，先把单位里已经存在的身份系统列清楚：是只有手机号？还是有统一的LDAP、AD域？有没有微信企业号、钉钉、企业微信？校园场景有没有学工号和统一身份认证？医院、政务有没有电子健康卡或政务账号？每一种身份源对应的对接方式、协议、管理方都不一样。我们见过一个学校， simultaneously 在用学工号、微信企业号和一卡通三套，彼此不互通，新认证系统上来先得决定以哪个为主。盘点这一步偷不得懒，它决定了后面整个账号模型怎么建。

一个主身份加多源绑定的模型最稳

比较成熟的做法是：在认证系统里建一个"主账号"，然后把手机号、工号、微信、学工号都作为"绑定关系"挂到主账号下面。用户用任意一种方式认证，系统都能识别到是同一个人。这样做的好处是，将来某个身份源变了，比如换了AD域，只要重新绑一遍，不影响用户在WiFi里的历史记录。反过来，如果让每种方式都生成独立账号，数据立刻就碎了。我们一般建议客户在方案阶段就把主账号字段定下来，别等到上线才发现账号对不上。

LDAP和AD域对接的坑在权限和同步

企业办公场景最常见的身份源是AD域或LDAP。技术上对接不复杂，难的是同步策略：是全量同步还是增量？离职员工禁用了域账号，WiFi这边多久能同步掉？账号状态不同步，就会出现人走了还能连WiFi的安全隐患。我们碰到过一家企业，HR在AD里禁用离职员工，但认证系统每周才同步一次，中间那几天离职人员仍能上网，被审计指出后赶紧改成实时或准实时同步。对接时要把"状态变化的传播时延"作为一个明确指标写进方案，不能只说"支持LDAP对接"就完事。

微信和企业微信的场景差异

对外服务的场所，微信几乎是绕不开的身份源。但微信个人号和微信企业号是两回事：个人号只能拿到一个openid，做不了真正的实名；企业微信能关联到具体员工，适合内部场景。很多商户想用微信做认证，又想要实名，就卡在个人微信拿不到真实身份。这时候通常是微信认证加手机号二次校验，把两者绑到主账号。设计时要分清楚：哪类用户走微信、哪类必须走手机号实名、两者的账号怎么并。混着用却不打通，最后就是一堆重复账号。

学工号这类校园身份的特殊性

校园场景里，学工号背后连着教务、人事、宿管多个系统，WiFi认证如果能和统一身份认证对接，学生入学自动开通、毕业自动注销，运维量能少一大半。难的是校园身份系统往往年代久远、接口不标准，有的还是定制的。对接前要先确认对方提供什么协议、什么字段、有没有测试环境。我们做高校项目时，通常要花不少时间和信息化办公室对齐接口文档，比写代码花的时间还多。这块急不得，前期对齐越细，后期半夜救火越少。

访客账号和内部账号必须分开治理

打通内部身份的同时，访客账号要单独处理。访客不应该进内部身份体系，否则一个临时访客的账号混在工号里，既不安全也不好清理。建议访客走独立的匿名或半实名通道，生命周期短、权限受限，到期自动清理。我们见过一个单位把访客也建进AD域，结果域里堆了几千个早已离场的访客账号，没人敢删，最后成了严重的安全隐患。内外账号分治，是账号体系设计的基本纪律。

对接失败要有降级方案

再稳的身份源也有抽风的时候，域控宕机、微信接口限流、学工号系统维护，都可能让认证走不通。设计时要问一句：主身份源挂了，用户还能不能正常上网？常见的降级是临时切到手机号认证，或者给已认证用户一个宽限期。我们没有见过哪个单位的身份系统全年零故障，所以降级不是多余，是必须。方案里要明确写清降级触发条件和恢复流程，别等出事时现场拍脑袋。