1. 背景：

在企业创办初期，少于50台服务器的情况下基本不会遇到帐号管理的问题。

但是随着时间的推移，服务器数量增加及经常变更服务器密码，就会频繁导致有些服务器忘记密码，登录不上去的情况。

这个在大多数公司都是普遍存在的，给SA增加了不少烦恼。甚至有些企业内部员工一直在使用root帐号，开发人员及运维人员混用同一帐号进行管理。这会导致误操作的后果不堪设想，因此急需一套帐号密码管理制度和管理工具。

最初可能仅仅是为了能满足最简单的功能，但是随着时间的推移，问题与需求越来越多，系统不断的演变，最终将会形成一个什么样的系统呢？

下面跟大家分享下，我经历的统一身份认证系统（基于OpenLDAP）的整个发展及演变过程。

2.1 最初需求的产生：

需求的产生往往都来自于故障

公司发生了一次故障，一台边缘系统服务不稳定，造成主系统的负载非常高，这个时候业务运维人员需要登录上服务器进行解决问题，可是发生了最不愿意看到的一幕：

“密！码！不！对！我！登！录！不！上！去！”

“我试试看，是不是之前改密码的时候漏掉了这台服务器……完了，我的也登录不上去….”

本来一个简简单单的故障，被延时了将近一个小时才登上服务器进行解决，结果被骂得狗血淋头，站都站不稳。

这个时候运维部门决定要搭建一套统一身份认证系统，避免类似问题再次发生。经过公司内多个部门的讨论，得出最初的需求：

a）为了员工能高效工作，需要只使用一个帐号密码就能登录所有服务器

场景A

A同事入职，申请登录服务器，这个时候需要管理员为他分配登录服务器的账号密码，并且以A的名字为命名账号，密码为初始密码。

b）同时更改一次帐号密码，所有服务器快速生效

场景B

A同事拿到分配的账号密码之后，项目比较着急，希望能马上登录服务器查看相应的应用情况。

出于安全考虑，需要修改账号密码，但是不希望有其他人知道，甚至是管理员。

c）所有人都能sudo到root用户，进行系统管理和业务调整（创业初期讲究短平快，使用root是相当常见的，不过这个不合理的需求在后面会解决）

2.2 实现方案讲解

根据讨论得出的需求及运维部门的考虑，我们考虑过两种方案：

第一、使用配置管理工具，将系统的Passwd、shadows等文件进行统一管理，达到账号密码的统一；

第二、使用工具OpenLDAP/Kerberos来实现账号密码信息的统一管理。

考虑到第一种方案风险较大，而且用户更改密码生效周期过长等因素，所以放弃了。

而至于在OpenLDAP与Kerberos之间的选择则完全是巧合，因为测试OpenLDAP过程非常顺利，而且容易上手（ 请原谅我选择了容易上手的工具，大家请勿拍砖 ^_^）

最终确定实施方案：以 OpenLDAP 为核心工具，使用 sudo + pam 来辅助。下面阐述一下方案的概况：

1. OpenLDAP实现的功能：

• 账号信息管理：包括用户ID、用户账号、用户密码、OU账号（OpenLDAP以OU命名，区分角色组或者部门）、OU_ID等；

• 账号认证功能：用户通过OpenLDAP客户端，将账号密码传输到服务器端进行验证；

2. Pam实现的功能：

服务器登录验证模块：pam模块增加验证数据源的扩展，不仅在本地 passwd & shadow 文件中进行验证，还增加了到OpenLDAP源的验证过程。

3. Sudo实现的功能：

• 提权功能：用户通过个人账号登录服务器之后，可以使用sudo来进行提权；

• 权限定义：权限定义分为默认权限和临时权限，默认权限是在OpenLDAP中定义，默认所有用户的权限都是

  sudo su - root

4. OpenLDAP的使用建议

前期如果考虑到数据库的权限比较特殊，安全级别比较高，可以让OpenLDAP不承载所有服务器类型的认证。

