Chapter 4 - LDAP Schema

Chapter 1 介绍了架构及其重要性。该模式定义了管理 LDAP 目录可以执行的大部分操作的规则。当您更改游戏规则时，游戏可能会发生重大变化。架构的好处是与目录交互的用户通常不需要知道它，当然他们也不需要了解它是如何工作的。

The schema holds a central importance, which is hidden from users
The schema determines the type of data a directory holds

但是模式定义的不仅仅是交互规则；它定义了可以在目录中创建的条目类型。它定义目录可以存储哪些信息。所以修改schema可以大大增加LDAP目录的价值和灵活性。

Modifying the schema can extend the functionality of a directory

您修改模式以允许新类型的对象或创建新的属性类型。创建新型条目的影响可以大大增加目录的功能。您还可以添加属性匹配规则，并通过这样做来更改 LDAP 目录解析搜索操作的方式。我在本章末尾讨论了一些有趣的模式修改示例。

The schema components are highly interdependent

该模式由几个组件组成。图 4-1 表示这些模式元素中的每一个在模式上下文中是如何相关的。您可以使用它来可视化这些元素中的每一个，因为它被解释了。每个元素之间都有相当多的相互依赖性；事实上，每个模式元素可能依赖于其他几个模式元素。对象类和属性等复杂元素是从语法和匹配规则等较简单的元素构建而来的。图 4-1 显示了元素之间的这种依赖关系。

Figure 4-1. Conceptual diagram of schema

Object classes and attributes are the top level of the schema

对象类定义目录中允许的条目类型。对象类定义由内容规则、结构规则、名称形式和附加操作信息组成。对象类定义中的内容规则详细说明对象类包含的属性。结构规则定义了每个对象类如何参与命名空间，换言之，对象类的条目可以驻留在何处。名称形式定义了哪些属性可用于命名对象类的条目。属性定义与这些对象类中的每一个相关联的信息类型，因此在条目中。属性类型是属性的定义。属性类型由语法、匹配规则和有关属性的其他操作信息定义。语法决定了数据值的表示方式。匹配规则确定如何在 LDAP 操作中比较这些数据值。

Syntax is the building block of matching rules and attribute types

语法定义属性值中允许的数据类型和形式。语法的一个例子是布尔值。对于符合布尔语法的值，它必须是 FALSE 或 TRUE。其他语法允许数据以各种形式在目录中表示。匹配规则也使用语法并包含在属性类型定义中。

Schema checking maintains the integrity of the directory

Chapter 1 引入了模式检查的概念。在每次添加、修改或修改 RDN 操作时，必须检查属性值以查看它们是否满足对象类和属性类型的模式要求。如果这些检查失败，则操作失败。模式检查过程主要与确保目录的数据结构一致有关。这个过程类似于裁判员或官员的工作，他们确保比赛按照规则手册进行。

Several documents define the recommended LDAP schema

LDAP 目录开头的默认架构由多个文档定义。 RFC 2252 描述了 LDAP 模式的框架，换句话说，支持内部目录功能并允许您在模式中定义特定组件的模式部分。该框架包括一组语法、匹配规则和属性类型。

RFC 2252 还描述了在 LDAP 操作期间应用于表示属性值中的数据的编码规则。包括编码方法的描述可确保 LDAP 将跨实现进行互操作。 RFC 2256 描述了用户模式，换句话说，客户端定期与之交互的模式部分。此 RFC 中只有两个要求是每个 LDAP 服务器都必须实现的。但 RFC 包含许多关于对象类和属性的建议，几乎所有供应商都实施了这些建议。

X.500 schema definitions are valid for LDAP

LDAP 模式使用为 X.500 目录开发的相同模式定义，因为 X.500 是 LDAP 的前身。例如，前面提到的 RFC 大量借鉴了 X.501、X.520 和 X.521 标准中建立的定义，这些定义由国际标准组织 ITU 记录。这种与 X.500 目录的紧密联系提供了一个方便的、经过历史测试的定义池以供构建，同时还允许供应商实施同时支持 LDAP 和 X.500 的目录。

---

X.500 如何影响 LDAP 模式？

X.500 是一组定义目录结构和服务的标准，而 LDAP 是用于与目录结构和服务交互的协议。 LDAP 最初旨在作为 X.500 目录的网关服务，因此客户端不需要实施 X.500 所需的大量目录访问协议 (DAP)。因此，LDAP 从不关注目录结构或服务；假定 X.500 标准和模型。但是随着 LDAP 的发展，供应商已经开始在不支持 X.500 的情况下实施 LDAP。这种趋势引发了关于 LDAP 是否应该在其定义中包括目录结构和服务模型的争论。如果您检查 LDAP 模式，您会看到频繁引用这种与 X.500 标准的关系。

The LDAP schema is flexible

缺少必需的默认架构意味着 Mycompany 在实现其目录时具有很大的灵活性。供应商也可以利用这种灵活性来为他们的目的创建功能，并且各个组织可以在设计他们的目录时挑选和选择模式修改。可以在实施后对模式进行扩展以扩展目录的功能。

