网上有很多文章，都是在介绍了部署之后，就完事儿了，真正系统认真地把实际应用场景中的配置内容分享的，则是少之又少，有分享的，也都是含糊不清，让人难以学习，这里我特别将日常生产中常用的一些软件配置方式，一一过了一遍，并整理分享，愿阅读本篇文章的你能有所收获。

另外，我所分享出来的，可能只是我个人的一种思路方案，如果您有更加简便合理的方案，欢迎留言分享交流！

1，zabbix 配置 LDAP

zabbix 在配置起来是比较简单的，我们直接使用最外层的用户授权即可，亦即不用过分深入再对用户进行分组管理，因为 zabbix 自身还会有一层授权控制。

那么所有的配置如下图所示：

说明：

• 认证方式：选择 LDAP。
• LDAP 主机：可以填 IP，这里我写了配置 LDAP 时用的域名，注意记得将此域名写入到本机 hosts 解析。
• 端口：默认 389.
• 基于 DN：此处填写 ou=People,dc=eryajf,dc=net，表示用户基于 People 这一分组下维护。
• 搜索属性：uid。
• 绑定 DN：此处填写 cn=admin,dc=eryajf,dc=net，表示绑定到根域上去。
• 登陆：Admin，这个用户与 zabbix 管理账户重叠，但是要注意需要先在 LDAP 中创建此用户，并设置密码。
• 用户密码：将上一步创建用户的密码写在这里，点击测试，如果没毛病，将会通过测试。

2，Gitlab。

默认情况下，Gitlab 没有开启 ldap 的认证，这个功能需要通过配置文件来启用，所以在现有 Gitlab 中，往配置文件里边添加如下配置：

cat /etc/gitlab/gitlab.rb
external_url 'http://10.133.205.206'
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.163.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = 'Linuxlql@163.com'
gitlab_rails['smtp_password'] = "xxxxxxx"
gitlab_rails['smtp_domain'] = "smtp.163.com"
gitlab_rails['smtp_authentication'] = :plain
#gitlab_rails['smtp_authentication'] = "login"
#gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_enable_starttls_auto'] = false
gitlab_rails['gitlab_email_from'] = "Linuxlql@163.com"
user["git_user_email"] = "Linuxlql@163.com"
git_data_dir "/home/git"
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = {
'main' => {
  'label' => 'OpenLDAP', # 随便自定义
  'host' =>  '10.3.0.42',   # ldap的server地址
  'port' => 389,    # ldap端口
  'uid' => 'sn',    # 配置为cn或者sn都可以，但要注意用户名称将会以此处配置为依据
  'encryption' => 'plain',  # 加密
  'bind_dn' => 'cn=admin,dc=eryajf,dc=net', # 管理员账号
  'password' => 'eryajf@456',   # 管理员密码
  'active_directory' => false,
  'base' => 'ou=People,dc=eryajf,dc=net',   # 核心配置，表示从哪一层读取用户信息
  'allow_username_or_email_login' => true,  # 是否启用邮件作为用户名登陆
  'verify_certificates' => true,    #
  }
}

配置添加之后，依旧像安装时候那样，重载一下配置：

gitlab-ctl reconfigure

重载过程如果不报错，可以使用如下命令验证功能是否可用：

$ gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
    DN: uid=test01,ou=people,dc=eryajf,dc=net    cn: ceshi
    DN: uid=test02,ou=people,dc=eryajf,dc=net    cn: test02
    DN: uid=test03,ou=people,dc=eryajf,dc=net    cn: test03
    DN: uid=admin,ou=people,dc=eryajf,dc=net     cn: Admin
    DN: uid=liql,ou=people,dc=eryajf,dc=net  cn: liql
Checking LDAP ... Finished

可以看到会刷出来当前所有的用户，此时配置就已经完成了，再次访问 Gitlab，发现已经多了一个 ldap 登陆的选项。

使用 ldap 用户名密码进行登陆即可，此时登陆进去是没有任何项目的权限，如果需要某权限，可以对用户进行组或者单项目的授权。

3，Jenkins

以上两种应用，都是基于最外层的用户进行管理的，并没有再细化分组，这种配置方式，是有其原因的，因为两者都是在默认登陆之后，用户无任何权限，需要通过管理员重新授权，从而获得相应的权限。

而 Jenkins 就不太一样了，Jenkins 启用了 ldap 登陆之后，默认是登录用户就是管理员权限，尽管我们还可以通过更细化权限划分的插件来实现管控，但是这仍然让人觉得不那么优雅。

因此，在 Jenkins 这里，打算采用基于应用分组的方式进行配置。

配置之前，首先创建用户以及应用组，那么授权的时候，直接针对应用组授权即可。

创建普通用户：

