Schema是LDAP的一个重要组成部分,类似于数据库的模式定义,LDAP的Schema定义了LDAP目录所应遵循的结构和规则,比如一个 objectclass会有哪些属性,这些属性又是什么结构等等,schema给LDAP服务器提供了LDAP目录中类别,属性等信息的识别方式,让这些可以被LDAP服务器识别。
在LDAP的schema中,有四个重要的元素:
1. Objectclass
objectclass定义了一个类别,这个类别会被不同的目录(在LDAP中就是一个Entry)用到,它说明了该目录应该有哪些属性,哪些属性是必须的,哪些又是可选的。一个objectclass的定义包括名称(NAME),说明(DESC),类型(STRUCTURAL或AUXILARY ,表示是结构型的还是辅助型的),必须属性(MUST),可选属性(MAY)等信息。
在BAP产品中,有下面几种类别
- # GalaxyTitle
- objectclass ( 2.16.840.1.153730.3.4.2
- NAME 'GalaxyTitle'
- DESC 'GalaxyTitle use to manage title'
- SUP top
- STRUCTURAL
- MUST ( uid )
- MAY (
- sortid )
- )
- # GalaxyPost
- objectclass ( 2.16.840.1.153730.3.4.32
- NAME 'GalaxyPost'
- DESC 'GalaxyPost use to manage post'
- SUP top
- STRUCTURAL
- MUST ( uid )
- MAY (
- sortid $ type )
- )
- # GalaxyDuty
- objectclass ( 2.16.840.1.153730.3.4.22
- NAME 'GalaxyDuty'
- DESC 'GalaxyDuty use to manage duty'
- SUP top
- STRUCTURAL
- MUST ( dutyuid )
- MAY (
- sortid )
- )
- # GalaxyGroup
- objectclass ( 2.16.840.1.153730.3.2.12
- NAME 'GalaxyGroup'
- DESC 'GalaxyGroup use to manage group'
- SUP top
- STRUCTURAL
- MUST ( uid )
- MAY (
- sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $
- email $ gfax $ others1 $ others2 $
- others3 $ uniqueMember $ searchConditionXml)
- )
- # GalaxyPeople
- objectclass ( 2.16.840.1.153730.3.2.22
- NAME 'GalaxyPeople'
- DESC 'GalaxyPeople use to manage people'
- SUP InetOrgPerson
- STRUCTURAL
- MAY (
- otherDepartmentNumber $ sortid $ ifactivated $ peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $ virtualaccount
- )
- )
- # GalaxyOrganization
- objectclass ( 2.16.840.1.153730.3.2.2
- NAME 'GalaxyOrganization'
- DESC 'GalaxyOrganization use to manage dep'
- SUP top
- STRUCTURAL
- MUST ( uid )
- MAY (
- sysid $ employeeids $ sortid $ depmanager $ telephone $
- email $ gfax $ others1 $ others2 $
- others3 $ depmanagerFilter $ title $ post)
- )
- # GalaxyContainer
- objectclass ( 2.16.840.1.153730.3.2.16
- NAME 'GalaxyContainer'
- DESC 'a container,can fill with people,org,group...'
- SUP top
- STRUCTURAL
- MUST ( cn )
- )
- # GalaxyLevel
- objectclass ( 2.16.840.1.153730.3.3.18
- NAME 'GalaxyLevel'
- DESC 'level inof'
- SUP top
- STRUCTURAL
- MUST ( cn $ number )
- )
- # GalaxyAttOfPeople
- objectclass ( 2.16.840.1.153730.3.3.19
- NAME 'GalaxyAttOfPeople'
- DESC 'att name and sn'
- SUP top
- STRUCTURAL
- MUST ( sn $ cn )
- )
# GalaxyTitle
objectclass ( 2.16.840.1.153730.3.4.2
NAME 'GalaxyTitle'
DESC 'GalaxyTitle use to manage title'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sortid )
)
# GalaxyPost
objectclass ( 2.16.840.1.153730.3.4.32
NAME 'GalaxyPost'
DESC 'GalaxyPost use to manage post'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sortid $ type )
)
# GalaxyDuty
objectclass ( 2.16.840.1.153730.3.4.22
NAME 'GalaxyDuty'
DESC 'GalaxyDuty use to manage duty'
SUP top
STRUCTURAL
MUST ( dutyuid )
MAY (
sortid )
)
# GalaxyGroup
objectclass ( 2.16.840.1.153730.3.2.12
NAME 'GalaxyGroup'
DESC 'GalaxyGroup use to manage group'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sysid $ employeeids $ sortid $ groupType $ searchCondition $ groupManager $ telephone $
email $ gfax $ others1 $ others2 $
others3 $ uniqueMember $ searchConditionXml)
)
# GalaxyPeople
objectclass ( 2.16.840.1.153730.3.2.22
NAME 'GalaxyPeople'
DESC 'GalaxyPeople use to manage people'
SUP InetOrgPerson
STRUCTURAL
MAY (
otherDepartmentNumber $ sortid $ ifactivated $ peopleLevel $ leadermember $ leaderFilter $ title $ post $ globalsortid $ virtualaccount
)
)
# GalaxyOrganization
objectclass ( 2.16.840.1.153730.3.2.2
NAME 'GalaxyOrganization'
DESC 'GalaxyOrganization use to manage dep'
SUP top
STRUCTURAL
MUST ( uid )
MAY (
sysid $ employeeids $ sortid $ depmanager $ telephone $
email $ gfax $ others1 $ others2 $
others3 $ depmanagerFilter $ title $ post)
)
# GalaxyContainer
objectclass ( 2.16.840.1.153730.3.2.16
NAME 'GalaxyContainer'
DESC 'a container,can fill with people,org,group...'
SUP top
STRUCTURAL
MUST ( cn )
)
# GalaxyLevel
objectclass ( 2.16.840.1.153730.3.3.18
NAME 'GalaxyLevel'
DESC 'level inof'
SUP top
STRUCTURAL
MUST ( cn $ number )
)
# GalaxyAttOfPeople
objectclass ( 2.16.840.1.153730.3.3.19
NAME 'GalaxyAttOfPeople'
DESC 'att name and sn'
SUP top
STRUCTURAL
MUST ( sn $ cn )
)
2. Attribute
attribute就是一个上面objectclass中可能包含的属性,对其的定义包括名称,数据类型,单值还是多值以及匹配规则等。后面用具体的例子来说明。
3. Syntax
syntax是LDAP中的“语法”,其实就是LDAP中会用到的数据类型和数据约束,这个语法是遵从X.500中数据约束的定义的。其定义需要有一个ID(遵从X.500)以及说明(DESP)
4. Matching Rules
是用来指定某属性的匹配规则,实际上就是定义一个特殊的Syntax的别名,让LDAP服务器可以识别,并对定义的属性进行匹配。
LDAP的schema的主要元素就是这些了,下面列举出了一些LDAP规定好的或是现在比较通用的schema,一般的LDAP服务器都应该可以识别这些定义。
这就是一个名为subschema的objectclass的定义:
(2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) )
首先是ID,这里是2.5.20.1,接着是NAME,AUXILIARY说明是辅助型,之后是可选属性的定义,subschema中没有定义必须属性,如果需要定义,应该和MAY一样,将属性放在MUST()中并用$隔开
再来看一个属性定义:
( 2.5.4.3 NAME 'cn' SUP name EQUALITY caseIgnoreMatch )
可以看到cn属性的父属性是name,它相等性匹配于caseIgnoreMatch(匹配原则为EQUALITY,还有如SUBSTR是字符串匹配,ORDERING是顺序匹配)
syntax定义一般都比较简单,如:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'String' )
这个定义说明,这一串数字1.3.6.1.4.1.1466.115.121.1.5就代表了LDAP中的字符串,这个数字串的定义和X.500相关,包括了它的存储方式,所占空间大小等。
最后看看Matching Rule的例子,前面提到了caseIgnoreMatch,就看他的吧
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
其实1.3.6.1.4.1.1466.115.121.1.15 就是LDAP数据类型Directory String的ID,说明前面的cn需要等于这个数据类型才有效。
还有很多常用schema的定义都在了RFC2252中,LDAP服务器都应该支持这些基本的schema。好了,现在基本对LDAP中的schema有个一个大致的说明,可能有不到位或不妥之处,还望大家指正。