LDAP v3 publicizes its schema to clients

LDAP v3 要求在子模式条目中发布模式，可以通过查询任何目录条目的 subschemaSubentry 属性值找到该条目。此条目的值是包含已发布模式的子模式条目的 DN。通过发布模式，客户端可以了解服务器支持的功能。这还可以通过使模式更易于修改以及利用目录支持的任何其他维护（例如复制）来简化模式维护。

Object Classes

An object class defines the types of entries in a directory

对象类定义 LDAP 目录中可能的条目。 LDAP 目录中的每个条目都有一个名为对象类的属性，对象类属性值对应于模式中的对象类定义。对象类别定义了哪些属性是必需的，哪些属性可选地可用于目录条目。它们还为用户提供了一种方便的方式来查询具有特定对象类属性的所有条目。例如，我可能想找到所有带有 objectclass=user 的条目，这样我就可以识别 Microsoft Active Directory 中的所有用户帐户。

Three categories of object classes create a template for building object classes

对象类分为三类：抽象类、辅助类和结构类。目录中的每一项都至少有一个结构类和一个抽象类，还可能有辅助类。 LDAP 的一些供应商实现不区分这些类别的对象类，但这并不意味着这些类别不被底层模式使用。任何特定的对象类都可以建立在另一个对象类定义的基础上，或者选择另一个对象类定义的有吸引力的部分；对象类类别启用此功能，即使它们未被供应商正式承认。对象类可以包含或继承现有定义，从而形成对象类之间的关系。这些关系意味着一个对象类有一整套对象类依赖于它，因此形成了层次结构。对象类的每个类别的目的，以及每个类别如何帮助您构建新的对象类，将在稍后讨论。

Elements of an Object Class

对象类定义包含几个关键字段，有助于定义对象类的条目以及该条目遵循的规则。以下字段是对象类定义的一部分：

• OID— The unique object identifier for this object class.
• Name— The name used to refer to the object class.
• Description— Brief description of what the object class represents.
• Inactive status— Indicated byOBSOLETE, which means the object class
  is inactive.
• Superior class— Lists the object class(es) on which this object class
  is based. Some schema formats label this field SUPwhile others call itSUBCLASS OF.
• Category of object class— Specified with the presence
  ofabstract,auxiliary, orstructural. By default, structural is
  assumed. The categories indicate to the schema-checking process how
  to create an entry of that object class, and what attributes are
  required or allowed.
• Mandatory attributes— Usually noted by aMUST field, which lists all
  the attributes that must have values for an entry of this object
  class to exist.
• Optional attributes— Usually noted by aMAY field, which lists all the
  attributes that are allowed on an entry of this object class.

Although the following object class fields are not defined in RFC 2252, many LDAP directories also support them:

• Naming attribute— Designates which attribute or attributes are used
  for naming (RDN) of entries of this object class. You can designate
  more than one attribute to form multivalued RDNs.
• Superior rules— Designate which object classes can contain entries of
  this object class

为了说明，这是子模式对象类定义的示例：

subschema OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { dITStructureRules | nameForms |
ditContentRules | objectClasses |
attributeTypes | matchingRules |matchingRuleUse }
ID 2.5.20.1}

Most products store the schema in a text file

大多数目录产品使用文本文件来存储架构定义。可以修改此文本文件以包含新定义或更改现有定义。许多产品需要重新启动 LDAP 服务器才能识别更改。子模式对象类定义使用 ASN.1 模式格式。定义遵循依赖于供应商的特殊格式。附录 B 检查了常见的模式格式。

Some products allow schema modifications via LDAP operations

一些目录将模式对象类和属性表示为目录条目，允许 LDAP 客户端通过 LDAP 操作搜索和修改模式定义。例如，personobject 类可能作为一个条目存在于 cn=person,ou=Schema,dc=mycompany,dc=com。在这个虚构的示例中，强制属性列在一个名为 must 的特殊属性中，可选属性列在一个名为 may 的特殊属性中。具有适当访问控制的 LDAP 客户端可以修改定义。虽然没有遵循这个虚构示例的细节，但 Microsoft 的 Active Directory 产品是允许用户通过 LDAP 操作添加或修改模式的产品示例。

Creating the Entry You Want

Creating the entry you want may require using multiple object classes

对象类定义允许您创建具有所需属性、内容规则和名称形式的条目。假设您想在 Mycompany 的目录中创建一个具有特定配置文件的条目。但是在现有的对象类别中，没有一个类别符合您想要的配置文件。你有两个选择。您可以从现有的对象类中进行选择，然后创建一个包含多个对象类的条目。或者你设计一个新的对象类。

You may have to build a new object class to get the entry you want

让我们进一步假设现有对象类的组合不适合您想要的配置文件，因为缺少属性或来自多个类的内容规则的组合限制太多。但是现有的对象类确实具有您需要的一些元素。您必须创建一个新的对象类，如果您可以在现有对象类的基础上进行构建会更容易。以下两节探讨您的选择。