• 在 People 之下点击创建新条目
• 模板选择默认
• ObjectClasses选择inetOrgPerson，然后点击继续
• 从上而下填写，RDN 选择 User Name(uid)
• 然后开始正式的人员信息填写
  • cn：zhangs
  • sn：zhangs
  • displayName：张三
  • 电子邮件：zhangs@qq.com
  • ou：People
  • 密码：123456
  • User Name：zhangs

然后点击创建，提交之后，一个普通用户就创建成功了。一般情况下，应用直接通过这一层来管理用户即可。

但是有些情况下，再另外拉出来一个分组，从软件的角度来分组，会更好一些。

创建一个应用组：

• 在 Group 之下创建新条目
• 模板选择默认
• ObjectClasses选择groupOfNames，然后点击继续
• 从上而下填写，RDN 选择 cn(cn)
• 然后开始填写组信息
  • cn：jenkins
  • member：点击后边的搜索框，选择将要包含的用户

然后点击创建，提交之后，就创建了一个 jenkins 组，配置 ldap 的时候，可以基于这个组来进行管理。

创建完成后的架构模式如下：

可以看到，此时在 Jenkins 这个组里边，加入了三个用户，实际生产当中，原有用户应该已经存在，此时可以新增群组，然后将需要访问 Jenkins 应用的用户，加入进来，而没有加入这个组的用户，将无法访问。

下边进入正式配置，新版本的 Jenkins 已经默认集成了 ldap，因此不需要额外安装插件，直接点击系统管理—>Configure Global Security，按照下边的内容，进行配置即可。

配置完成，下边会有一个 test，此时可以用其中一个账号密码进行测试，看到如下输出，则说明配置成功：

保存之后，就可以通过 ldap 当中，Jenkins 组内的用户名密码进行登陆了，这里只是解决了用户能够登陆 Jenkins 的问题，具体 Jenkins 中详细的用户权限分配，可以参考这篇文章进行配置 (opens new window)。

4，jumpserver

直接进入到 jumpserver 的系统设置里边，如下内容，进行配置，几项工具配置下来，基本上都熟悉了各个配置的概念了。

配置完毕，可以点击测试连接，会看到导入几个用户的提示，然后点击提交配置，提交之后，可以点击一键导入，将对应用户导入进来：

然后点击导入，即可将 ldap 中的用户导入到 jumpserver 中了。

5，harbor

常规来讲，harbor 的认证，也像 zabbix 那样，只取用 ldap 最外层即可，也就是 People 下的所有人，都可以登录 harbor，然后再针对不同的项目，对不同的用户进行授权即可。

这种配置比较简单，如下图所示：

配置完成之后，可以点击一下测试看看效果，如果成功，则可以保存启用。

当然，如果人员数量很大，也可以走按组分配的方向，可以基于如上配置进行：

**重要提示：必填参数，如缺失将无法实现分组效果 **

截图中遗漏了配置 LDAP 过滤器参数

(memberOf=cn=ops,cn=group,dc=eryajf,dc=net)

如果有多个分组需要加入，比如 ops 和 Jenkins 分组的用户都需要登录 harbor，则可参照如下添加两个过滤器即可

(|(memberOf=cn=ops,cn=group,dc=eryajf,dc=net)(memberOf=cn=jenkins,cn=group,dc=eryajf,dc=net))

同样，先测试是否可用，成功之后点击保存即可。保存之后，可以用其中一个用户进行登陆验证，可以在用户设置里边看到来自于 LDAP。

6，NGINX

1，基于全员的认证

NGINX 基于 ldap 的认证，一旦出手，谁与争锋，日常业务当中，有太多页面内容，通过 NGINX 代理，有时需要添加认证以提高安全，使用 NGINX 的密码策略，又极不方便，容易出现一个账号多人使用的情况，而今接入到 ldap，所有权限回归到 ldap 中，简直不要太优雅。

NGINX 基于 ldap 的认证需要 nginx-auth-ldap模块儿，可以在原有已经在用的 NGINX 中，添加进去，或者直接全新的 NGINX 进行配置。

cd /opt
git clone https://github.com/nginxinc/nginx-ldap-auth

然后编译安装 NGINX：

tar xf nginx-1.14.0.tar.gz
yum -y install zlib zlib-devel openssl openssl-devel pcre pcre-devel libxslt-devel
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_v2_module --with-http_realip_module --add-module=/opt/nginx-auth-ldap
make && make install

然后进入正式配置：

