第 5 章 Catalog Entry Schema 参考
5.1. 关于 Directory Server Schema
本章概述了目录架构的一些基本概念，并列出说明该架构的文件。它描述了对象类、属性和对象标识符(OID)，并简要讨论扩展服务器架构和模式检查。
5.1.1. 模式定义
目录架构是一组用于定义如何存储数据的规则。目录信息存储了离散条目，每个条目由一组属性及其值组成。条目中描述的身份种类在条目的对象类中定义。对象类指定条目通过对象类定义的一组属性描述的对象类型。
基本上，架构文件是可以创建（ 对象类）的多种条目列表，以及这些条目可以描述的方式（ 属性）。架构 定义 对象类和属性是什么。该架构也定义属性值包含的格式（属性 的语法），以及是否只能是该属性的单一实例。
额外的架构文件可以添加到目录服务器配置中并加载到服务器中，因此该架构可以自定义，并可根据需要进行扩展。
如需有关对象类、属性以及目录服务器使用架构的详细信息，请参阅 《部署指南》。
如果 schema 定义包含太数或太多字符，目录服务器无法启动。在 LDAP 标准允许使用零个或多个空格的地方使用一个空格；例如，NAME 关键字和属性类型名称之间的位置。
5.1.1.1. 对象类
在 LDAP 中，对象类定义可用于定义条目的属性集合。LDAP 标准为许多常见条目类型提供对象类，如人员 （人员和 inetOrgPerson）、组(groupOfUniqueNames)、位置（本地性）、机构和部门（组织和 组织单元）以及设备（设备）。
在架构文件中，对象类由 objectclasses 行标识，然后由其 OID、名称、描述、其直接高级对象类（对象类用于与对象类共享其属性）以及与这个对象类共享其属性的列表，以及所需(MUST)和允许的(MAY)属性的列表。
这在 例 5.1 “人员对象类架构条目” 中显示。
例 5.1. 人员对象类架构条目
objectClasses: ( 2.5.6.6 NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' )
5.1.1.1.1. 所需的属性和允许的属性
每个对象类定义多个所需属性和允许的属性。所需属性必须在使用指定对象类的条目中出现，但允许的属性可用，但条目有效并不是必需的。
与 例 5.1 “人员对象类架构条目” 中一样，个人 对象类需要 cn、sn 和 objectClass 属性，并允许 描述、seeAlso、电话 和 userPassword 属性。
所有条目都需要 objectClass 属性，它会列出分配给该条目的对象类。
5.1.1.1.2. 对象类继承
一个条目可以有多个对象类。例如，一个人的条目由个人对象类定义，但同一人也可能由 inetOrgPerson 和 organizationalPerson 对象类中的属性描述。
此外，对象类也可以是分级。对象类也可以继承另一个类的属性，也可以继承其各自的必要属性和允许的属性。第二个对象类 是第一个 的卓越对象类。
服务器的对象类结构决定了特定条目所需的属性列表。例如，用户的条目必须具有 inetOrgPerson 对象类。在这种情况下，该条目还必须包括用于 inetOrgPerson、OrganizationPerson、Opery Person 的卓越对象类，即 :
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson
当 inetOrgPerson 对象类分配给一个条目时，条目会自动从高级对象类继承所需的和允许的属性。
5.1.1.2. 属性
目录条目由属性及其值组成。这些对称为 属性断言或 AVAs。目录中的任何信息都与描述性属性相关联。例如，cn 属性用于存储个人的全名，如 cn: John Smith。
其他属性可以提供有关 John Smith 的额外信息：
givenname: John surname: Smith mail: jsmith@example.com
在 schema 文件中，属性由 attributetypes 行标识，后面跟着 OID、名称、描述、语法（允许的格式）以及是否是单属性还是多值的定义位置。
这在 例 5.2 “description Attribute Schema Entry” 中显示。
例 5.2. description Attribute Schema Entry
attributetypes: ( 2.5.4.13 NAME 'description' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 2256' )
某些属性可以缩写。这些 abbreviations 列为属性定义的一部分：
attributetypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) ...5.1.1.2.1. 目录服务器属性语法
属性的语法定义了属性允许的值的格式；与其他架构元素一样，利用架构文件条目中的语法为属性定义语法。在 Directory Server 控制台中，语法由其友好名称引用。
Directory 服务器使用属性的语法，对条目执行排序和模式匹配。
有关 LDAP 属性语法的详情，请参考 RFC 4517。
表 5.1. 支持的 LDAP 属性语法
| 名称 | OID | 定义 |
|---|---|---|
| 二进制 | 1.3.6.1.4.1.1466.115.121.1.5 | 已弃用。改为使用 10 月字符串。 |
| 位字符串 | 1.3.6.1.4.1.1466.115.121.1.6 |
对于作为位数的值，如 |
| 布尔值 | 1.3.6.1.4.1.1466.115.121.1.7 | 对于只有两个允许值的属性，TRUE 或 FALSE。 |
| 国家/地区字符串 | 1.3.6.1.4.1.1466.115.121.1.11 | 如果值只限制为两个可打印的字符串字符；例如，美国。 |
| DN | 1.3.6.1.4.1.1466.115.121.1.12 | 对于可分辨名称(DN)的值。 |
| 交付方法 | 1.3.6.1.4.1.1466.115.121.1.14 | 对于包含提供信息或联系实体的首选方法的值。不同值用美元符号($)分隔。例如： [literal,subs="+quotes,verbatim"] …. phone $ physical …. |
| 目录 String | 1.3.6.1.4.1.1466.115.121.1.15 | 对于有效的 UTF-8 字符串的值。这些值不一定不区分大小写。Directory 字符串和相关语法都提供区分大小写和不区分大小写的匹配规则。 |
| 增强的指南 | 1.3.6.1.4.1.1466.115.121.1.21 | 对于包含基于属性和过滤器的复杂搜索参数的值。 |
| Facsimile | 1.3.6.1.4.1.1466.115.121.1.22 | 表示包含 fax 数字的值。 |
| faven | 1.3.6.1.4.1.1466.115.121.1.23 | 对于包含传输的 faxes 的镜像的值。 |
| 常规时间 | 1.3.6.1.4.1.1466.115.121.1.24 | 对于以可打印字符串编码的值。必须指定时区。强烈建议使用 GMT 时间。 |
| 指南 | 1.3.6.1.4.1.1466.115.121.1.25 | 过时。对于包含基于属性和过滤器的复杂搜索参数的值。 |
| IA5 String | 1.3.6.1.4.1.1466.115.121.1.26 | 对于有效字符串的值。这些值不一定不区分大小写。对于 IA5 String 及相关语法，都提供区分大小写和不区分大小写的匹配规则。 |
| 整数 | 1.3.6.1.4.1.1466.115.121.1.27 | 代表整个数字。 |
| JPEG | 1.3.6.1.4.1.1466.115.121.1.28 | 包含镜像数据的值。 |
| 名称及可选 UID | 1.3.6.1.4.1.1466.115.121.1.34 | 对于包含 DN 和可选唯一 ID 的组合值的值。 |
| 数字字符串 | 1.3.6.1.4.1.1466.115.121.1.36 | 对于包含 numerals 和空格的字符串的值。 |
| OctetString | 1.3.6.1.4.1.1466.115.121.1.40 | 对于二进制值，替换二进制语法。 |
| 对象类描述 | 1.3.6.1.4.1.1466.115.121.1.37 | 包含对象类定义的值。 |
| OID | 1.3.6.1.4.1.1466.115.121.1.38 | 对于包含 OID 定义的值。 |
| 邮编地址 | 1.3.6.1.4.1.1466.115.121.1.41 |
对于以 [literal,subs="+quotes,verbatim"] ….1234 主要 St.$Raleigh, NC 12345$USA …. 每个 dstring 组件都被编码为 DirectoryString 值。反斜杠和美元符号（如果发生）会用引号进行引号，因此将不会为行分隔符而出错。许多服务器将邮编地址限制为最多三十 个字符的 6 行。 |
| 可打印的字符串 | 1.3.6.1.4.1.1466.115.121.1.44 | 对于包含可打印字符串的值。 |
| space-In 敏感字符串 | 2.16.840.1.113730.3.7.1 | 对于包含空格分隔字符串的值。 |
| TelephoneNumber | 1.3.6.1.4.1.1466.115.121.1.50 | 对于以电话号码格式的值。建议您在国际表单中使用电话号码。 |
| Teletex Terminal Identifier | 1.3.6.1.4.1.1466.115.121.1.51 | 对于包含国际电话号码的值。 |
| Telex Number | 1.3.6.1.4.1.1466.115.121.1.52 | 对于包含 telex 号、国家/地区代码的值，以及电话终端的回答代码。 |
| URI |
对于 URL 形式的值，由字符串（如 |
5.1.1.2.2. 单值和多值属性
默认情况下，大多数属性都是多值。这意味着条目可以多次包含同一属性，具有不同的值。例如：
dn: uid=jsmith,ou=marketing,ou=people,dc=example,dc=com ou: marketing ou: people
例如，cn、tel 和 objectclass 属性可以有多个值。是单值值的属性 - 也就是说，在架构中只能指定其中一个属性实例，因为只允许单个值。例如，uidNumber 只可以有一个可能的值，因此其 schema 条目具有术语 SINGLE-VALUE。如果属性是多值，则没有值表达式。
5.1.2. 默认目录服务器架构文件
Directory 服务器的模板架构定义存储在 /etc/dirsrv/schema 目录中。这些默认架构文件用于生成新的目录服务器实例的模式文件。每个服务器实例在 /etc/dirsrv/slapd-实例/schema 中都有自己的特定于实例的模式目录。实例目录中的架构文件仅由该实例使用。
要修改目录架构，请在实例特定架构目录中创建新属性和新对象类。由于默认模式用于创建新实例，并且每个实例都有自己的架构文件，每个实例的模式可能稍有不同，这与每个实例的使用匹配。
使用 Directory Server Console 或 LDAP 命令添加的自定义属性都存储在 99user.ldif 文件中；其他自定义模式文件可以添加到每个实例的 /etc/dirsrv/slapd-实例/schema 目录中。不要对 Red Hat Directory Server 提供的标准文件进行任何修改。
有关 Directory 服务器如何存储规划目录架构的信息和建议的更多信息，请参阅 《部署指南》。
表 5.2. 模式文件
| 架构文件 | 用途 |
|---|---|
| 00core.ldif | 从 X.500 和 LDAP 标准(RFCs)中推荐的内核模式。此架构供 Directory 服务器本身用于实例配置并启动服务器实例。 |
| 01core389.ldif | 从 X.500 和 LDAP 标准(RFCs)中推荐的内核模式。此架构供 Directory 服务器本身用于实例配置并启动服务器实例。 |
| 02common.ldif | RFC 2256、LDAPv3 和用于配置条目的目录服务器定义的标准相关模式。 |
| 05rfc2927.ldif | RFC 2927 的 schema，"LDAP 架构的MIME 目录配置文件"。 |
| 05rfc4523.ldif | X.509 证书的 schema 定义。 |
| 05rfc4524.ldif | Cosine LDAP/X.500 模式. |
| 06inetorgperson.ldif | RFC 2798、RFC 2079 以及 RFC 1274 的一部分，InetOrgPerson 架构元素。 |
| 10rfc2307.ldif | RFC 2307 的 schema，"使用 LDAP 作为网络信息服务的方法"。 |
| 20subscriber.ldif | Directory Server-Nortel 订阅者互操作性的通用架构元素。 |
| 25java-object.ldif | RFC 2713 的 schema，"在 LDAP 目录中代表 Java 对象的架构"。 |
| 28pilot.ldif | 试用 RFC 的 schema，特别是 RFC 1274，在新部署中不再使用。 |
| 30ns-common.ldif | 常见架构。 |
| 50ns-admin.ldif | 管理服务器使用的模式。 |
| 50ns-certificate.ldif | 红帽证书系统使用的模式。 |
| 50ns-directory.ldif | 传统目录服务器 4.x 服务器使用的模式。 |
| 50ns-mail.ldif | 邮件服务器的模式。 |
| 50ns-value.ldif | Directory 服务器中的值项的 schema。 |
| 50ns-web.ldif | Web 服务器的模式。 |
| 60autofs.ldif | 用于自动挂载配置的对象类；这是用于 NIS 服务器的几个架构文件之一。 |
| 60eduperson.ldif | 与教育相关的人员和组织条目的模式元素。 |
| 60mozilla.ldif | 与 Mozilla 相关的用户配置集的 schema 元素。 |
| 60nss-ldap.ldif | GSS-API 服务名称的模式元素。 |
| 60pam-plugin.ldif | 将目录服务与 PAM 模块集成的模式元素。 |
| 60pureftpd.ldif | 定义 FTP 用户帐户的 schema 元素。 |
| 60rfc2739.ldif | 日历和 vCard 属性的 schema 元素。 |
| 60rfc3712.ldif | 用于配置打印机的架构元素。 |
| 60sabayon.ldif | 定义 sabayon 用户条目的架构元素。 |
| 60sudo.ldif | 用于定义 sudo 用户和角色的架构元素。 |
| 60trust.ldif | 用于为 NSS 或 PAM 定义信任关系的 schema 元素。 |
| 99user.ldif | 通过 Directory 服务器控制台添加的自定义模式元素。 |
5.1.3. 对象标识符(OID)
所有 schema 元素分配有对象标识符(OID)，包括属性和对象类。OID 是整数序列，通常以点分隔的字符串编写。所有自定义属性和类都必须符合 X.500 和 LDAP 标准。
如果没有为 schema 元素指定 OID，目录服务器会自动使用 ObjectClass_name-oid 和 attribute_name-oid。但是，使用文本 OID 而不是数字 OID 可能会导致客户端、服务器互操作性和服务器行为出现问题，强烈建议您分配一个数字 OID。
OID 可以构建于.基本 OID 是一个根数字，用于组织的每个 schema 元素，然后可以从那里递增架构元素。例如，基本 OID 可以是 1。然后，公司将 1.1 用于属性，因此每个新属性的 OID 为 1.1.x。它使用 1.2 用于对象类，因此每个新对象类都具有 1.2.x 的 OID。
对于 Directory Server 定义的 schema 元素，基本 OID 如下：
-
Netscape 基础 OID 为
2.16.840.1.113730。 -
Directory 服务器基础 OID 为
2.16.840.1.113730.3。 -
所有 Netscape 定义的属性都具有基础 OID
2.16.840.1.113370.3.1。 -
所有 Netscape 定义的对象类都具有基础 OID
2.16.840.1.113730.3.2。
如需有关 OID 或请求前缀的更多信息，请访问互联网编号授权机构(IANA)网站，访问地址： http://www.iana.org/
5.1.4. 扩展架构
目录服务器架构包含数百个对象类和属性，可用于满足大多数目录要求。此架构可以使用新的对象类和属性来扩展，通过创建自定义架构文件来满足企业中目录服务的不断变化的要求。
在架构中添加新属性时，应创建新的对象类来包含它们。在现有对象类中添加新属性可能会破坏目录服务器与依赖标准 LDAP 模式的现有 LDAP 客户端的兼容性，并可能会在升级服务器时造成困难。
有关扩展服务器模式的更多信息，请参阅 《部署指南》。
5.1.5. 模式检查
架构检查 意味着，Directory 服务器会在使用 LDIF 导入的数据库创建时检查每个条目，以确保它符合 schema 文件中的模式定义。模式检查会验证三个内容：
- 条目中使用的对象类和属性在目录架构中定义。
- 对象类所需的属性包含在条目中。
- 条目中仅包含对象类允许的属性。
您应该运行启用了架构检查的目录服务器。有关启用架构检查的详情，请参考 管理指南。
5.1.6. 语法验证
语法验证 意味着 Directory 服务器检查属性值是否与该属性的所需语法匹配。例如，语法验证将确认新的 phoneNumber 属性实际上具有其价值的有效电话号码。
使用其基本配置时，语法验证（如架构检查）将检查任何目录修改，以确保属性值与所需语法匹配，并将拒绝违反语法的任何修改。此外，也可选择将语法验证配置为记录关于语法冲突的警告消息，并拒绝更改或允许修改过程成功。
除 DN 外，所有语法都会根据 RFC 4514 进行验证。默认情况下，DN 会根据 RFC 1779 或 RFC 2253 验证，其比 RFC 4514 严格。必须配置 DN 的严格验证。
这个功能检查 表 5.1 “支持的 LDAP 属性语法” 中列出的所有属性语法，但二进制语法（无法验证）和非标准语法除外，它们没有定义所需的格式。未验证 的语法如下：
- 传真（二进制）
- 10 月字符串（二进制）
- JPEG（二进制）
- 二进制（非标准）
- 在敏感字符串中空格（非标准）
- URI（非标准）
启用语法验证后，每当向条目中添加或修改属性时，会检查 新 属性值。（这不包括 复制 更改，因为语法将在供应商服务器上检查。） 还可以通过运行 syntax-validation.pl 脚本来检查语法冲突 的现有 属性值。
有关语法验证选项的详情，请参考 管理指南。