Option 1: Use Inheritance and Object Class Relationships

Object class inheritance allows content and structure rules to be shared

您的新对象类可以从另一个对象类继承名称形式、内容规则和结构规则。当新对象类建立在现有对象类之上时，新对象类被称为原始对象类的子类，并且它继承了现有对象类的特征。稍后我们将了解继承的含义。原始类称为新对象类的上级类或超类。这种关系包含在上级字段中新对象类的定义中:

A hierarchical relationship of object classes is created when you use inheritance

对象类别之间的这种关系类似于科学家在生物分类中观察到的关系。生命形式类别之间存在等级制度，就像对象类别之间存在等级制度一样。如果生命形式被归类为人类，它也被归类为动物、哺乳动物和灵长类动物。人类与所有其他动物、哺乳动物和灵长类动物都有一些共同特征，但也有其他独特的特征。图 4-2 显示了对象类之间层次关系的具体示例。 ASN.1 模式格式用于表示对象类定义:

Figure 4-2. Building object classes using inheritance

 Inheritance allows entries of one object class to take the traits of another object class

如果我称你为人，我也不需要称你为哺乳动物；每个人都假设你是哺乳动物。以类似的方式，如果您创建一个条目，其中的对象类是另一个对象类的子类，则不需要指明所有上级类。该目录假定那些其他类并自动将它们包含在条目中。当您创建新子类的条目时，新条目的对象类属性值将同时具有新对象类名称和 SUP 字段中记录的任何对象类的名称。新条目需要遵循模式中为所有这些对象类定义的规则和要求。

Inheritance results in simpler schema definitions

请注意，新子类并未明确包含其任何超类的架构定义。它不需要。创建条目时，要求、规则和定义都会被继承。该目录负责处理这些细节。将继承构建到条目创建中会导致优雅高效的对象类定义，以及创建条目的简化过程。图 4-3 显示了对象类的元素如何用于创建子类的条目。在条目上，斜体属性是可选的，粗体属性必须由客户端请求提供，而以常规字体显示的单个属性由目录本身自动提供。

Figure 4-3. How elements of inherited object classes are used to create an entry

An example of creating an entry using an inherited object class

继承如何工作的例子将说明这个概念。使用图 4-2 中所示的定义，我使用以下参数向 Mycompany 的目录发送一个添加操作：

请注意，自动添加了三个额外的对象类值。如果我在添加操作参数中省略了 snattribute，操作就会失败。即使我正在创建 inetOrgPerson 的条目，我也必须满足 inetOrgPerson 的每个超类的所有要求，并且这是对象类 person 的要求。我可能已经在图 4-2 所示的四个对象类定义中的任何一个中添加了任何可选属性。 SoinetOrgPerson 为我提供了四个对象类，尽管我只需要指定一个。

You use abstract classes to build other object classes

抽象类构成了其他对象类的构建块。您通过继承使用抽象类作为模板来构建其他对象类。有一个特殊的抽象类称为 top，它是所有对象类的最终超类。要构建一个不继承任何东西的对象类，您可以构建一个作为top 的直接子类的对象类。抽象类是最不常用的，它通常用于支持内部 LDAP 操作，而不是为条目构建数据结构。

Structural classes are used in every directory entry

每个目录条目必须包含一个结构类。结构类总是使用继承，它必须是另一个对象类的子类。反之，只有结构类才能使用继承；抽象类和辅助类不能使用继承。结构类可以是另一个对象类的超类。

Option 2: Use an Auxiliary Class

您可以使用辅助类，而不是使用继承在 Mycompany 的目录中创建您需要的条目。这
包含您需要的一些元素的现有对象类加上新定义的辅助类的组合
将导致您需要的条目。要创建您的条目，您需要显式添加现有对象类和
辅助类。

You use auxiliary classes to mix and match

辅助类增加了条目的其他对象类，而没有与继承相关的成本。辅助类从不涉及继承，因为辅助类永远不是结构类或抽象类的超类。相反，辅助类显式包含在条目中，而不是通过继承隐式包含。您可以使用辅助类将特定功能添加到标准对象类，而无需修改原始对象类定义。可以将相同的辅助类添加到具有不同对象类的条目。这是辅助类最显着的优势。换句话说，辅助类不是继承链的一部分，您可以将它与不同类的条目一起使用。图 4-4 显示了在创建条目时辅助类的元素如何与其他类组合。斜体显示的属性是可选的，粗体显示的属性必须由客户端请求提供。

Figure 4-4. How elements of an auxiliary object class are used to create an entry

Auxiliary classes are outside of class inheritance chains

许多 LDAP 目录只允许一个对象类继承自一个类，因此对于任何特定的对象类，只允许一个超类。此约束导致对象类的依赖链，该对象类继承链中所有超类的特征。您可能需要某些特征（通常是属性），但不需要其他特征。这种依赖链是辅助类很重要的原因；辅助类不参与继承链。最大化这种好处的辅助类没有强制属性，只包含可选属性，从而真正允许类扩展功能。您使用辅助类的功能来扩充彼此之间没有（也不应该）具有层次关系的对象类。

