Rancher

测试版本:2.7.x

参考文档:http://ranchermanager.docs.rancher.com/zh/pages-for-subheaders/configure-openldap

Nexus3

配置步骤

登录 Nexus 管理账户,进入配置界面

依次点击 Security >> LDAP 进入配置页面

点击 "Create Connection" 创建 LDAP 连接

配置说明:

  • name:此连接的名称,可自定义
  • LDAP server address
    • Protocol:是否启用 SSL,是选用 LDAPS,否则选用 LDAP
    • Hostname:LDAP 的服务器地址
    • Port:LDAP 端口号
  • Search base:基本 DN,即一般从域的根节点开始搜索,如 dc=test,dc=com
  • Authentication method:加密方式
  • Username or DN:输入用于获取 LDAP 用户的账户,建议使用只读账户
    • 用户名:格式为 用户名@域名,如 userget@test.com
    • password:输入用户的密码
  • Connection rules:连接规则
    • 第一个选框:超时时间,单位 秒
    • 第二个选框:多少秒后重试
    • 第三个选框:失败尝试次数

服务器信息填写完成后,点击 Verify connection 测试连接

右上角弹出测试结果,如测试连接失败,检查配置信息是否有误。

测试成功后,点击 next 进入 LDAP 用户和组配置

  • 情景一:所有用户都在 Users 根节点下
    • 视情况选择 Configuration template 为 Active Directory 或者 generic ldap server,所有配置默认即可
  • 情景二:大部分用户在 Users 目录中,但还有其他目录存在用户
    • 视情况选择 Configuration template 为 Active Directory 或者 generic ldap server
    • 勾选 User subtree 下的复选框
    • 其他配置信息默认
  • 情景三:其他情况
    • 视情况选择 Configuration template 为 Active Directory 或者 generic ldap server
    • 去掉 Base DN 默认值
    • 勾选 User subtree 下的复选框
    • 输入 User filter,值为:(&(objectCategory=Person)(sAMAccountName=*))

点击 Verify user mapping 测试获取用户列表

点击 Verify login 测试 LDAP 用户登录

点击 Save 保存,退出当前用户,使用 LDAP 用户登录,配置完成

Rancher2.6/7 Monitoring Grafana

先决条件

  • Rancher:2.6.x/2.7.x
  • k8s:1.24.x
  • monitoring:100.1.2+up19.0.3
  • OpenLDAP:latest

Grafana 对接 LDAP

编辑 Monitoring Yaml 配置 LDAP

Edit YAML

访问 Rancher explorer UI,进入 Apps & Marketplace,选择 Monitoring,在配置选项中选择 Edit YAML:

开启 LDAP 认证配置

grafana.grafana.ini 层级下新增如下 auth.ldap 配置信息开启 LDAP:

1
2
3
4
5
6
grafana:
grafana.ini:
auth.ldap:
allow_sign_up: true
config_file: /etc/grafana/ldap.toml
enabled: true

