Directory Service（目录服务）：基于X..500的树状层次化数据结构。
LDAP（轻量级目录访问协议）：公有的用来访问目录数据库的接口协议。
DIT（目录信息树）：目录服务数据架构。
DC（目录组件）：LDAP中定义的层次化结构组件，一般与DNS域名相同。
OU（组织单元）：LDAP中定义的层次化结构单元。
AD（活动目录）：微软公司商用的目录服务，适合作为域用户的应用权限管理。
2. 系统设计 2.1. 系统设计原则
目录服务统一用户管理系统，着眼于如何将分散的用户数据整合到一致的目录服务平台下，并提供统一的操作管理界面给用户进行后续的管理与维护功能。
2.2. 系统分析与设计方法
目录服务器信息树（DIT）是对目录的逻辑描述。参照了标准X.500国际标准，采用层次的命名方法。同时考虑到日常维护的灵活性，划分组织单元时主要从以下方面考虑：
¨ 人员或组织是否经常变化：在组织机构内人员经常从一个部门调动到另外一个部门。
¨ 是否易于使用：是否可方便地找到系统中的用户、个人计算机、服务器。
¨ 是否容易管理和支持：是否可以对用户、个人计算机、服务器和验证进行方便的管理。
¨ 是否具有可扩展性：是否能适应将来组织的变化和增长。
¨ 对于每个组织单元可以实行分级管理。
¨ 组织单元名以及相对应的单位、部门、科室的汉语名称缩写或其特定的名称缩写为准。
LDAP目录树的最顶部就是根，也就是所谓的“基准DN”。基准DN通常使用下面列出的三种格式之一：
¨ 以X.500格式表示的基准DN：o="yourOU ", c=CN
在这中方法中，o=yourOU. 表示组织名，在这里就是公司名的同义词。c=CN 表示国家名称。以前，一般都用这种方式来表示基准DN。但是事物总是在不断变化的，随着Internet/Intranet的发展，在基准DN中使用国家代码很容易让人产生混淆。
¨ 用公司的Internet/Intranet地址表示的基准DN：o=yourOU.com
这种格式很直观，用公司的域名作为基准DN。是现在使用较多的格式，也是公司原有Notes系统采用的地址格式。
¨ 用DNS域名的不同部分组成的基准DN：dc=yourOU, dc=com
这种格式是以DNS域名为基础的，这种格式把域名：yourOU.com分成两部分 dc=yourOU, dc=com。在理论上，这种格式可能会更灵活一点，对于后续的扩展能力也更强一些。Microsoft的活动目录强制要求采用这种格式。
考虑到维护的灵活性，如公司组织结构变动，调整等。本次建设建议采用DNS域名的不同部分组成的基准DN。
2.3. 数据设计
本目录服务项目涉及到的数据领域包括，员工查询(Employe yellow page)、AD中相关域和用户信息及组织结构信息等。根据以上信息，我们把存储在目录中的数据分成以下三类数据元素：一，跟员工相关；二，跟部门相关；三，跟资源相关，比如打印机等。按照X.500中Group的组织方法，我们设置目录树组织单元分别为OU=people, OU=groups,OU=resource。
存放在目录中的数据在许多方面需要考虑，比如目录attribute的syntax(语法)，attribute的值长度及是否允许Multi-valued的attribute。当目录使用attribute语法执行比较操作，比如等于操作，针对String类型跟Numerical类型会有不同的结果。
下表为跟员工相关的数据元素描述
Element
Description
Syntax
Size/#Values
Owner
Consumers
Stability
姓
Case Ignore String
*/1
Admin
Employe yellow page
Static
名
Case Exact String
*/1
Admin
Authentication
Employe yellow page
Static
创建时间
Case Ignore String
*/1
Admin
Employe yellow page
Static
常用名称
用户全名
Encrypted
*/1
Admin
Authentication
Dynamic
用户工号
Case Ignore String
*/1
Admin
Employe yellow page
Static
密码
Case Ignore String
*/1
User
Employe yellow page
Static
电子邮件
Case Ignore String
*/1
Admin
Employe yellow page
Static
电话
Case Ignore String
*/1
Admin
Employe yellow page
Static
传真
Case Ignore String
*/1
Admin
Employe yellow page
Static
部门
Case Ignore String
*/1
Admin
Employe yellow page
Static
班组
Case Ignore String
*/1
Admin
Employe yellow page
Static
下表为跟部门相关的数据元素描述
Element
Description
Syntax
Size/#Values
Owner
Consumers
Stability
部门名称
Case Ignore String
*/1
Admin
Employe yellow page
Static
包含员工列表
Case Ignore String
*/1
Admin
Employe yellow page
Static
2.4. 数据元素与Schema映射
根据上节数据设计结果，我们把员工相关信息映射到目录的Attribute。
下表为员工相关的数据元素到LDAP Schema Attribute映射表。
Data Element
Schema Attribute
Custom
Multi-valued
姓
sn
Predefined
NO
名
givename
Predefined
NO
创建时间
createtimestamp
Predefined
NO
常用名称
displayname
Predefined
NO
用户工号
cn
Predefined
NO
密码
userpassword
Predefined
NO
电子邮件
Predefined
NO
电话
telephoneNumber
Predefined
NO
传真
facsimileTelephoneNumber
Predefined
NO
部门
department
Predefined
YES
班组
team
Custom
NO
下表为部门相关的数据元素到LDAP Schema Attribute映射表。
Data Element
Schema Attribute
Custom
Multi-valued
部门名称
cn
Predefined
NO
员工列表
uniquemember
Predefined
YES
根据上表，我们尽量使用标准的LDAP Attribute来满足数据元素到Schema Attribute的映射，然而X.500中标准的inetOrgPerson的attribute不能满足员工的数据设计需要，通过扩展inetOrgPerson这个obectClass，定义YourPerson来实现以上Attribute。对于部门的数据设计，X.500中标准的groupofuniquenames这个obectClass能满足需求。
在Blog中贴图一系列图片实在是难题,详细文档请参见:
http://webscope.cosoft.org.cn/upload/API%20Publish%20Demostrate.html
:[email protected]
本文地址：http://com.8s8s.com/it/it15034.htm