例如，Mycompany 可能希望为每个组附加一个全局唯一标识符 (guid)
(objectclass=groupOfUnique Names) 和目录中的用户 (objectclass=inetOrgPerson) 条目。指南是
定义为属性。辅助对象类 guidClass 定义为带有 guid 属性作为可选属性。
然后可以将 guidClass 对象类添加到每个组和用户条目中。我们会通过修改来做到这一点
添加 objectclass=guidClass 的请求。最后，可以将 guid 值添加到所有条目。这些值可能是
通过添加辅助类的相同修改请求添加。

考虑替代方案，假设一个目录只支持单一继承。使用类继承的替代方法需要您定义两个不同的对象类，它们分别是 groupOfUniqueNames 和 inetOrgPerson 的子类。将这些子类中的每一个都称为 guidgroupOfUniqueNames 和 guidinetOrgPerson。这些中的每一个实际上都具有相同的目的——添加相同的单个可选属性——但是您必须提供两个定义来规避单一继承问题。

Attributes

属性类型在 RFC 2252 中所谓的 AttributeType-Description 和 RFC 2251 中的 AttributeType 中进行了描述。

---

那么哪种策略更好：继承还是辅助类？

根据我的描述，您可能认为辅助类是设计新对象类的更有效方法。但是从想要创建条目的用户的角度考虑事情。它们必须显式地包含两个对象类。如果他们改用继承，则只需要包含一个对象类。使用辅助选项，如果用户忘记其中一个对象类，就会出现问题。最佳策略实际上取决于对象类的用户。当然，如果您有一个支持 LDAP 的接口隐藏了这些细节，那么这可能无关紧要。最终，这不是非此即彼的选择。您会发现这两个选项都很有用。事实上，您可能已经注意到图 4-4 中所示的代码同时使用了继承和辅助类来创建条目。您可能没有注意到这一事实，因为继承的对象类是顶级类（没有强制或可选属性）。棘手，是吧？无论您采用哪种方法，请清楚您想要什么并了解任何潜在的责任。

An attribute is defined by an attribute type, which is composed primarily of syntax and matching rules

一个属性类型包含几个关键字段。这些字段有助于定义属性以及该属性遵循的规则。关键字段定义属性的语法和匹配规则。语法定义属性值中允许的数据类型和形式。匹配规则定义目录如何在 LDAP 操作期间确定断言值是否与属性值匹配。如前所述，匹配规则也使用句法。属性类型还指定是否可以接受多个属性值。默认情况下，一个属性是多值的，这意味着一个属性可以在每个条目上有多个值。

Elements of an Attribute Type

The following fields are part of the AttributeTypeDescription:

• OID— Unique object identifier for this attribute type.

• Name— Usually specified with theNAME label, which is the name used to
  refer to the attribute type.

• Description— Usually indicated with theDESC label, which is a
  brief description of what the attribute type represents.

• Inactive status— Usually specified with the presence of theOBSOLETE
  label, which means the attribute type is inactive.

• Superior class— Lists the attribute type on which this attribute type
  is based.

• Equality matching rule— Matching rule used to determine whether an
  asserted value matches an attribute value.

• Order matching rule— Matching rule used to determine whether an
  asserted value is ordered before or after an attribute value.

• Substring matching rule— Matching rule used to determine whether an
  asserted string value with a wildcard character matches an attribute
  value.

• Syntax— The kind and form of the data allowed in the attribute value.

• Number of allowed values— Whether only a single value or multiple
  values are allowed. By default, multiple values are assumed. The
  presence of SINGLE-VALUE indicates only a single value is allowed.

• Collective— By default, not collective is assumed.

• Modifiable— Whether the attribute value can be modified by
  user-initiated LDAP operations. By default, the attribute value is
  user modifiable.

• Usage— 用途——使用该属性的操作类型。默认情况下，假定为 userApplications。 userApplications、directoryOperation、distributedOperation 和 dSAOperation 都是有效值；然而，许多供应商的实现丢弃了这些值并仅用两个值替换它们：user 或 application 和 operational。未标记为 userApplications 的属性在搜索操作时默认不会返回，因为它们被认为是只有内部目录需要支持内部操作的信息

为了说明，这里有一个 createTimestamp 属性定义的例子:

( 2.5.18.1 NAME 'createTimestamp' EQUALITY
generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION USAGE
directoryOperation )

该定义以 BNF 模式格式给出，这与本章前面的示例对象类所使用的格式不同。有关模式格式的更多详细信息，请参阅附录 B。

Attributes can have more than one name

任何特定的属性类型都可以有多个名称。这些名称是彼此的同义词。例如，属性传真电话号码可能有传真作为同义名称。或者 cnm 可能将 commonName 作为同义词。同义名称包含在属性类型定义的 NAME 字段中。属性类型定义的 NAME 字段中的第一个名称称为规范属性名称。在共享通用架构的目录中，用户通常可以互换使用这些同义词，但这不一定适用于具有不同架构的目录。

