Gitlab CE 10.6集成CAS后，如何同步CAS密码至Gitlab？

首先得明确一个核心点：CAS协议的设计本身不支持返回用户明文密码或可直接复用的密码哈希——它是一种"断言式"认证机制，只负责告诉GitLab"这个用户身份合法"，不会传递密码相关的敏感信息。所以GitLab OmniAuth的CAS集成没有直接的配置项能实现自动同步密码的功能。

接下来给你几个可行的解决方案，结合你的场景（CAS对接双AD+用户库）来选择：

方案1：切换为GitLab直接集成LDAP（推荐） #

既然你的CAS已经对接了Active Directory，那其实可以让GitLab直接配置LDAP认证（支持多LDAP源），这样：

• 用户登录GitLab时直接用AD密码验证，GitLab不需要存储密码，完全依赖AD做身份校验，自然也就没有"同步密码"的需求
• 同时你可以保留CAS作为其他系统的认证入口，GitLab的LDAP认证和CAS认证可以共存（通过OmniAuth启用多个provider）
• 配置步骤：在gitlab.rb里添加LDAP配置段，针对两个AD分别设置gitlab_rails['ldap_servers']，核心配置逻辑围绕LDAP服务器地址、绑定账号、用户检索规则展开。

方案2：扩展CAS服务器+自定义GitLab OmniAuth处理逻辑 #

如果必须保留CAS作为唯一认证入口，那需要做一些定制开发：

1. 修改CAS服务器：在CAS的认证流程中，从AD或用户数据库中获取用户的密码哈希（注意：AD默认不允许读取明文密码，只能获取NTLM/MD5等哈希，且需要特殊权限），并在CAS返回的断言属性中添加这个哈希字段
2. 定制GitLab的OmniAuth CAS策略：修改GitLab的CAS认证逻辑，在用户自动注册或登录时，将CAS返回的密码哈希转换为GitLab兼容的格式（比如默认的bcrypt）后，写入GitLab的用户密码字段——这需要修改GitLab的代码，或者编写OmniAuth的自定义钩子来实现

• 注意：这种方式存在安全风险，因为密码哈希在网络中传输（即使是HTTPS），且需要保证哈希格式的兼容性，维护成本较高。

方案3：利用GitLab API实现半自动同步 #

如果不想修改代码，可以借助GitLab的API和CAS的后置钩子：

1. 在CAS服务器上配置认证成功后的钩子，当用户首次通过CAS登录时，触发一个脚本
2. 脚本从你的用户数据库中获取用户的初始密码（如果是AD的话，可能需要提前导出初始密码，或者在用户重置AD密码后触发同步）
3. 调用GitLab的PUT /users/:id API，设置用户的密码

• 局限性：如果用户在AD中修改密码，这个方案无法自动同步，需要额外的定时任务来做周期性同步，且AD密码的获取本身是个难题（AD默认不允许直接读取密码）。

额外提醒 #

你的GitLab CE 10.6版本非常老旧，已经不在官方支持范围内，存在安全漏洞和功能限制。如果可能的话，建议先升级到较新的版本，新版本的OmniAuth和LDAP集成有更多的功能和更好的安全性。

内容的提问来源于stack exchange，提问作者José Hidalgo