企业Portal认证系统对接AD域账号的实操与坑

企业办公网上Portal认证系统，最常见的一个诉求是对接AD域账号。员工上班连WiFi，用自己的域账号密码登录，IT不用单独再发一套上网账号，离职销户跟着AD走，运维省一大截。想法很顺，真对接起来坑不少。我遇到过不少项目，设备能弹页、能输密码，但 sync 不到AD的组和OU，策略全失效，最后又回到手动维护账号。

对接不是透传账号密码那么简单

很多人的理解是，Portal把用户名密码丢给AD验一下就完事。这只能算认证通过，谈不上对接。真正有用的对接，是Portal能从AD拉到这个账号的OU和所属组，比如属于哪个部门、哪个楼层、是不是访客。有了这些信息，才能做策略：研发网段只能研发进，访客只能上互联网。只做账号密码透传，等于把一套精细的权限体系降级成一根开关。

所以对接前先想清楚要哪些字段。Portal系统和AD之间靠LDAP协议通信，属性映射要配对，比如sAMAccountName对应登录名，memberOf对应组。字段名写错一个，拉到的就是空，策略自然不生效。这一步最好让懂AD的人一起看，别让只懂网络的工程师闭门配。

同步延迟和账号状态

第二个坑是状态不同步。员工今天离职，AD里禁用账号，但Portal本地缓存没刷新，人还能上三天网。反过来，新员工账号刚建，Portal那边还没同步，当天连不上。这两类问题都出在同步机制上。靠谱的做法是Portal定期从AD拉全量或者增量，关键操作（离职、禁用）尽量实时触发同步，而不是纯靠定时任务。

密码过期也是高频问题。域策略要求每90天改密，员工改完域密码， Portal如果缓存了旧密码哈希，下次登录就失败。有些Portal系统支持走AD的实时校验而不是本地存密码，能避开这个问题，但配置复杂些。项目初期容易忽略这个，等到第一次批量改密日才爆雷。

OU分组映射决定策略粒度

最有价值也最容易做错的是OU和组的映射。企业网络常常按楼层、按部门划分VLAN，Portal要根据AD里的部门属性把人分到对应VLAN。映射表配错，销售连进了研发网段，合规上就是事故。建议先在测试OU上跑通映射逻辑，再用小批量真实账号验证，确认分组和VLAN对齐了，再全量切。

还有访客账号的问题。AD里一般不给访客建正式账号，Portal要能识别临时访客并走独立通道，不能让访客蹭着员工OU拿到内网权限。很多对接方案漏了这层，访客扫码进来直接进了员工网段，这是实打实的安全缺口。

对接AD域这件事，技术门槛不在连得上，而在字段、状态、分组三件事都对齐。只要有一处没对齐，系统看起来能跑，策略其实是虚的。项目验收时别只测登录成功，要测离职禁用、改密失败、访客隔离这些边界场景，才算真的对接明白。

测试环境先跑通再切生产

对接AD这种涉及账号体系的改动，千万别直接在生产网动。先搭一个测试OU，放几个真实账号，把字段映射、状态同步、分组VLAN全跑一遍，确认离职禁用、改密失败、访客隔离都符合预期，再小批量切真实部门，最后全量。生产网直接改，一旦映射错了，可能影响一片人正常上网，回滚都来不及。测试环境多花的那两天，省的是上线当晚的救火。

日志能帮上大忙

对接过程中，Portal和AD之间的认证日志要打开。哪个账号同步失败、哪个组没拉到、哪次登录走了本地缓存还是实时校验，日志里一目了然。很多单位对接完就把日志关了，出问题时两眼一抹黑，只能猜。保留一段时间的对接日志，平时占点空间，真出边界case时是定位的唯一线索。运维省力不靠关日志，靠日志看得懂。

权限最小化原则

Portal从AD拉字段，遵循最小必要。只拉认证和策略要的，比如登录名、部门、状态，别顺手把手机号、邮箱全拉过来存着。拉得越多，数据保管责任越重，泄露风险越高。很多对接为了省事一股脑同步全部属性，后面审计发现问题一大堆。对接前列清楚策略真需要的字段，多余的坚决不碰，既是合规也是自保。

把对接结果文档化

对接做完，把字段映射表、同步频率、失败处理逻辑写成文档，随系统交接。运维换人或者厂商更替时，新接手的人照文档能看懂当初怎么配的。我们见过对接是人走的，文档没留，半年后策略要改，没人敢动，怕改坏。知识留在一个人脑子里最脆弱，落在文档里才扛得住人员流动。

和单点登录的关系

对接AD域账号，往上一步就是单点登录。员工用域账号登录办公网，同时也用这个身份进OA、进内网应用，一套账号走全身。Portal对接AD是单点登录在网络的落点。项目值不值得做单点，看企业应用是不是已经或者打算统一身份。如果其他系统还是各管各的账号，只把Portal接了AD，价值就打了折扣。身份统一是系统工程，Portal对接是其中一环，想清楚全局再动手。