Rancher
测试版本:2.7.x
参考文档:http://ranchermanager.docs.rancher.com/zh/pages-for-subheaders/configure-openldap


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

依次点击Security>>LDAP进入配置页面
点击 “Create Connection” 创建LDAP连接

1 | name:此连接的名称,可自定义 |
服务器信息填写完成后,点击 Verify connection 测试连接[

右上角弹出测试结果,如测试连接失败,检查配置信息是否有误
测试成功后,点击 next 进入LDAP 用户和组配置
- 情景一:所有用户都在 Users 根节点下
- 情景二:大部分用户在Users目录中,但还有其他目录存在用户
- 情景三:其他情况
点击 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 | grafana: |

在 grafana
层级下,添加 LDAP 认证参数
1 | grafana: |
参数说明:
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 | cluster.name=elasticsearch-cluster |
role_mapping.yml
1 | # 如下所示,superuser 是在我们的 Elasticsearch 中已经定义好的 role。赋予如下账户superuser角色 |
API
1 | POST /_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
(字符串列表)授予与角色映射规则匹配的用户的角色名称列表。必须指定
roles
或role_templates
中的一个。role_templates
(对象列表)胡子模板列表,将对其进行评估以确定应授予与角色映射规则匹配的用户的角色名称。这些对象的格式定义如下。必须指定
roles
或role_templates
中的一个。rules
(必需,对象)确定映射应匹配哪些用户的规则。规则是使用 JSON DSL 表达的逻辑条件。参阅 角色映射资源。
例子
以下示例将“user”角色分配给所有用户:
1 | POST /_security/role_mapping/mapping1 |
执行角色映射时,已
enabled
设置为的映射将被忽略。false
metadata字段是可选的。
成功的调用会返回一个 JSON 结构,显示映射是已创建还是已更新。
1 | { |
更新现有映射时,
created
设置为 false。
以下示例将“user”和“管理admin”角色分配给特定用户:
1 | POST /_security/role_mapping/mapping2 |
以下示例匹配针对特定领域进行身份验证的用户:
1 | POST /_security/role_mapping/mapping3 |
以下示例匹配用户名是esadmin
或用户在cn=admin,dc=example,dc=com
组中的任何用户:
1 | POST /_security/role_mapping/mapping4 |
当你的身份管理系统(例如 Active Directory 或 SAML 身份提供商)中的组名称与 Elasticsearch 中的角色名称没有一对一的对应关系时,上面的示例很有用。角色映射是将组名与角色名链接起来的方法。
但是,在极少数情况下,你的组名称可能与你的 Elasticsearch 角色名称完全匹配。当你的 SAML 身份提供者包含自己的“组映射”功能并且可以配置为在用户的 SAML 属性中发布 Elasticsearch 角色名称时,就会出现这种情况。
在这些情况下,可以使用将组名称视为角色名称的模板。
注意:仅当你打算为所有提供的组定义角色时才应执行此操作。将用户映射到大量不必要或未定义的角色是低效的,并且会对系统性能产生负面影响。如果你只需要映射组的一个子集,那么你应该使用显式映射来执行此操作。
1 | POST /_security/role_mapping/mapping5 |
mustache函数
tojson
用于将组名列表转换为有效的 JSON 数组。因为模板生成一个 JSON 数组,所以格式必须设置为
json
.
以下示例匹配特定 LDAP 子树中的用户:
1 | POST /_security/role_mapping/mapping6 |
以下示例匹配特定领域中特定 LDAP 子树中的用户:
1 | POST /_security/role_mapping/mapping7 |
规则可能更复杂,包括通配符匹配。例如,以下映射匹配满足所有这些条件的任何用户:
- 可分辨名称与模式匹配
*,ou=admin,dc=example,dc=com
,或者用户名是es-admin
,或者用户名是es-system
cn=people,dc=example,dc=com
群组 中的用户- 用户没有
terminated_date
1 | POST /_security/role_mapping/mapping8 |
模板化角色可用于自动将每个用户映射到他们自己的自定义角色。角色本身可以通过 Roles API或使用 自定义角色提供程序来定义。
在此示例中,每个使用“cloud-saml”领域进行身份验证的用户都将自动映射到两个角色 - 角色"saml_user"
和一个角色,其用户名前缀为_user_
. 例如,用户nwong
将被分配saml_user
和 _user_nwong
角色。
1 | POST /_security/role_mapping/mapping9 |
因为不可能在同一个角色映射中同时指定
roles
和role_templates
,所以我们可以通过使用没有替换的模板来应用“固定名称”角色。
实战
这里我们仅创建两种mapping,一种admin,一种basic_user
1 | # GET /_security/role_mapping/admins |
问题
ldap用户删除后仍可登录
Elasticsearch 与 LDAP 集成时,用户的身份验证是通过 LDAP 服务器进行的。如果你已经在 Elasticsearch 中配置了 LDAP 集成,并且已经删除了 LDAP 中的用户,则该用户将无法再登录 LDAP 服务器,但仍然可以登录 Elasticsearch。这是因为 Elasticsearch 缓存了先前身份验证的用户凭据,以便在将来的请求中使用,而不是每次都要向 LDAP 服务器发出身份验证请求。
配置会话缓存时间
在默认情况下,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 | # LDAP configuration |
Yapi
项目地址: https://github.com/fjc0k/docker-YApi
注:yapi默认以用户名和邮箱为唯一标准,所以最好将yapi库中存储账户邮箱改成和ldap一一对应的,这样依赖就可以直接继承下原yapi库下的账户
这里贴下将原有邮箱后缀改成指定邮箱后缀的mongo sql
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 | version: '3' |
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集成的基础功能,部分高级功能仅开放给订阅用户
配置LDAP集成
参考极狐官网安装GitLab
- 参考安装极狐部署GitLab
修改配置并重新配置GitLab实例
- 修改主配置文件
/etc/gitlab/gitlab.rb
添加以下内容: - 注:每个版本的配置各不同,所以按需修改
1 | gitlab_rails['ldap_enabled'] = true |
- 并修改以下字段
1 | 'label' => 'LDAP' # 该字段为LDAP服务名称,该名称会展示在GitLab Portal的登陆界面 |
- 其他配置项目参考LDAP基础配置 4
1 | # 例如,你可以通过配置user_filter将部分ldap用户同步到GitLab中 |
- 执行
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 * * *" |