Rancher

测试版本:2.7.x

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

Nexus3

配置步骤

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

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

点击 “Create Connection” 创建LDAP连接

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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 fitter,值为:(&(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

先决条件

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

参考

ES LDAP官方:https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-role-mapping.html

ES LDAP 集成:https://www.jianshu.com/p/5b10475c605a

ELK部署至K8s并启用AD认证:https://lzzeng.github.io/log-analysis/k8s-elk-auth-kibana-via-ad/

Elasticsearch LDAP 用户鉴权:https://juejin.cn/post/7132739314902892574

修改配置文件

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 组中的所有用户赋予superuserElasticsearch 中的角色。该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

    (对象列表)胡子模板列表,将对其进行评估以确定应授予与角色映射规则匹配的用户的角色名称。这些对象的格式定义如下。必须指定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用户无法修改服务器中的mail,email,userPrincipalName字段
    • 你的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重启下