同义名称的处理方式不规范，存在问题

通常 LDAP 目录更喜欢以规范形式返回属性名称，替换在一个要求。例如，我可能要求传真，但得到的是传真号码。属性名称同义词不是由 LDAP 标准管理，任何特定供应商或组织如何实施它们是不受管制的。什么时候我的公司需要整合多个LDAP目录，其中一个目录允许或偏好的属性名可能是不同于另一个目录。这种差异会导致严重的集成问题。希望这种疏忽该标准将在未来解决。

属性子类型

Subtyping is not defined in the LDAP standard, yet it is mentioned as a feature

现有标准（在 RFC 2256，第 5.50 节中）提到了子类型化的可能性，但没有解释它。子类型在 X.500 中很常见；并且由于 LDAP 最初被认为是 X.500 的扩展，因此暗含了该定义。既然 LDAP 目录是在没有 X.500 支持的情况下实现的，标准中的这种遗漏会带来问题。

An attribute subtype builds on an existing attribute definition

正如您所料，子类型的概念与子类的概念类似。子类型用于属性，子类用于对象类。您可以将现有属性类型扩展为子类型。属性子类型继承了其超类型的语法和匹配规则。例如，cnattribute 类型派生自 name 属性类型。cn 因此是 name 的子类型。 name 将是 cn 的超类型。 cn 属性描述不包含任何语法或匹配规则，因为它从名称属性定义中继承了这些元素。图 4-5 显示了这种关系。

Figure 4-5. Conceptual example of attribute subtypes

子类型改变了搜索操作的运作方式

子类型扩展了目录的功能。请求 name 属性的搜索将返回 name 值以及来自 name 的所有子类型的值。例如，搜索具有名称属性中存在的任何值的所有条目（换句话说，(name=*)）将返回具有值 inname 或 cn（以及名称的许多其他子类型）的所有条目:

子类型通常只出现在支持 X.500 的 LDAP 产品中

如前所述，子类型在 LDAP 中只是一种可能，而不是必需的。很少有 LDAP 实现包含此功能，并且这些实现通常也包含 X.500 功能。子类型可以是一个强大的补充，但它们会改变许多基本假设，因此 Mycompany 在使用它们时会非常谨慎。

Attribute Options

An Attribute-Description associates special attribute options with an attribute type

AttributeDescription 在 RFC 2251 中定义为属性类型定义的超集。这不是属性类型，而是稍微大一点的定义。 AttributeDescription 封装了属性类型定义，允许指定特殊的属性选项。这些属性选项在很大程度上未定义其用途。从历史上看，它们已用于更改与客户端通信的属性值的格式。

Figure 4-6 显示 AttributeDescription 和属性选项如何与目录中的条目以及可能使用该属性选项的客户端相关。在图中，客户端希望使用 mungeoption 返回条目 Y 的属性 A。属性 A 的模式定义包括 mungeoption，因此允许此请求。该目录查找属性 A 的值，然后根据为 munge 选项定义的语法重新格式化该值。目录向客户端报告通过这种mungereformatting看到的属性值。

图 4-6 属性选项如何启用目录功能

The binaryoption changes the format of the attribute value communicated to the client

例如，RFC 2251 给出了二进制选项的示例，您可以在其中强制服务器将与客户端通信的属性值的语法格式更改为二进制格式，而不是典型的基于字符串的语法。这并不一定意味着服务器必须以二进制格式存储属性值，只是它必须以二进制格式将值传递给客户端。

Options do not have to change the format

您还可以使用属性选项来指示属性值中的语言。此方法不会更改值的格式，而是指示该值以特定语言存储。有关通过属性选项支持语言的详细信息，请参阅下一节语言支持。

Clients specify attribute options by appending them to the attribute type

用户通过在相关搜索或比较操作参数中的属性类型末尾附加分号和选项名称来指定他们想要的属性选项。例如，具有 cn 属性的二进制选项将指定为 cn;binary。您可以在比较操作中使用此方法，在该操作中您想要比较二进制形式的数据值，但属性值具有字符串语法。您可以一次指定多个选项。不识别请求选项的服务器应将请求视为无法识别的属性类型，操作将失败。二进制选项的唯一常见用途是用于数字证书，例如 userCertificate:binary。这里它用于纠正 LDAP 早期关于如何表示数字证书的无效假设。如果没有二进制选项，您永远不应该搜索数字证书。

Language Support

LDAP supports multiple languages in data format, but further support is needed

LDAP 支持基于 Unicode 的国际语言支持的可能性。 LDAP v3 专门使用 Unicode Transformation Format-8 (UTF-8)，这是一种可用于表示几乎所有书面语言的字符集。因为 LDAP 使用 Unicode，所以您不需要特别指出属性值采用的语言。使用多值属性，可以同时支持多种语言。但是，在多语言目录中可能需要支持特定语言的特殊语法和匹配规则，因此特定语言的用户可以使用该语言的规则搜索和接收结果。

Attribute-based language code suffixes are used to extend support

