企业Portal认证对接AD域和LDAP的坑：账号源打通前要想清楚

企业Portal认证要真正落地，几乎绕不开和现有账号体系对接。大多数公司的人事账号在AD域，有的还叠了LDAP，Portal认不认这些源，直接决定员工要不要再记一套密码。对接看起来是技术活，实际前面一堆管理问题没想清楚，后面一定会返工。我接触过的项目里，卡在账号源上的比卡在设备上的多得多。

先确认你到底有几个账号源

不少企业以为自己只有AD，真去梳理才发现，老系统用的是本地账号，新系统挂在LDAP上，还有一部分外包人员根本不在域里。Portal对接前不把这些源摸清楚，上线后就会出现一部分人能登、一部分人登不了。更麻烦的是历史账号：有人离职了AD里没删，Portal如果只做正向同步不做清理，僵尸账号就成了安全隐患。对接之前先把账号家底盘一遍，这步省不得。

域控权限别随便给Portal

Portal要和AD通信，通常要一个服务账号。很多实施方图省事，直接给个域管理员权限，理由是调试方便。这在大企业是绝对不能接受的，一旦Portal这台机器被攻破，攻击者就握着整个域的钥匙。正确做法是建一个只读、限定OU的服务账号，只够它验证用户和密码。权限给多容易，收回来难，这个口子从一开始就别开。

字段映射的坑比想象中深

AD里的字段和Portal要的字段经常对不上。比如Portal要手机号做二次验证，AD里这个字段可能空着，或者格式不统一。再比如部门字段，有的公司用数字编码，Portal要的是可读名称。这些映射如果不提前约定，上线后员工登录会各种奇怪报错。我的习惯是先把两张字段表摊开对齐，把空值、异常值都列出来，再让实施方写同步逻辑，而不是边跑边补。

同步频率决定了体验

账号改动要多久反映到Portal上，这件事直接影响员工感受。实时同步最理想，但对域控压力大，也不是所有Portal都支持。定时同步的话，员工改了密码要等下一个周期才能登，抱怨就来了。折中的做法是关键事件触发同步，比如密码重置、账号禁用时立刻推一次。具体选哪种，看你们账号变动的频繁程度，变动少的可以定时，变动多的得上触发。

对接完一定要做反向验证

很多人验证对接是否成功，只测自己那个账号能登。这不够。真正该测的是：禁用一个AD账号，Portal是不是马上拒绝；修改密码后旧密码是否失效；不在白名单里的账号是否进不来。这几条不过，对接就只是看起来通了。我建议上线前专门列一张异常用例表，让实施方逐条演示，别信口头保证。账号源是安全的第一道门，这里糊弄，后面再好的策略也白搭。

密码策略也要提前对齐。AD里的密码复杂度要求和Portal里的是否一致，不一致员工会困惑。更关键的是Portal自己的失败锁定次数，设太严员工输错几次就被锁，设太松又容易被暴力破解。这个值和AD的锁定策略最好同源。我见过因为两边锁定阈值不同，员工在Portal被锁了但AD里好好的，IT两头查半天查不出原因的笑话。

上线后的交接别忽视。对接做完，实施方一走，你们自己的人要能改配置、查日志。很多项目交付时只给了操作手册的截图，真出问题没人敢动。建议上线同期做一次内部培训，让至少两个人能独立处理账号源相关的故障。账号源是根基，根基的维护能力不能只捏在实施方手里。

小结

企业Portal认证对接AD域和LDAP，技术只是三分之一，前面账号盘点、权限收敛、字段对齐这三件事做不好，后面怎么调都别扭。先把管理问题想透，对接才是顺理成章的水到渠成。

证书认证也可以作为补充。对于服务账号、设备这类不会输密码的主体，Portal支持证书认证时，对接AD的机器账号会更顺。但这要求AD的证书服务也健康，又是另一个依赖。要不要上证书，看你们有没有无人类主体要认证，没有的话先别碰，复杂度不值得。

最后提醒一句：对接文档要留底。账号源的结构、字段映射、同步方式，这些当时想得清清楚楚，半年后换人就全忘了。把对接的设计写成一份简短文档存好，比依赖某个人的记忆可靠。账号源是安全的根基，根基的来龙去脉得写得明白。

上线节奏也要有讲究。账号源对接建议选在业务低峰期，比如周末或夜间，因为同步过程可能短暂影响登录。很多实施方图方便白天就切，结果上班高峰一堆人登不进去，投诉电话被打爆。这种事本可避免，只是没把业务节律放在心上。技术切换永远要考虑人在什么时候用它。

对接完成后别急着关旧通道。很多人一验证通了，立刻把老的本地账号停掉，结果有批边缘系统还在用旧账号，一夜之间全瘫。正确做法是新旧并行一段时间，观察没有遗留依赖再回收。账号源迁移最怕一刀切，平滑过渡才是真稳妥。