以WEB+CACHE+DB的业务类型为例，我们将WEB\CACHE业务的管理纳入到OpenLDAP中，而DB业务维持本地的账号密码+sudo权限管理。

3.1 演变的开始：权限的精细化管理

a）需要实现每个人都有相对应的默认权限

场景C

A同事拿到分配的账号密码之后，向SA说明自己的需求，不希望拿到太大的权限，避免误操作承担过多的风险，只需要读的权限，不需要服务器和应用的操作权限。

b）需要在特定环境中获得一些特殊权限

场景D

A同事拿到只读权限登录上服务器之后，希望能拿到测试环境中自己负责模块的应用操作权限，但是不希望拿到BETA和生产环境的操作权限。同时以上的需求仍然需要满足。

c）所有拥有root的权限，非常的危险，必须对权限进行精细化管理

场景E

生产环境发生了一个故障，还是A同事在配合运维排查故障过程中，发现有这个服务配置的内存数量太小，导致服务运行效率非常低，这个时候A同事立马对配置进行更改，效果非常明显，服务恢复了！

但是这并没有结束，接下来是服务器ping得通了，但是服务宕机，连ssh登录都被拒绝了。原因是配置的内存超过了服务器的实际内存大小，服务器严重使用了内存及SWAP空间，最终SWAP空间被使用快速消耗完，并最终导致了服务器短时间内的宕机假象。

场景F

B同事，在根目录下，以为在自己的目录下，使用root的用户执行了一个shell命令： rm -rf ./*

3.2 解决方案：

思考：

在公司内部会有多个部门，而每个部门对权限的需求又有很多的不一致：

1. 系统管理员要求必要时候可以获取Root权限；

2. 业务管理员要求可以进行服务的操作，完成正常上线，但是又不能给他系统管理员权限；

3. 网络管理员只要求能在每个机房用个人账号进行登录即可，不需要其他权限；

4. 开发人员需要使用个人账号登录服务器，只能看业务日志，不能看系统日志和任何的系统、业务方面的操作；

5. 数据库管理员要求只能在数据库服务器上获取数据库管理员的权限，而且数据库服务器只能由DBA才能登陆，其他人一律没有权限；

经过讨论得出：需要对所有的员工根据权限的不同进行分组，并对组进行授权，不同的组拥有不同的权限。

企业中的角色账号分类，具体如下：

1. 管理员角色：root（SA角色使用）

2. 业务角色：oracle（DBA角色使用）、service（OPS角色使用）

3. 观察角色：read_only（研发角色使用）

4. 个人角色：LDAP账号（个人账号）

在OpenLdap里面存在三种对象：

1. 用户（个人账户：people）
2. 用户组（部门组：OU）
3. sudoers组及权限

对象之间的关联关系如下：

1. 用户账号通过在属性里面定义的gidNumber与用户组建立关联；

2. sudoers组通过属性中定义的cn与用户组建立关联；

就这样用户账号就与sudoers组产生了关联，而在sudoers组里包含了sudo权限。所以用户的权限也就确定了：

• 超级管理员：所有服务器

sudo su - root

• 业务管理员：应用类服务器

sudo su - service；

• 网络管理员：所有服务器

none

• 开发人员： 应用类服务器

sudo su - read_only

我们实际情况是如何使用的呢？

个人用户通过LDAP个人账号登录跳板机，然后再登录至目标服务器，最终在目标服务器上根据OpenLDAP内定义的权限，进行用户角色的切换（例如 sudo su - root ) ，这样就可以得到相应的许可权限。

4.1 演变的继续：分布式管理

是否支持多IDC分布式部署？

场景G

随着业务的发展，公司需要进行异地灾备，从一个IDC扩展成为多个IDC。

运维部门必须考虑到有多个IDC该如何处理，必须满足多IDC的分布式架构，才能满足数据同步及快速生效的需求，同时减轻管理上的成本；