$cat /usr/local/nginx/conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    log_format json escape=json '{ "remote_addr": "$remote_addr",'
                           '"@timestamp":"$time_iso8601",'
                           '"request_uri": "$request_uri",'
                           '"verb": "$request_method",'
                           '"httpversion": "$server_protocol",'
                           '"response": "$status", '
                           '"body_bytes_sent": "$body_bytes_sent", '
                           '"referrer": "$http_referer", '
                           '"user_agent": "$http_user_agent", '
                           '"server_name": "$host",'
                           '"request_time": "$request_time",'
                           '"upstream_response_time": "$upstream_response_time",'
                           '"realpath_root": "$realpath_root",'
                           '"cookie": "$http_cookie",'
                           '"request_body": "$request_body",'
                           '"nginx_version": "$nginx_version",'
                           '"scheme": "$scheme"}';
    access_log /data/log/tmp.log json;
    error_log /data/log/error.log;
    ldap_server test {
    url ldap://10.3.0.42:389/DC=eryajf,DC=net?cn?sub?(objectClass=person);
    binddn "cn=admin,dc=eryajf,dc=net";
    binddn_passwd 123465;
        require valid_user;
    }
    ldap_server test_ldap1 {
        url "ldap://10.3.0.42:389/DC=eryajf,DC=net?uid?sub?(&(objectClass=organizationalPerson))";
        binddn "cn=admin,dc=eryajf,dc=net";
        binddn_passwd "123456";
        require valid_user;
        #group_attribute People;
        #group_attribute_is_dn on;
    #require group "cn=jenkins,ou=Group,dc=eryajf,dc=net";
    }
    server {
        listen       80;
        server_name  localhost;
        location / {
            auth_ldap "Forbidden";
            auth_ldap_servers test_ldap1;
            root   /usr/share/nginx/html;
        }
    }
}

说明：最开始我使用的 test的配置，对于许多地方并没有过于在意，但是在请求的时候，总是进入死循环，输入用户名密码之后又跳入到了让输入用户名密码的界面，然后错误日志里边打印了一条：[error] 11539#0: *388 http_auth_ldap: Could not find user DN,，然后在官方 issue 中，看到一个不错的解答：https://github.com/kvspb/nginx-auth-ldap/issues/133

最后根据回答里边说明的，结合自己配置的实际情况，使用了 test_ldap1这个 server，整体验证通过。

然后就可以利用这种思路，给很多 web 界面套上这种管理方案了。

2，基于特定组的认证

以上配置用于验证用户层级的权限，也就是配置之后，所有的用户都可以访问对应的域名，这样似乎仍然有一丢丢不理想，对于一些重要的域名而言，显得权限放开的过宽。于是我想到通过组来进行权限的控制，这个配置的成型，同样也是经历千辛万苦各方验证而来，网上真正找到可用的，并不多，因此能看到这个地方的朋友，绝对是有缘了。

这个配置如下：

ldap_server test_ldap1 {
    url "ldap://10.3.0.42:389/DC=eryajf,DC=net?uid?sub?(&(objectClass=organizationalPerson))";
    binddn "cn=admin,dc=eryajf,dc=net";
    binddn_passwd "eryajf@456";
    group_attribute member;
    group_attribute_is_dn on;
    require group "cn=jenkins,ou=Group,dc=eryajf,dc=net";
}
server {
    listen       80;
    server_name  localhost;
    location / {
        auth_ldap "Forbidden";
        auth_ldap_servers test_ldap1;
        root   /usr/share/nginx/html;
    }
}

这样就把权限控制在 jenkins这个组内了，其他人访问的时候，是被拒绝的。

如果你当前使用的是 openresty，那么可以参考这篇文章进行模块的添加 (opens new window)。

7，Apollo

Apollo 在安装配置完毕后，用户管理这块儿也可以接入到 ldap 当中，官方文档中给出了好几种方案，这里选取基于组进行过滤认证的方案。

需要在 /data/apollo/apollo-portal/config目录下添加如下配置文件：

spring:
  ldap:
    base: "dc=eryajf,dc=net"
    username: "cn=admin,dc=eryajf,dc=net" # 配置管理员账号，用于搜索、匹配用户
    password: "eryajf@456"
    searchFilter: "(uid={0})"  # 用户过滤器，登录的时候用这个过滤器来搜索用户
    urls:
    - "ldap://openldap.eryajf.net:389"

ldap:
  mapping: # 配置 ldap 属性
    objectClass: "inetOrgPerson" # ldap 用户 objectClass 配置
    loginId: "uid" # ldap 用户惟一 id，用来作为登录的 id
    rdnKey: "uid" # ldap rdn key
    userDisplayName: "cn" # ldap 用户名，用来作为显示名
    email: "mail" # ldap 邮箱属性
  group: # 启用group search，启用后只有特定group的用户可以登录apollo
    objectClass: "posixGroup"  # 配置groupClassName
    groupBase: "ou=groups" # group search base
    groupSearch: "(&(cn=apollo))" # group filter
    groupMembership: "member" # group memberShip eg. member or memberUid

然后在启动文件 /data/apollo/apollo-portal/scripts/startup.sh 中添加如下声明：

export JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=github,ldap"

接着重启服务即可。