解决这个问题的方法在 RFC 2596 中有所标准化。为此，RFC 建议通过属性描述的属性选项部分专门指定与属性类型定义相关联的语言代码。 RFC 2251 中提到的属性选项功能旨在作为一种允许扩展 LDAP 目录框架的方法。

The language code desired is added to the option field of the attribute type in the schema

在模式方面，每个属性类型定义都可以使用所需的语言代码进行扩展。 RFC 1766 指定要使用的语言代码后缀。因此，例如，Mycompany 可能会选择使用西班牙语扩展 description 属性类型。 Mycompany 将修改模式中的描述 AttributeDescription，将 lang-es 添加到定义的选项部分。然后用户可以在搜索请求期间指定此选项。在这个例子中，描述； lang-es 将被指定为完整的属性类型名称，表示使用西班牙语的描述属性类型。

Entries with the extended attribute option can have a value both for the option format and for the default format

目录中具有定义了语言选项的属性的条目可以同时具有语言选项和基本属性类型的值。例如，如果 description 属性类型如前所述用西班牙语扩展，则以下条目将有效:

objectClass=person
cn=Brian Arkills
sn=Arkills
description=He is very crazy.
description;lang-es=Está muy loco

每个所需的语言选项都必须单独设置，因为服务器不会自动将值从默认格式转换为语言选项格式。

Searches on attribute options work like they do for attribute subtypes

在搜索行为方面，您可以将每个语言选项视为属性类型的子类型。正如您可以预期对属性超类型的搜索将返回所有属性子类型的匹配项一样，对属性类型的搜索将返回该类型的匹配项以及该类型的所有语言选项。对于属性子类型，反之则不然；搜索属性类型的特定语言选项不会返回没有语言选项的属性类型的值。您可以在 RFC 中找到说明此行为的具体示例。尽管有这种搜索行为，语言选项扩展并不是定义新属性类型的子类型；他们是选项。

Matching rules that support language and cultural rules are needed

RFC 2596 并非在所有情况下都提供完整的解决方案。如前所述，完整功能需要支持特定于语言的文化规则的匹配规则。需要匹配规则来定义许多通常被视为理所当然的语法问题。例子包括：

• The order of characters in the language’s alphabet
• Issues of language type, such as what is a number and what is an
  alphabetic character
• The cultural formats for common data types like time, money, and date

我们很快就会看到匹配规则。如果这是一项关键要求，Mycompany将希望仔细审查潜在产品中的语言支持。

Operational Attributes

Operational attributes support internal directory operations

目录使用操作属性来支持内部目录操作，它们是未标记为 userApplications 用法的属性。 LDAP v3 在 rootDSE 条目和 subschema 条目中需要这些操作属性中的几个。其他操作属性对客户端可能很有价值，因为它们包含的信息可以揭示 LDAP 服务器支持的内容、可能使用的规则，甚至是至关重要的信息，例如条目的最后修改时间。

Operational attributes are noteworthy enough to list

掌握操作属性的唯一方法是仔细阅读标准和供应商文档。表4-1和表4-2中，按照RFC 2252中注明的类型区分列出了标准中的操作属性，OID、语法、匹配规则等信息没有列出，大家可以关注描述和预期功能。您可以在 RFC 2252 的第 5.1 至 5.4.3 节中轻松获得此信息。更多细节超出了本书的范围，可能取决于特定供应商的实施。

子模式和目录操作属性

The subschema publishes the schema to clients

子模式对象类是 LDAP v3 标准的必需元素；它是仅有的两个必需的对象类之一。子模式用于公布 LDAP 目录中支持的模式。客户端使用子模式条目（每个目录中可以有多个条目）来确定他们在与特定 LDAP 目录交互时可以期望的规则。

What Exactly Is the Definition of the Subschema?

有关子模式对象类的定义，请参阅 RFC 2252。此定义省略了强制性的
RFC 2251 中注明的子模式条目所需的属性。RFC 2251 使用允许的语言
附加强制和可选属性的实现，而 RFC 2252 不使用相同的
包容性语言。 RFC 2251 谈论的是子模式条目，而 RFC 2252 谈论的是
子模式对象类。尽管子模式条目和子模式定义在语义上不是
相同，遗漏只能视为错误。幸运的是，该标准确实概述了
属性可以在子模式条目中。

Table 4-1. directoryOperation attributes

Table 4-2. dSAOperation Attributes

子模式条目至少有四个强制属性和许多可选属性。强制属性
include cn,objectClass,objectClasses,andattributeTypes.object-Classes包含所有支持的列表
目录中的对象类。 attributeTypes 包含目录中所有受支持属性的列表。可选的，
子模式条目的操作属性称为目录操作属性。这些见表 4-1
属性和简短描述。您通过询问操作属性的值找到子模式条目
subschemaSubentry，它位于根 DSE 条目以及目录中的每个条目上。该值是
子模式条目。

rootDSE Entry and dSAOperation Attributes

