3) Keystone通过只读LDAP验证

　　根据上文中提及，企业组织对已有LDAP服务与keystone整合的需求来看，现有的LDAP后端不满足于企业的需求。因此，本文提出通过自定义验证后端的方式，来满足这类用户的实际需求。

　　自定义LDAP后端的功能需求

　　如前面所述，已有LDAP服务的企业组织，对Keystone的需求可以简化如下：

　　•Keystone所有的系统服务账号及特定管理员帐号存储于OpenStack的本地MySQL数据库中，不依赖于现有LDAP服务。

　　•Keystone中所需要的用户角色及租户信息存储于OpenStack的本地MySQL数据库中，不依赖于现有LDAP。

　　•Keystone中所有常规的用户帐号验证通过现有的LDAP服务进行验证。

　　上述简化的需求既可以保证OpenStack系统各组件服务的独立性，也可以通过现有的LDAP服务进行常规用户的验证，实现企业内部统一的身份验证机制。

　　自定义LDAP后端的简单实现

　　依据上述简化的需求，keystone现有的SQL后端和LDAP后端均可满足部分需求。因此，我们只需基于现有的SQL和LDAP后端定制一个混合的验证后端即可。

　　具体实现的思路如下：

　　•以现有的SQL验证后端为基础，列出OpenStack各系统服务帐号及特定管理员帐号的列表，在该服务帐号列表中的服务帐号通过SQL验证后端进行本地验证。

　　•在服务帐号列表以外的其他帐号，以现有LDAP后端为基础，仅利用现有LDAP后端中的密码验证部分，实现仅通过LDAP服务进行帐号的密码验证功能。

　　自定义LDAP后端的验证流程如下：

　　1) 用户登陆时，自定义后端会通过现有的SQL后端查询账号是否存在。如果不存在直接返回，如果存在继续2);

　　2) 如果账户存在，查询该账号是否属于系统服务账号。如果是系统账号继续a);

　　a) 如果账号属于系统账号，则通过SQL后端进行密码验证。密码验证失败，则返回;密码验证成功，则继续4);

　　b) 如果不是系统账号，而是普通用户账号，继续3);

　　3) 如果账号存在，并且是普通用户账号，则通过LDAP后端进行密码验证。如果密码验证失败，则返回;如果密码验证成功，则继续4)

　　4) 继续通过SQL后端进行其他验证步骤。

　　注意：建议保留一个系统管理员帐号，用以进行必要的初始化配置。本文中保留的系统管理员帐号为“admin”。