grafana 层级下,添加 LDAP 认证参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
grafana:
ldap:
config: |
[[servers]]
host = "test.zerchin.xyz"
port = 389
use_ssl = false
start_tls = false
ssl_skip_verify = true
bind_dn = "cn=admin,dc=rancherldap,dc=com"
bind_password = 'Rancher123'
search_filter = "(cn=%s)"
search_base_dns = ["cn=group,ou=rancher,dc=rancherldap,dc=com"]
[servers.attributes]
name = "givenName"
surname = "sn"
username = "cn"
member_of = "memberOf"
email = "email"
enabled: true
参数说明
  • host:LDAP 服务器地址(IP/Domain,指定多个地址空格分隔)。
  • port:LDAP 端口,默认是 389,如果 use_ssl=true 则是 636。
  • use_ssl:是否使用加密 TLS 连接。
  • start_tls:STARTTLS 是一种明文通信协议的扩展,能够让明文的通信连线直接成为加密连线(使用 SSL/TLS 加密),而不需要使用另一个特别的端口来进行加密通信。
  • ssl_skip_verify:是否跳过 SSL 证书验证。
  • bind_dn:LDAP 服务账户用户名。
  • bind_password:密码(如果密码包含 #,则需要用三个括号引起来,例如:"""#password;""")。
  • search_filter:用户查询过滤字段,例如 "(cn=%s)""(sAMAccountName=%s)""(uid=%s)"
  • search_base_dns:用户搜索起点。

配置好之后启动监控

等待监控启动成功后,打开 Grafana UI 界面,默认账号密码为:admin/prom-operator

LDAP 验证

登录之后,左侧进入 Server Admin - LDAP,在 LDAP Connection 下可以看到连接的主机。

在 Test user mapping 下,搜索存在的 LDAP 用户,可以查到用户信息。

Elastic Stack

先决条件

保证 Elasticsearch 是白金版以上,破解教程参考站内 elasticsearch 7.x 白金破解

参考

修改配置文件

elasticsearch.yml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
cluster.name=elasticsearch-cluster
node.name=es-node1
network.host=0.0.0.0
network.publish_host=node1.elastic.com
http.port=9200
transport.tcp.port=9300
http.cors.enabled=true
http.cors.allow-origin=*
discovery.type=single-node
node.master=true
node.data=true
discovery.seed_hosts[0]=node1.elastic.com
discovery.zen.minimum_master_nodes=1
http.cors.allow-headers=Authorization
bootstrap.memory_lock=true
# es 开启 xpack 的前提是,必须配置 ssl,所以此处必须有
xpack.security.enabled=true
xpack.security.http.ssl.enabled=true
xpack.security.transport.ssl.enabled=true
xpack.security.http.ssl.key=/usr/share/elasticsearch/config/certs/es-node1.key
xpack.security.http.ssl.certificate=/usr/share/elasticsearch/config/certs/es-node1.crt
xpack.security.http.ssl.certificate_authorities=/usr/share/elasticsearch/config/certs/ca.crt
xpack.security.transport.ssl.key=/usr/share/elasticsearch/config/certs/es-node1.key
xpack.security.transport.ssl.certificate=/usr/share/elasticsearch/config/certs/es-node1.crt
xpack.security.transport.ssl.certificate_authorities=/usr/share/elasticsearch/config/certs/ca.crt
# 此处是配置 ldap 认证的核心信息
xpack.security.authc.realms.ldap.ldap1.order=0
xpack.security.authc.realms.ldap.ldap1.url=ldap://<ldapIp>:<ldapPort>
xpack.security.authc.realms.ldap.ldap1.bind_dn=cn=admin,dc=extension,dc=sopei
xpack.security.authc.realms.ldap.ldap1.bind_password=xxxxxx
xpack.security.authc.realms.ldap.ldap1.user_search.base_dn=ou=people,dc=extension,dc=sopei
xpack.security.authc.realms.ldap.ldap1.user_search.filter=(cn={0})
xpack.security.authc.realms.ldap.ldap1.unmapped_groups_as_roles=false
# role_mapping.yml,可配置可不配,就放这里参考下,一般通过 api 配置映射关系。因为通过文件的形式需要每个 node 都存放一份。
# xpack.security.authc.realms.ldap.ldap1.files.role_mapping=/usr/share/elasticsearch/config/role_mapping.yml

role_mapping.yml

1
2
3
4
5
# 如下所示,superuser 是在我们的 Elasticsearch 中已经定义好的 role。赋予如下账户 superuser 角色
superuser:
- "cn=liuxg,ou=users,dc=example,dc=com"
- "cn=xgliu,ou=users,dc=example,dc=com"
- "employeeNumber=1,ou=users,dc=example,dc=com"

API

1
2
POST /_security/role_mapping/<name>
PUT /_security/role_mapping/<name>

先决条件

  • 要使用此 API,你至少具有 manage_security 集群权限。

描述

角色映射定义分配给每个用户的角色。每个映射都有识别用户的规则和授予这些用户的角色列表。

角色映射 API 通常是管理角色映射的首选方式,而不是使用角色映射文件。创建或更新角色映射 API 无法更新角色映射文件中定义的角色映射。

此 API 不创建角色。相反,它将用户映射到现有角色。可以使用创建或更新角色 API角色文件来创建角色。

有关详细信息,参阅将用户和组映射到角色

角色模板

角色映射最常见的用途是创建从用户的已知值到固定角色名称的映射。例如,cn=admin,dc=example,dc=com 应该为 LDAP 组中的所有用户赋予 superuser Elasticsearch 中的角色。该 roles 字段用于此目的。

对于更复杂的需求,可以使用 Mustache 模板动态确定应授予用户的角色名称。该 role_templates 字段用于此目的。

要成功使用角色模板,必须启用相关的脚本功能。否则,使用角色模板创建角色映射的所有尝试都会失败。参阅允许的脚本类型设置

角色映射中可用的所有用户字段 rules 在角色模板中也可用。因此,可以将用户分配给反映他们的 username、他们的 groups 或他们验证的 realm 名称的角色。

默认情况下,评估模板以生成单个字符串,该字符串是应分配给用户的角色的名称。如果 format 模板的设置为 "json" 那么模板应该为角色名称生成一个 JSON 字符串或一个 JSON 字符串数组。

路径参数

  • name

    (字符串)标识角色映射的独特名称。该名称仅用作标识符,以促进通过 API 进行交互;它不会以任何方式影响映射的行为。

主体参数

以下参数可以在 PUT 或 POST 请求的主体中指定,并且与添加角色映射有关:

  • enabled

    (Required, Boolean) 执行角色映射时忽略已 enabled 设置为 false 的映射。

  • metadata

    (对象)帮助定义分配给每个用户的角色的附加 metadata 字段。在该 metadata 对象中,以 _ 开头的键保留供系统使用。

  • roles

    (字符串列表)授予与角色映射规则匹配的用户的角色名称列表。必须指定 rolesrole_templates 中的一个。

  • role_templates

    (对象列表)Mustache 模板列表,将对其进行评估以确定应授予与角色映射规则匹配的用户的角色名称。这些对象的格式定义如下。必须指定 rolesrole_templates 中的一个。

  • rules

    (必需,对象)确定映射应匹配哪些用户的规则。规则是使用 JSON DSL 表达的逻辑条件。参阅 角色映射资源

例子

以下示例将 "user" 角色分配给所有用户:

1
2
3
4
5
6
7
8
9
10
11
POST /_security/role_mapping/mapping1
{
"roles": [ "user"],
"enabled": true,
"rules": {
"field" : { "username" : "*" }
},
"metadata" : {
"version" : 1
}
}

执行角色映射时,已 enabled 设置为 false 的映射将被忽略。

metadata 字段是可选的。

成功的调用会返回一个 JSON 结构,显示映射是已创建还是已更新。

1
2
3
4
5
{
"role_mapping" : {
"created" : true
}
}

更新现有映射时,created 设置为 false。

以下示例将 "user" 和 "admin" 角色分配给特定用户:

1
2
3
4
5
6
7
8
POST /_security/role_mapping/mapping2
{
"roles": [ "user", "admin" ],
"enabled": true,
"rules": {
"field" : { "username" : [ "esadmin01", "esadmin02" ] }
}
}

以下示例匹配针对特定领域进行身份验证的用户:

1
2
3
4
5
6
7
8
POST /_security/role_mapping/mapping3
{
"roles": [ "ldap-user" ],
"enabled": true,
"rules": {
"field" : { "realm.name" : "ldap1" }
}
}

以下示例匹配用户名是 esadmin 或用户在 cn=admin,dc=example,dc=com 组中的任何用户:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
POST /_security/role_mapping/mapping4
{
"roles": [ "superuser" ],
"enabled": true,
"rules": {
"any": [
{
"field": {
"username": "esadmin"
}
},
{
"field": {
"groups": "cn=admins,dc=example,dc=com"
}
}
]
}
}

当你的身份管理系统(例如 Active Directory 或 SAML 身份提供商)中的组名称与 Elasticsearch 中的角色名称没有一对一的对应关系时,上面的示例很有用。角色映射是将组名与角色名链接起来的方法。

但是,在极少数情况下,你的组名称可能与你的 Elasticsearch 角色名称完全匹配。当你的 SAML 身份提供者包含自己的"组映射"功能并且可以配置为在用户的 SAML 属性中发布 Elasticsearch 角色名称时,就会出现这种情况。

在这些情况下,可以使用将组名称视为角色名称的模板。

注意:仅当你打算为所有提供的组定义角色时才应执行此操作。将用户映射到大量不必要或未定义的角色是低效的,并且会对系统性能产生负面影响。如果你只需要映射组的一个子集,那么你应该使用显式映射来执行此操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
POST /_security/role_mapping/mapping5
{
"role_templates": [
{
"template": { "source": "{{#tojson}}groups{{/tojson}}" },
"format" : "json"
}
],
"rules": {
"field" : { "realm.name" : "saml1" }
},
"enabled": true
}

mustache 函数 tojson 用于将组名列表转换为有效的 JSON 数组。

因为模板生成一个 JSON 数组,所以格式必须设置为 json

以下示例匹配特定 LDAP 子树中的用户:

1
2
3
4
5
6
7
8
POST /_security/role_mapping/mapping6
{
"roles": [ "example-user" ],
"enabled": true,
"rules": {
"field" : { "dn" : "*,ou=subtree,dc=example,dc=com" }
}
}

以下示例匹配特定领域中特定 LDAP 子树中的用户:

1
2
3
4
5
6
7
8
9
10
11
POST /_security/role_mapping/mapping7
{
"roles": [ "ldap-example-user" ],
"enabled": true,
"rules": {
"all": [
{ "field" : { "dn" : "*,ou=subtree,dc=example,dc=com" } },
{ "field" : { "realm.name" : "ldap1" } }
]
}
}

规则可能更复杂,包括通配符匹配。例如,以下映射匹配满足所有这些条件的任何用户:

  • 可分辨名称与模式匹配 *,ou=admin,dc=example,dc=com,或者用户名是 es-admin,或者用户名是 es-system
  • cn=people,dc=example,dc=com 群组中的用户
  • 用户没有 terminated_date
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
POST /_security/role_mapping/mapping8
{
"roles": [ "superuser" ],
"enabled": true,
"rules": {
"all": [
{
"any": [
{
"field": {
"dn": "*,ou=admin,dc=example,dc=com"
}
},
{
"field": {
"username": [ "es-admin", "es-system" ]
}
}
]
},
{
"field": {
"groups": "cn=people,dc=example,dc=com"
}
},
{
"except": {
"field": {
"metadata.terminated_date": null
}
}
}
]
}
}

模板化角色可用于自动将每个用户映射到他们自己的自定义角色。角色本身可以通过 Roles API 或使用 自定义角色提供程序来定义。

在此示例中,每个使用 "cloud-saml" 领域进行身份验证的用户都将自动映射到两个角色 - 角色 "saml_user" 和一个角色,其用户名前缀为 _user_。例如,用户 nwong 将被分配 saml_user_user_nwong 角色。

1
2
3
4
5
6
7
8
9
POST /_security/role_mapping/mapping9
{
"rules": { "field": { "realm.name": "cloud-saml" } },
"role_templates": [
{ "template": { "source" : "saml_user" } },
{ "template": { "source" : "_user_{{username}}" } }
],
"enabled": true
}

因为不可能在同一个角色映射中同时指定 rolesrole_templates,所以我们可以通过使用没有替换的模板来应用"固定名称"角色。

实战

这里我们仅创建两种 mapping,一种 admin,一种 basic_user

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# GET /_security/role_mapping/admins
# DELETE /_security/role_mapping/admins
# GET /_security/role_mapping/basic_users
# DELETE /_security/role_mapping/basic_users

# 对管理员的绑定
PUT /_security/role_mapping/admins
{
"roles" : [ "superuser" ],
"rules" : { "field" : {
"dn" : "uid=xiaowu,ou=people,dc=extension,dc=sopei"
} },
"enabled": true
}

# 对普通用户的绑定,例子中仅对开发组成员赋权
PUT /_security/role_mapping/basic_users
{
"enabled" : true,
"roles" : [
"log-all-viewer",
"devlopment",
"reporting_user"
],
"rules" : {
"any" : [
{
"field" : {
"groups" : "cn=od-3d5d12d234493102cbc1ceef154d9c38,ou=feishuroot,dc=extension,dc=sopei"
}
}
]
},
"metadata" : { }
}

问题

LDAP 用户删除后仍可登录

Elasticsearch 与 LDAP 集成时,用户的身份验证是通过 LDAP 服务器进行的。如果你已经在 Elasticsearch 中配置了 LDAP 集成,并且已经删除了 LDAP 中的用户,则该用户将无法再登录 LDAP 服务器,但仍然可以登录 Elasticsearch。这是因为 Elasticsearch 缓存了先前身份验证的用户凭据,以便在将来的请求中使用,而不是每次都要向 LDAP 服务器发出身份验证请求。

配置会话缓存时间

参考:https://www.elastic.co/guide/en/elasticsearch/reference/master/security-settings.html#ref-ldap-settings

在默认情况下,Elasticsearch 的 LDAP 集成会缓存 LDAP 用户凭据,以便在将来的请求中使用。缓存的时间取决于 Elasticsearch 配置中 cache.ttl 参数的设置,默认值为 20m,这意味着,如果你删除了 LDAP 中的用户,该用户在 Elasticsearch 中的访问仅受到缓存的时间限制,通常会在 20m 内失效。

Jumpserver

参考:https://docs.jumpserver.org/zh/v2/admin-guide/authentication/ldap/

Yearning

项目地址:https://github.com/cookieY/Yearning

参考:http://next.yearning.io/guide/config/ldap.html

Sonarqube

参考地址:https://docs.sonarqube.org/latest/instance-administration/authentication/ldap/

修改 <SONARQUBE_HOME>/conf/sonar.properties

示例配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# LDAP configuration
# General Configuration
sonar.security.realm=LDAP
ldap.url=ldap://myserver.mycompany.com
ldap.bindDn=admin_bind_dn
ldap.bindPassword=admin_bind_password

# User Configuration
ldap.user.baseDn=ou=Users,dc=mycompany,dc=com
ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

# Group Configuration
ldap.group.baseDn=ou=Groups,dc=sonarsource,dc=com
ldap.group.request=(&(objectClass=groupOfUniqueNames)(uniqueMember={dn}))

Yapi

项目地址:https://github.com/fjc0k/docker-YApi

注:Yapi 默认以用户名和邮箱为唯一标准,所以最好将 Yapi 库中存储账户邮箱改成和 LDAP 一一对应的,这样依赖就可以直接继承下原 Yapi 库下的账户。

这里贴下将原有邮箱后缀改成指定邮箱后缀的 mongo sql:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 将 email 字段中以 sopei.yapi 结尾的数据全部改成以 @eryajf.net 结尾
db.user.updateMany(
{ email: { $regex: /@sopei.yapi$/ } },
[
{
$set: {
email: {
$concat: [
{ $arrayElemAt: [{ $split: ['$email', '@'] }, 0] },
'@eryajf.net'
]
}
}
}
]
)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
version: '3'

services:
yapi-web:
image: jayfong/yapi:1.10.2
container_name: yapi-web
ports:
- 40001:3000
environment:
- YAPI_ADMIN_ACCOUNT=admin@xxx.yapi
- YAPI_ADMIN_PASSWORD=xxx
- YAPI_NPM_REGISTRY=https://registry.npm.taobao.org
- YAPI_CLOSE_REGISTER=true
- YAPI_DB_SERVERNAME=<mongoIp>
- YAPI_DB_PORT=<mongoPort>
- YAPI_DB_DATABASE=<mongoDatabase>
- YAPI_DB_USER=<mongoUser>
- YAPI_DB_PASS=<mongoPass>
- YAPI_DB_AUTH_SOURCE=<MongoDB 身份认证所用库>
- YAPI_MAIL_ENABLE=false
- YAPI_LDAP_LOGIN_ENABLE=true
- YAPI_LDAP_LOGIN_SERVER=ldap://<ldapIp>:<ldapPort>
- YAPI_LDAP_LOGIN_BASE_DN=<ldap管理员dn>
- YAPI_LDAP_LOGIN_BIND_PASSWORD=<ldap管理员密码>
- YAPI_LDAP_LOGIN_SEARCH_DN=<ldap用户搜索范围>
# 下面这个是 user filter,按此格式进行进行修改
- YAPI_LDAP_LOGIN_SEARCH_STANDARD=&(objectClass=inetOrgPerson)(cn=%s)
# 邮箱后缀,经测试似乎没啥用
- YAPI_LDAP_LOGIN_EMAIL_POSTFIX='@eryajf.net'
# ldap 映射字段
- YAPI_LDAP_LOGIN_EMAIL_KEY=mail
- YAPI_LDAP_LOGIN_USERNAME_KEY=cn
- YAPI_PLUGINS=[]
restart: unless-stopped

Gitlab

参考:https://forum.gitlab.cn/t/topic/620

注:Gitlab 默认以用户名和邮箱为唯一标准,所以最好将 Gitlab 中存储账户邮箱改成和 LDAP 一一对应的,这样依赖就可以直接继承下原 Gitlab 下的账户。

极狐 GitLab 集成 LDAP 背景介绍

使用场景

  • 将现有的 LDAP 用户同步到 GitLab 中
    • 支持快速将 LDAP 服务器管理的用户同步到 GitLab 中
    • 支持通过规则限定特定分类的 LDAP 用户同步到 GitLab 中
  • 使用 LDAP 服务管理极狐 GitLab 用户
    • 支持使用 LDAP 服务创建和管理 GitLab 用户

LDAP 安全性检查

  • 集成 LDAP 前需要对你的系统做以下检查,以确保使用的安全性
    • 你的 LDAP 用户无法修改服务器中的 mailemailuserPrincipalName 字段
    • 你的 LDAP 用户不能分享同一个 email 地址,否则这些用户可以访问同一个 GitLab 用户的资源

其他说明

  • 社区用户可以使用 LDAP 集成的基础功能,部分高级功能仅开放给订阅用户

配置 LDAP 集成

参考极狐官网安装 GitLab

修改配置并重新配置 GitLab 实例

  • 修改主配置文件 /etc/gitlab/gitlab.rb 添加以下内容:
  • 注:每个版本的配置各不同,所以按需修改
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
gitlab_rails['ldap_enabled'] = true
gitlab_rails['prevent_ldap_sign_in'] = false
gitlab_rails['ldap_servers'] = YAML.load <<-'EOS' # remember to close this block with 'EOS' below
'main' => {
'label' => 'LDAP',
'host' => 'ldap.mydomain.com',
'port' => 389,
'uid' => '<sAMAccountName> 或 <uid>',
'encryption' => 'simple_tls',
'verify_certificates' => false,
'bind_dn' => '管理员dn',
'password' => '管理员pass',
# 可选
'tls_options' => {
'ca_file' => '',
'ssl_version' => '',
'ciphers' => '',
'cert' => '',
'key' => ''
},
'timeout' => 10,
# 此处配置 ldap 源服务器是否是 ad,如果此处设置 true,那么 allow_username_or_email_login 最好设置为 false
'active_directory' => true,
'allow_username_or_email_login' => true,
'block_auto_created_users' => false,
# 此处设置 user find dn
'base' => 'ou=people,dc=extension,dc=net',
'user_filter' => '',
# 字段映射
'attributes' => {
'username' => ['uid', 'userid', 'sAMAccountName'],
'email' => ['mail', 'email', 'userPrincipalName'],
'name' => 'cn',
'first_name' => 'givenName',
'last_name' => 'sn'
},
'lowercase_usernames' => false,
EOS
  • 并修改以下字段
1
2
3
4
'label' => 'LDAP' # 该字段为 LDAP 服务名称,该名称会展示在 GitLab Portal 的登陆界面
'host' => 'ldap.mydomain.com' # 该字段为 LDAP 服务器的地址
'bind_dn' => '_the_full_dn_of_the_user_you_will_bind_with' # 该字段为 LDAP 管理员用户的 DN
'password' => '_the_password_of_the_bind_user' # 该字段为 LDAP 管理员用户的 password
1
2
3
# 例如,你可以通过配置 user_filter 将部分 ldap 用户同步到 GitLab 中
'(employeeType=developer)'
'(&(objectclass=user)(|(samaccountname=momo)(samaccountname=toto)))'
  • 执行 sudo gitlab-ctl reconfigure 使得上述配置生效

使用 Rake Task 检查同步情况

  • 配置完成后,可使用 LDAP 相关的 Rake Task 检查用户同步情况 gitlab-rake gitlab:ldap:check[100] 该命令检查前 100 个 LDAP 用户

其他 LDAP 配置

LDAP 用户同步周期

  • GitLab 默认每日执行 LDAP 用户同步,如果你需要修改 LDAP 的同步周期,可以通过修改 /etc/gitlab/gitlab.rb 中配置实现
1
gitlab_rails['ldap_sync_worker_cron'] = "0 */12 * * *"

如未生效可执行 gitlab-ctl restart 重启下