rootDSE 条目提供有关目录服务器的基本信息。根 DSE 条目在标准中没有定义的对象类。然而，它必须存在并允许表 4-2 中列出的 dSAOperation 操作属性。其他属性可能位于 rootDSE 条目中以支持特定于供应商的功能。 ThedSAOperation 操作属性也可以包含在其他对象类定义中。

Syntaxes

ASN.1 is commonly used to build syntax

语法定义属性类型或匹配规则使用的数据格式。一种称为抽象语法符号一 (ASN.1) 的特殊系统用于传达语法的定义。 ASN.1 由 X.209 定义，类似于 BNF 表示法（在 RFC 822 中定义）。 ASN.1 是一个灵活的系统，可用于定义多种数据类型，从整数和字符串到各种数据类型的复杂集合和序列。它用于从您可能称为预定义工具箱的内容构建类型定义。该工具箱包含一小组简单类型，如整数、IA5string (ASCII) 或位串（二进制），以及表示组合这些简单类型的方法的特殊运算符，使用序列、集合和多项选择。可以通过替换引用不太复杂的定义来构建复杂类型定义。

ASN.1 有助于提供跨平台互操作性

ASN.1 有几个优点。一是 ASN.1 具有称为 BER 和 DER 的特殊编码规则，它们定义了如何将 ASN.1 中表示的内容放入适合传输的消息中。 LDAP 使用 BER 编码，特别是 BER 的简化子集。 ASN.1 消息以一种称为八位字节字符串的格式放置。八位字节字符串是任意长的 8 字节数据字符串。所以一个八位字节串的长度应该总是有一个因子 8。顺便说一句，ASN.1 被许多标准使用，包括 SSL 和 Kerberos 版本 5 使用的 X.509 证书，这使得这些技术更容易与 LDAP 集成。

There are no default syntaxes in the standard, only commonly used ones

RFC 2252 列出了 58 种 LDAP 服务器的默认语法，但只定义了其中的 33 种。供应商实现没有义务实现这些语法中的任何一个，并且他们可以实现新的语法。这是一个可能的可扩展性领域，但它可能以破坏与其他客户端或服务器的互操作性为代价。对于这些语法中最常见的，请参见 Appendix B.

LDAP 服务器支持的语法可以在称为 ldapSyntaxes 的属性中的子模式条目中发布。不幸的是，标准不需要包含此属性及其包含的信息。

Matching Rules

Matching rules are used to compare data values

LDAP 服务器使用匹配规则将属性值与 LDAP 客户端搜索或比较操作提供的断言值进行比较。服务器还使用匹配规则将客户端断言值转换为添加或修改操作中的属性值。最后，服务器使用匹配规则将声明的 DN 名称与目录中条目的 DN 进行比较。几乎每个 LDAP 操作都使用一个匹配规则，而且很多时候单个操作会多次使用匹配规则。匹配规则有一个简单的定义，将名称和 OID 与语法联系起来。然后属性在其定义中包含匹配规则，因此至少每个属性类型都支持相等匹配。

Extended operations employ matching rule use definitions for the attributes specified in the definition.

匹配规则使用定义与匹配规则定义略有不同。匹配规则使用定义将匹配规则定义与特定属性类型链接起来，以便在扩展搜索过滤器中使用。您使用这种类型的定义将匹配规则与属性类型定义之外的属性类型相关联。本章前面列出的 matchingRuleUse 属性的值表示目录使用的匹配规则。每个值表示一个匹配规则使用定义，该定义告诉目录在扩展搜索过滤器操作中哪些匹配规则与特定属性类型一起使用。

语法用于构建匹配规则

匹配规则定义和匹配规则使用定义都依赖于语法定义。语法匹配规则描述和匹配规则使用描述用于构建匹配规则。还为断言值语法与属性值语法不同的匹配规则定义了语法。 RFC 2252 中注明的基本匹配规则列于表 B-1 中 Appendix B.

OIDs

An OID is a string of numbers that guarantees the uniqueness of an object

OID 是一个特殊的数字，用于唯一标识某些对象，与技术无关。对象类、属性类型、语法、匹配规则和控件使用它们。事实上，每个对象定义都需要一个 OID。在保证唯一性很重要的领域，OID 在目录技术之外使用。例如，管理信息库模块 (MIB) 使用它们。管理软件通常使用 MIB 来了解每个实体的状态。 MIB 的一种常见用途是监视和管理联网的计算机。 OID 是由句点分隔的任意长的整数字符串。例如，1.4.23.98740 是一个有效的 OID。可以使用 OID 代替对象的名称。

OID 是集中管理的，具有授权

