企业WiFi认证回答"你是谁"这件事，本质上是把一份身份清单交给认证系统去判断。身份从哪里来、谁来维护、员工离职后怎么停，决定了这套认证好不好管。按账号来源划分，企业场景常见有四类：认证系统本地账号本、AD域或LDAP统一身份、企业办公应用账号（企业微信、钉钉、飞书）、以及OA或其他第三方业务系统数据源。四类不是互斥关系，成熟企业往往是"员工走一类、访客走另一类"的组合，但各自的前提条件和运维责任差别很大，选型前需要分清楚。
第一类：认证系统本地账号本
本地认证就是人员信息保存在认证系统自己的数据库里，管理员在后台逐个新增、修改、停用账号，员工用分配的用户名密码或者账号密码加短信验证码完成认证。它不依赖任何外部系统，部署简单、数据完全自控，适合人数不多、没有统一目录服务、或者访客临时账号为主的小企业、独立办公点。
它的主要痛点是两套账号并行：员工本来有办公系统账号，WiFi又得再建一份，新员工入职要在两边录入，离职时容易漏停WiFi账号，留下账号长期有效、人走网还在的隐患。本地账号本管理成本会随人数线性上升，而且密码强度、有效期策略都要靠本地系统自己约束。它适合作为基础能力和访客临时账号的落脚点，不建议作为几百人企业员工认证的唯一来源。
第二类：AD域或LDAP统一身份
第二类是和企业现有的Windows AD域或者LDAP目录对接，员工直接用域账号登录WiFi，账号的创建、改密、停用全部跟随企业目录，认证系统只做校验和放行，不另建一份人员数据。这正是很多中大型企业最想要的效果：人员变动在人事和域管理流程里完成，网络侧自动跟随，避免重复维护。安全等级上，LDAP域认证属于偏高的一档，适合对内部身份管理有规范要求的政企和规模企业。
但对接有明确前提，不能听到"支持LDAP"就认为一定能打通。首先域控制器要开放认证接口、允许认证服务器发起校验；其次账号字段要能映射，比如登录名、部门、用户组、是否禁用这些属性对得上；还要规划域控制器不可用时的兜底策略，是本地缓存放行还是拒绝新登录，提前定好。这些接口、字段、权限和联调窗口都需要现场确认，属于"可按需对接、需结合现网条件验证"的能力，而不是无条件直连。现网没有AD域、也没有目录规划的企业，为了WiFi单独搭一套域服务，通常要权衡投入是否合理。
第三类：企业微信、钉钉、飞书等办公应用账号
第三类是通过企业在用的移动办公应用完成认证，员工在自己的企业微信、钉钉或飞书里完成身份校验后接入WiFi，不需要再记一套WiFi专用密码。它的体验好、和日常办公习惯贴合，管理员也不需要独立维护密码本，账号状态跟随组织架构。对已经全面使用某款办公应用的团队，这条路线上手快、接受度高。
需要注意两点：一是具体对接哪款应用、支持到什么程度，要以该应用开放的接口能力和认证系统的实际对接方式为准，立项前确认接口授权、字段获取和组织架构同步方式；二是这类认证依赖应用服务可用性，办公应用服务波动或员工手机未登录时，要设计备用登录通道，比如本地账号或短信验证码兜底，避免全员被挡在门外。第三方系统自身故障会连带影响认证，这是架构层面必须考虑的风险。
第四类：OA、考勤、一卡通等第三方业务数据源
第四类是把认证信息来源接到企业已有的OA系统、人事数据库、门禁或一卡通等第三方数据源，员工在业务系统里的在册状态作为WiFi准入依据。这种做法的价值在于复用已有管理成果，减少人工录入，理论上还能和人员在岗状态挂钩。但它对接口规范要求最高：要确认数据源是否提供查询接口、能否按账号返回"有效/失效"状态、数据更新延迟多久、是否有开放文档。如果现有系统是封闭老版本、只导出表格不提供接口，强行对接就要额外开发，成本和周期都要重新评估，不能简单写成"支持OA对接"。
账号回收与断链兜底不能漏
无论身份来自哪里，账号回收都是管理成败的关键。员工离职、转岗、外包结束时，要在身份源侧停用并让网络准入及时跟随，避免出现"人事系统已离职、网络账号仍在线"的空档；外部对接断开或数据同步异常时，要有明确的本地处理规则，比如限制新增授权、保留已通过会话还是按安全策略要求及时断开，这些规则要在联调前和管理员约定清楚。对临时账号和访客凭据，则坚持按有效期发放、到期自动失效，不长期保留默认密码。身份来源解决的是"用谁的身份认证"，回收和兜底解决的是"身份变化后网络能不能跟上"，两者合起来才算完整的账号管理。
四类来源怎么搭配
实际项目里常见的组合是：固定员工走域或者办公应用账号，保证离职自动回收；访客和临时人员走本地账号、短信或扫码授权，到期失效；无法承载浏览器的设备走白名单或固定凭据。选型时先盘点企业已经有哪类身份源，优先复用已有系统，缺什么补什么，而不是为了技术齐全把四类全部接进来。账号来源一旦确定，还要配套定期核对机制，确认离职人员在各身份源里的停用确实同步到了网络准入，这才是管理闭环，而不是把认证方式选完就结束。