Internet 号码分配机构 (IANA) 管理 OID 空间并根据请求提供 OID。一旦组织拥有 OID，它就拥有该 OID 空间的所有扩展。如果 Mycompany 被授予 OID 1.4.23.98740，它还将拥有 1.4.23.98740.1 和 1.4.23.98740.2 等等。扩展 OID 称为创建弧。常见的约定是将每种类型的对象组织成一个单独的弧。 Mycompany 可能将其对象类放在 1.4.23.98740.1 下，属性放在 1.4.23.98740.2 下，语法放在 1.4.23.98740.3 下，匹配规则放在 1.4.23.98740.4 下，控件放在 1.4.23.98740.5 下，等等。但是没有这方面的规定。 Mycompany 可以委托给你一个arc，比如1.4.23.98740.6，但是Mycompany 最好不要同时使用那个arc，否则你和Mycompany 可能会遇到那个空间中的对象互操作的问题。网站 http://www.alvestrand.no/objectid/top.html 是唯一公开的 OID 列表。这是提供 OID 空间和定义之间映射的非正式尝试。

OIDs Are Problematic

OID 丑陋且难以使用，如果需要使用它们来代替命名对象，它们的长度可能会有问题。更复杂的是，没有人主动管理 OID 使用或相关定义。因此，您和我可能会为一个对象赋予完全相同的定义，但具有不同的 OID。当我们的目录互操作时，它们将无法将这些对象视为相同的。其中一个目录必须修改其模式定义。 OID 的唯一好处是它们保证唯一性。 IETF 应该认真考虑修改 LDAP 使用它们的方式。

OIDs aren't special, but they are required

总之，OID 不启用任何特殊功能，但它们确实唯一标识对象的定义。幸运的是，用户永远不必了解 OID。只有管​​理员和设计架构定义的人员需要使用它们。

Schema Checking

模式检查确保操作不违反模式定义

模式包含定义，但目录必须确保所有请求的操作都遵循这些定义。为此，它使用称为模式检查的过程。 LDAP 标准中未提及的架构检查是从 X.500 借用的另一个概念。因此，供应商选择如何（以及是否）实施模式检查。通常，模式检查过程将确保

• All attribute values conform to the syntax noted in the schema
  definitions.
• All mandatory attributes for an entry’s defined object classes are
  present.
• DN syntax is used properly

例如，通过检查以名称形式指定的属性以查看值是否符合 DN 语法规则来验证 DN 语法。 DN 通常不是条目的属性，因此必须单独检查。

架构违规导致整个操作失败

如果模式检查过程发现违反模式定义，它将向请求操作的客户端返回一个错误。整个操作将无法确保部分完成的操作不会导致用户不希望出现的状态。

关闭架构检查是个好主意吗？

如果管理员关闭模式检查，可能会导致目录中的数据不一致。当您的组织需要目录数据来实施企业应用程序时，这种缺乏一致性会产生重大问题。清理数据的成本高于保持架构检查的成本。更好的方法是让模式检查保持打开状态，并解决提示将其关闭的问题。您可能会发现您认为关闭架构检查的充分理由。例如，供应商以与您组织的要求（或标准）不一致的方式实现对象类，但不允许对该对象类定义进行任何修改。关闭模式检查会影响所有模式定义，因此您应该尽一切努力寻找替代解决方案。

Extended Schema Definitions

以下有趣的定义在 LDAP 标准中没有提及。如前所述，架构是可以扩展目录和增加目录功能的主要位置之一。这使得新的模式定义很有价值。因为 LDAP 目录之间模式的不一致会产生集成问题，所以新模式定义的标准化就更加重要了。以下定义均在标准文件或正在标准化的文件中注明。

DNS Extensions

通过 RFC 2247 支持 DNS 命名空间映射

RFC 2247 描述了 dc 属性以及 dcObject 和域对象类。这些架构元素用于允许在 DN 语法中使用 DNS 名称。 dc 属性明确了 DN 的哪一部分映射到 DNS 名称。 dc 属性直接映射到 DNS 名称，区域名称或主机名。它是 dcObject 和域对象类条目的命名属性。 dc 属性的值不区分大小写，符合 DNS 标准。几乎每个 LDAP 供应商都实现了这个 RFC。

dcObject 用于将 DNS 名称附加到现有容器对象类

dcObject 对象类是一个辅助对象类，它可用于扩展用作容器（如组织单位）的现有条目的定义，以支持到 DNS 命名空间的清晰映射。 dc 属性是 dcObject 对象类的强制属性。

You use the domain to create objects with DNS names

域对象类是结构对象类。您可以使用它来表示不需要基于现有对象类定义的新条目。 dc属性是强制属性，还有几个有用的可选属性。

extensibleObject Object Class

The extensibleObject includes every attribute type as an optional attribute

extensibleObject 对象类确实非常有趣。 extensibleObject 对象类的条目
允许您使用任何属性类型。您可以使用这种灵活性来表示不符合
整洁的分类或为条目提供最大的功能，而无需仔细设计对象
班级。你可以在 Chapter 8

You can use extensibleObject to extend an existing object class

extensibleObject 对象类是辅助性的，您可以将它添加到另一个对象类定义中以扩展其功能。其他对象类的强制属性仍然是必需的。 extensibleObject 对象类的定义并没有在字面上包括可选属性列表中的数百个可用属性；相反，它隐含地包含了它们。您可以使用此对象类来避免关闭架构检查过程，因为它允许架构规则内的所有可选属性。

P118