Chapter 2 - LDAP Namespace

“名称空间”意味着名称不仅仅是名称，而且还具有结构方面的含义。该术语包含目录的两个不同方面，并试图将它们联系在一起：如何命名事物以及如何组织它们。服务命名空间的定义很关键。这可能很明显，但命名空间可以让您找到东西。命名空间是用于标识给定环境中所有对象的一组约定；换句话说，它是命名系统。如果没有我们同意的名称空间，您和我可能指的是同一件事，但使用不同的语言。一个好的命名空间还可以确保一个对象的名称不会与另一个对象的名称冲突。命名空间可能是本书中介绍的最难的概念，所以如果它看起来令人困惑，请放心。为了帮助介绍命名空间的概念，下一节将检查一些示例和命名空间的属性。本章的其余部分重点介绍 LDAP 使用的名称空间。

The namespace includes more information than just the immediate identifier

一个很好的类比可以说明现实世界中命名空间的使用，即全球使用的邮政地址系统。在 postal 命名空间中，一封信的地址（或命名，如果你愿意的话）如下：

          Person's name
          Street number Street
          City, State/Province/Region Zip code
          Country

这个名称（地址）通过它的构造方式和每个组件的值告诉我们很多事情，同时也唯一地指定了接收者。我们知道此人居住在所列国家、所列州、所列城市、所列街道等。我们还知道这封信是写给住在这个地址的人，而不是住在其他地方的同名人。

By using a hierarchical namespace, you can delegate information management

但是请考虑这个邮政示例很好地说明的另一点。因为这个命名空间是以层次化的方式组织的，并且明确指定了范围递减的语言环境，所以可以委托涉及对象（换句话说，接收者）的管理。换句话说，当读者在邮箱中投下一封信给这个人时，它可以先被发送到负责所列国家的邮政服务。之后可以寄到州邮局，依此类推，直到到达当地邮局，可以投递。此命名空间中固有的层次结构方便地提供了一种有效的合作委托管理方式。

You can use the namespace for other management purposes

邮政示例说明了一个名称空间，该名称空间用于唯一标识对象并在这些对象之间建立结构化关系。除了标识和结构之外，名称空间还可以参与完成其他几个目录管理操作。作为此类功能的示例，大多数供应商都实现了数据分区和复制。第 5 章涵盖这些和其他特殊的结构概念。

Namespace can also refer to a specific directory implementation

当在特定目录命名空间的上下文中使用术语“命名空间”时，其含义略有不同。在这种情况下，它不是被引用的命名系统。在此上下文中，该术语指的是该目录中的所有对象以及所选的特定结构。在 LDAP 中，每个目录术语似乎都有两个名称，因此请为大量具有重复含义的新词汇做好准备。您可能听说过术语目录信息树 (DIT) 用于指代特定的目录名称空间。

DNS

The server’s DNS name is the basis for the name of the root of the LDAP directory.

域命名系统构成了 LDAP 名称空间基础的一部分，它也是名称空间的一个很好的例子。探索 DNS 的工作原理将有助于强调有关 LDAP 的要点。如第 1 章所述，LDAP 目录服务器的 DNS 名称在确定目录根名称（即目录的基本 DN）时尤为重要。是否使用DNS命名会影响LDAP命名空间的实现。目录的基本 DN 不必与目录服务器的 DNS 名称匹配，并且当需要跨多个服务器分布的目录时，通常两者不匹配。除了与命名空间的这种连接之外，DNS 还在 LDAP 客户端定位 LDAP 目录服务器的过程中发挥关键作用。 DNS 不必在服务器位置使用，但经常使用。

DNS maps a human-readable name to a computer-readable name

DNS是一个分布式目录服务，由全球成千上万的服务器维护。这个目录中有数十亿条记录，将一个IP地址映射到一个计算机名称，反之亦然。IP地址是数字，是一台计算机用来指向另一台计算机的 “名字”。人们通过字母数字名称了解计算机。一个样本记录可能是host.mycompany.com。在127.42.12.6。这条记录表示host.mycompany.com是IP地址为127.42.12.6的计算机的人可读名称。

DNS Hierarchy

A hierarchy is employed to provide a clear basis for authoritative name resolution

这些记录分布在数百万个称为区域的文件中。每个区域都保存其具有权威性的 DNS 名称空间的记录副本。换句话说，每个区域只允许更改整个 DNS 名称空间的一小部分。 host.mycompany.com 计算机记录属于 mycompany 区域。 mycompany 区域属于 com 区域。 com 区域属于根区域。根区域是所有 DNS 中最顶层的区域。图 2-1 显示了 DNS 区域层次结构图。区域文件保存在该区域的权威 DNS 服务器上。每个parent zone是一个权限，用来区分哪个DNS服务器对哪个child zone有权限。单个根区域保存每个一级 DNS 区域的权威记录。这形成了一个层次结构，客户端计算机可以在合理保证获得权威名称解析的情况下进行查询。

                                          Figure 2-1. Hierarchy of DNS zones (the DNS namespace)

DNS Resolution

The hierarchy provides an efficient way for a client computer to perform name resolution

DNS 名称空间提供了一个系统，用于组织计算机名称记录和解析计算机名称的位置。客户端计算机通常被定向查询本地区域的权威 DNS 服务器以进行名称解析。例如，计算机 host.mycompany.com 将配置为查询 DNS 服务器以查找 mycompany.com。如果 host.mycompany.com 想知道 unknown.whitehouse.gov 的 IP 地址，它会首先询问位于 mycompany.com 的 DNS 服务器。 mycompany.com 会将其引用到 com DNS 服务器。 com DNS 服务器会将其引用到根 DNS 服务器。根 DNS 服务器会将其引用到政府 DNS 服务器。 gov DNS 服务器会将其引用到 whitehouse.gov DNS 服务器。 whitehouse.gov DNS 服务器随后会使用 unknown.whitehouse.gov 的 IP 地址回复客户端。通常 DNS 服务器会缓存有关重要区域的信息，例如根和一级 DNS 服务器，因此实际上所描述的过程会遵循更短的路径。

Basic DNS Record Types

There are several basic types of DNS records. Table 2-1 lists these records along with a short explanation

LDAP 如何使用 DNS

第 1 章描述了 LDAP 和 DNS 之间的非正式连接。此连接主要为 LDAP 客户端提供一种机制来定位特定目录的目录服务器。定义 LDAP 的 RFC 没有提到 DNS，但它们暗示了它。例如，RFC 2255 定义了 LDAP URL 语法，我将在本章稍后部分返回。仔细检查后，您会发现此语法的主机名部分显然依赖于 DNS，尽管未提及 DNS。所以对 DNS 的依赖是非正式的，但实际上每个 LDAP 产品都希望 LDAP 客户端使用 DNS 来定位他们的 LDAP 目录服务器。这种依赖有充分的理由。一个原因是 DNS 是主导的名称解析标准，另一个原因是 LDAP 使用的传输协议是 TCP，它依赖于 DNS。

                                                               Table 2-1. Basic types of DNS records

DNS is used to register a directory service

LDAP 使用 DNS 名称空间的一个重要含义是，通过注册 DNS 域名以将主机或主机区域连接到 Internet，您可能会无意中注册目录服务名称空间。电子邮件传送命名空间与 MX 记录和许多其他基于网络的服务类似。当我向权威 DNS 服务器注册 mycompany.com 的 A 记录时，mycompany.com 可能成为有效的目录服务名称空间。目前大多数供应商都希望您的 LDAP 目录对每个目录服务器都有一个 A 记录。一些供应商进一步期望，如果您部署分布在多个目录服务器上的目录，您将使每个目录服务器都从属于 DNS 名称空间。例如，如果我分发了 mycompany.com 目录，目录服务器可能有 dir1.mycompany.com、dir2.mycompany.com 等的 A 记录。

LDAP is making increasing use of DNS for its namespace functionality

除了已经成为实践的非正式期望之外，还有一些关于 DNS 和 LDAP 之间关系的正式工作。 RFC 2247 为 DNS 提供了一个明确的标准，可以轻松地将其合并到 LDAP 在目录中使用的命名空间中。定义了域组件 (dc) 属性，它可以用作容器对象目录中的命名属性。在 IETF 中，还有其他广泛的工作涉及使用 DNS 来扩展 LDAP 命名空间功能。文档草案包括一项建议，即使用 DNS SRV 记录为客户端定位给定命名空间的 LDAP 目录。正如 Microsoft 的目录实施所证明的那样，该提案已获得重要支持。它可能会在几年内取代现有的非正式做法。另一项提议建议使用带有引用的 DNS SRV 记录。第 5 章讨论了推荐。、

LDAP Object Structure

The internal structure of an LDAP directory primarily provides organization of entries via a hierarchy. The structure is
critical to the usability and manageability of the directory. The structure can also allow the benefits listed in Benefits 2-1 to
be easily provided

Benefits 2-1 LDAP namespace benefits
[1] 该结构可以更轻松地跨多个服务器分发信息。分布在多个服务器上的目录反过来又提供了更高的可靠性和将目录信息定位在靠近远程位置的可能性
[2] 该结构可以使访问控制的管理更简单
[3] 该结构可以使具有特定目录要求的应用程序集成到您的目录中
[4] 该结构可以通过将相似的条目分组在一起来简化目录维护

该结构本身不提供这些好处。 Mycompany 实现这些好处取决于它的目录实现和名称空间的设计。如何提供这些好处本身就是一个主题（参见第 5 章）

A namespace with a hierarchy of structure has other benefits

如邮政示例中所述，按层次结构组织目录对象提供了一种有效的委托管理条目的方法。要添加条目，您需要在目录中的适当位置获得某种类型的授权。由结构的存在创建的管理层有助于在条目中强制执行一致的数据。

Containers enable structure

由于容器条目，LDAP 目录中可能存在层次结构。容器条目是特殊条目，允许其他条目分层放置在它们下面。容器下方的条目有时称为容器的子项，或容器的从属条目。容器有时称为其下条目的父级。您还可以通过说条目被父项包含来引用容器与其下方条目之间的关系。

Allowed Structures

Only a specific kind of structure is allowed in LDAP

LDAP 目录中的名称空间不允许结构内的任意连接。不允许出现类似于网页之间链接关系的结构（即Web结构）。更具体地说，一个容器在其正上方只能有一个父级。一个容器可以有多个子容器，但只有一个父容器。这种类型的结构通常称为树结构。该术语可能会让您想起命名空间的另一个术语：目录信息树 (DIT)。图 2-2 和 2-3 显示了有效和无效名称空间结构的示例。当添加新条目时，规范的结构方法几乎不会导致服务中断，因为只写入新条目，而不必修改现有条目。

                              Figure 2-2. Example of valid hierarchical namespaces in an LDAP directory

                              Figure 2-3. Examples of invalid hierarchical namespaces in an LDAP directory

LDAP Containers

With LDAP, any entry can become a container

您可以假设 LDAP 目录中的容器具有将条目标识为容器的属性。但事实并非如此。当条目被放置在条目之下时，条目成为容器，但发生这种情况时，LDAP 目录不会修改容器条目。使用 LDAP，每个条目都有成为容器的可能性，并且这种设计支持许多分层机会。

You create a container by creating an entry below another entry

您还可以假设容器条目具有一个属性，该属性列出了该容器中包含的所有条目。这也不是这样。除了每个条目的名称之外，没有任何特殊机制存储层次结构。您可以通过在另一个条目下方创建一个条目来创建一个容器！这个概念需要一些时间来适应，因为逻辑表明容器条目需要修改。但是，特定的 LDAP 实现可能会超出 LDAP 规范，并具有子信息的特殊属性，以提供额外的管理功能。

Although every entry can be a container, some object classes may make more sense

在某些 LDAP 服务器实现中，对于条目必须成为容器的对象类可能存在限制。这些限制称为结构规则（更多详细信息，请参见第 4 章）。通常，由于历史原因，有几个对象类经常用作容器。这些对象类是最受欢迎的，因为它们是 X.500 中唯一允许的容器。表 2-2 列出了这些对象类，并附有每个对象类的简短描述以及它们作为容器可能有用的原因。在这些对象类中，组织单位的使用最为广泛。它经常被用于更广泛的目的，而不仅仅是政治结构。您不必使用这些对象类作为目录中的容器，但您可能会发现这些类受到青睐是有充分理由的。

Structure Rules

Structure rules restrict where an entry of an object class can be created

LDAP 还支持特定于对象类的结构规则（有关此处内容以外的详细信息，请参阅第 4 章）。此功能不一定是 LDAP 标准的一部分，但它已由多个供应商实现。对象类结构规则对可以创建特定对象类的条目的位置施加限制。例如，我可能会将结构规则与组织单位对象类相关联。此结构规则可能要求 objectclass=organizationalUnit 的所有条目都是 objectclass=organization 条目的直接子项。此规则在名称空间中施加了额外的限制，并且还限制了功能。结构规则由模式检查过程强制执行。 Mycompany 将希望审查特定于其所选供应商的任何结构规则。

Table 2-2. Common object classes used for containers

Naming Contexts

Naming contexts are used to refer to portions of a directory

每个顶层容器的名称都有一个区别，也称为命名上下文。不过，命名上下文不仅仅是容器。命名上下文是从顶级容器开始的连续子树。例如，如果您在 Mycompany 中引用 Accounts 命名上下文，则指的是 Accounts 容器、它的所有子条目以及 Accounts 容器下的所有容器和条目，如图 2-4 所示。这样，您可以方便地引用目录的各个部分。命名上下文是与目录后缀（或 X.500 中的上下文前缀）相同的术语。 Accounts 命名上下文是 Accounts 后缀。

Figure 2-4. Example of naming contexts in an LDAP directory

The directory has no single root entry; instead, all the naming contexts are peers connected by the
root DSE

LDAP 目录的根实际上没有目录对象。相反，有一个类似于根对象的特殊条目，称为根 DSE 条目，它列出了目录服务器上的所有命名上下文。该目录使用命名上下文来快速区分对条目的请求是否在已知的命名上下文中。

A flat namespace allows quick growth

在扁平结构的目录中，通常会忽略组织和管理，而添加新条目变得越来越容易。正如您在图 2-5 中所看到的，结构的缺乏鼓励了轻松的增长，因为只有一个组织容器在使用中，对添加几乎没有限制。但在这个模型中，一致性和可扩展性可能成为一场噩梦。当通用查询定期返回大量条目时，可伸缩性成为一个问题。当有用的唯一名称的数量达到极限时，可扩展性也会成为一个问题。可能会达到此限制，因为任何特定容器中只有一个条目可以用任何特定名称命名。分层模型通过在层次结构中的多个级别组织条目来回避这些问题。

Figure 2-5. A flat namespace in an LDAP directory

---

Don’t Be Fooled by the Figures
Note that the figures throughout the book include a root entry, when in actuality there is no such entry. This
is purely to allow you to know the context of the namespace being pictured. It is a common practice in
diagramming directory namespaces, but it fooled me for a long time into thinking there really was a root
entry.

目录命名空间有四个基本的有用部分：

1. Political/functional— Dividing information based on an organization, or difference in functional needs. For
   example, you might separate the HR directory information from the Marketing directory information
2. Geographic— Dividing information based on the location of the clients who will be accessing the information or
   based on the location of the real objects that the information in the directory represents. For example, you might
   separate the personal information for individuals in Europe from the same information for U.S. citizens
3. Resource-based— Dividing information based on the type of resource. For example, you might separate the
   printer information from the server information, or separate public resources from private resources
4. User classification— Dividing information based on users’ needs. For example, you might separate
   information for managers from information for staff

---

How Do I Decide How to Structure My Directory?

决定如何构建目录可能是一件困难的事情。同样困难的是决定何时分割平面结构或单个容器。名称空间的四个基本部分的混合组合通常可以很好地适应某种情况。通常地理划分伴随着在多个服务器上分布目录命名空间。第 5 章更详细地介绍了分布式目录服务器。做出该决定的另一个因素是需要通过在多个服务器上复制某些类型的目录数据，以更容错的方式提供这些数据。 LDAP 供应商对最小复制单元有不同的要求，这将影响设计决策。请记住，实施结构化的最大原因是为了简化信息管理。如果你实施一个没有明确管理目标的结构，你会后悔你的选择。在查看用于实现层次结构的每个模型时，您应该考虑以下问题

1. Will users of the directory need different levels of access to the information? If so, what structure
   can be implemented to simplify the access management?
2. Does the directory help to provide management of computers or other devices? If so, are there
   compelling reasons to manage specific computers differently from others
3. Are the political or organizational divisions under consideration? If so, make sure that you make it
   easier to manage resources, users, or directory information. The most frequent mistake is to
   blindly implement the structure based on internal organizational boundaries that require no
   different level of management.
4. For every new container, ask, “What administrative management purpose does this container
   serve?”

尝试使您的目录尽可能平坦，同时具有足够的结构来委派管理并实现其他目标，如好处 2-1 中的目标。在未来的情况下，过多的结构可能会受到限制。例如，如果使用广泛的政治结构作为命名空间划分的基础，那么以后的重组或公司合并可能会带来严重的问题。有趣的是，LDAP 标准有一个要求也可能影响您实现的设计。 LDAP 客户端只需要支持在根和任何条目之间有十个级别的层次结构。如果你实现更复杂的东西，它可能无法工作！这些指南可能不会为您创建结构，但它们应该有所帮助。

---

LDAP Object Naming

牢牢掌握 DNS 和 LDAP 目录中允许的可接受结构后，您就可以考虑 LDAP 名称空间的内部细节了。 LDAP 使用的名称空间非常灵活，允许每个条目有多个名称，并且可以使用不同的属性来构成名称。 LDAP 提供的命名灵活性不会以确保每个条目都具有在整个目录中唯一的名称为代价。

Relative Distinguished Name (RDN)

The RDN is an entry’s naming attribute; it has a unique value in the container of the entry

相对可分辨名称属性为容器中的每个条目提供唯一的名称标识符。例如，图 2-6 显示了一个 RDN 为 cn=Brian Arkills 的人员条目。同一容器内不能有两个具有相同 RDN 值的条目。因此，在 cn=Brian Arkills 的 People 容器中不能有其他人条目，并且在任何特定容器中，对于该容器的从属人员条目，cnattribute 值必须是唯一的。 RDN 属性是条目的属性之一，称为该类型条目的命名属性。但一般来说，任何特定对象类的命名属性并不强制为特定属性。在对象类定义中，一些 LDAP 供应商确实强制将特定属性作为命名属性，但这不是 LDAP 标准的一部分。在图2-6的例子中，cn(common name)属性是person对象类的命名属性

Figure 2-6. An example of an RDN

You can substitute a unique string of numbers called an object identifier for the attribute type in an
RDN

您可以使用称为对象标识符 (OID) 的特殊数字字符串来代替属性类型。每个属性类型都有一个分配给它的唯一 OID。例如，cnattribute 的 OID 是 2.5.4.3。 OID 用于唯一标识一个属性类型。例如，您可以定义一个名为 myattribute 的属性类型。我还可以定义一个名为 myattribute 的属性类型。我们怎么知道它们是否是相同的属性？通过比较两个属性的OID。有关 OID 的更多详细信息，请参阅第 4 章；现在，您需要知道 OID 可以替代属性类型的名称。当使用 OID 作为命名属性时，OID 与名称空间相关。例如，图 2-6 中条目的有效 RDN 是 2.5.4.3=Brian Arkills。

cn is frequently used in RDNs, but other types are possible

cnattribute 是最常用的命名属性；但是，还有其他几种常用的属性类型（请参见表 2-3）

Naming Attributes

You can use any attribute with a unique value in the RDN

您可以在该容器的条目中使用具有唯一值的条目的任何属性类型来形成 RDN。虽然这个规则看起来很混乱，但它允许客户端更灵活地识别一个意想不到的形式的条目。一般来说，模式检查器必须确保每个新条目或对现有条目的修改都至少为该条目留下一个唯一的 RDN，因此该条目具有唯一的名称。一些 LDAP 实现确实标准化了任何给定对象类的命名属性；在这种情况下，被指定为命名属性的属性必须满足模式检查器强制执行的唯一性规则。无论哪种方式，都可以保证每个条目都有一个在整个目录中唯一的名称。

Table 2-3. Common attributes used as naming attributes

您还可以在 RDN 中使用多个属性。这称为多值 RDN。当一个或两个属性值不满足唯一性要求时，此功能允许您指定一个具有两个属性值交集的唯一条目。例如，考虑图 2-7 中所示的情况。有两个电话号码相同的人，还有两个同姓的人。您不能使用电话号码或姓氏属性来唯一指示 Luke Skywalker 的条目，但两种属性类型的组合将创建唯一组合。 RDN 将是 sn=Skywalker+telephoneNumber=+1 222 222 2222。当然，在这种情况下，您可以更轻松地使用 cn=Luke Skywalker 作为 RDN；但是在某些情况下您可能不知道 cn 值，因此使用多值 RDN 会更有效。并非所有供应商实施都完全支持此功能。仅在仔细规划后使用。

Distinguished Name (DN)

A DN provides a name for users to uniquely refer to each directory entry

DN 为每个条目提供了一个完全限定的名称，因此很清楚引用了哪个条目，以及该条目在层次结构中的位置。在 LDAP 规范下，每个条目不存储其 DN，目录也不索引目录条目的 DN。相反，DN 主要是为了让目录的用户能够向目录指示需要哪个条目。 DN 由客户端操作请求提供，目录动态查看条目是否与此声称的 DN 匹配。特定供应商可能会将 DN 存储为条目的属性或索引所有 DN，但这既不是必需的也不是预期的。

The DN is a concatenation of the entry’s RDN and the RDN of every container between the entry and
the directory root

形成 DN 可能有点棘手，因为用户必须知道条目上方所有容器的 RDN。 DN 是一个字符串，由条目的 RDN 与条目的容器的 RDN 连接，该条目的容器的 RDN 与该容器上方的每个容器的每个 RDN 连接。逗号分隔每个组件。下面是 DN 的一个更简单的递归定义： DN 是由条目的 RDN 与其容器的 DN 串联而成的字符串。如图2-7所示，右边的entry有两个可能的DN。

cn=Luke Skywalker,ou=People,dc=mycompany,dc=com
or:
sn=Skywalker+telephoneNumber=+1 222 222
2222,ou=People,dc=mycompany,dc=com

---

这个电话号码是多少？
表示电话号码的属性具有普遍接受的语法，因此世界各地的用户都能理解该号码。接受的语法以加号和国家代码开头，后跟国内电话号码。在前面的多值 RDN 示例中有两个加号。一个是多值 RDN 语法的一部分，用于将两个 RDN 链接到一个 DN，另一个加号应出现在电话属性中

---

适当地使用命名属性 命名属性对您的目录至关重要。
您目录的用户将不断引用这些属性的值来查找和修改条目。这种设计有几个含义。这些属性的值不应包含被视为私有的信息。否则，您将需要对该属性设置访问控制，这将阻止将该属性用作 RDN。使用访问控制还可能导致某些条目被排除在关键业务流程之外。供应商和部署团队都可能会犯错误，将带有可能被视为私有的信息的属性用作极其重要的对象类的命名属性。命名属性的值应该是静态的。更改名称可能会导致已“硬编码”为使用特定名称的程序出现不良行为。正如程序是硬编码的一样，人也是。他们不会总是知道何时进行了名称更改，并且他们可能很难找到这个重命名的条目或知道重命名的条目与原始条目相同。回避这两个问题的一种方法是在命名属性中使用任意的、公共的但唯一的值。这种做法从设计的角度来看可能感觉不对，因为名字不太个性化，但它是有效的。保证任何人都可以查询所有条目，并且条目名称不会改变

Naming Special Characters

You should treat some special characters differently when they are used in a DN

当在 DN 中使用几个字符时，您必须对其进行特殊处理。您可以将这些特殊字符存储为不带转义字符的命名属性值；但是在 DN 中引用这些字符时，必须对它们进行转义。您可以通过在它们前面加上反斜杠字符 () 来特别标记这些字符，以避免含义错误。这有时称为注释或转义。例如，使用值中包含逗号的 RDN 指定 DN 会导致混淆，因为目录在 DN 中使用逗号来分隔 DN 组件。通过在 DN 中转义表 2-4 中列出的字符来特殊处理它们。 RFC 2253 明确表示供应商可以将其他字符设为特殊字符，因此请注意检查供应商对特殊情况的实现。

Table 2-4. Special characters in distinguished names

LDAP 黑客：可能的代码注入？

---

代码注入和格式字符串攻击是当今其他技术中常见的安全漏洞。近年来，SQL、printf、Web 服务器和本地 Web 应用程序都出现了此漏洞。这些类型的漏洞基于错误的异常编码或用户输入解析，它们允许恶意攻击者在服务器上插入命令或代码。这些类型的漏洞通常围绕着特殊字符，以及当用户将这些特殊字符作为输入时如何处理这些特殊字符的模棱两可的行为。虽然在这方面没有已知的 LDAP 漏洞，但我相信在不久的将来会发现漏洞。随着越来越多的组织将数据集中到 LDAP 目录中，更多的审查将产生发现这些漏洞背后的编码错误所需的反复试验

URL Naming

When using a Web browser as an LDAP client, you should use a special naming format

现在大多数 Web 浏览器都支持 LDAP 客户端功能。因此，您可以通过浏览器方便地进行搜索。 LDAP URL 的命名格式完全在 RFC 2255 中指定。此格式与标准 LDAP 客户端使用的格式略有不同。 URL 有大量特殊字符，必须按照 RFC 1738 中指定的特殊方式处理，不同的格式适应这一点。 LDAP URL 命名格式并非仅供 Web 浏览器使用；标准的 LDAP 客户端也必须能够使用它来支持推荐。

How to use LDAP URL syntax

LDAP URL 以协议名称 ldap:// 开头，后跟目录服务器的主机名和端口，然后是基本 DN 和其他名称，例如范围、过滤器和所需的属性。语法是

ldap://[hostname][/dn[?[attributes][?[scope]
[?[filter][?[extensions]]]]]

语法的组成部分是
hostname— The hostname specifies the LDAP server and the TCP/IP port used by the LDAP server. As
indicated by the brackets, both the hostname and port are optional. A default of port 389 is used if the port isn’t
specified. If the hostname isn’t specified, the client must have prior knowledge of which server to contact.
Separate the hostname and port with a colon, mycompany.com:389, as specified in RFC 1738.

DN— The DN component specifies the base distinguished name for the search.

attributes— The attribute component specifies the attribute types to return from the entries that match the
search parameters. If left unspecified, all attributes are returned.

scope— The scope component specifies the scope of directory entries to return. As with typical LDAP
searches, base,one, andsub are possible values. If the value is left unspecified,sub is assumed.

filter— The filter component specifies a limiting filter on which entries should be returned. It follows the same
syntax as typical LDAP searches. If left unspecified, (objectclass=*) is assumed, so that all entries are
returned.

extensions— The extensions component specifies optional LDAP URL extensions. These extensions can be
defined as needed, and they don’t necessarily correspond to LDAP extended operations. Only one such
extension has been standardized, called the bindname extension. The bindname extension allows the client to
specify the DN of a directory entry to use in authenticating to the directory. A subsequent authentication
challenge would then be initiated. You can find more details in Section 4 of RFC 2255.

Here is an example of an LDAP URL:

ldap://mycompany.com:389/cn=Brian
Arkills,ou=People,dc=Mycompany,dc=com?sn

给定图 2-6 中所示的示例目录，此搜索将返回条目的 n 属性 cn=Brian Arkills,ou=People,dc=mycompany,dc=com。搜索具有子树范围，但指定基 DN 的条目没有子项，因此仅返回一个条目。

Special URL characters must be treated in a unique way

有几个非法和特殊的 URL 字符。这些字符包括本章前面提到的特殊字符以及几乎所有非字母数字字符（值得注意的例外包括 $-_.!*'()）。当您在 LDAP URL 组件中使用这些字符时，您必须转义它们。转义方法在 RFC 1738 中有完整描述，但它相当于用 % 字符和两位十六进制 ASCII 代码代替相关字符。大多数浏览器会自动将非法 URL 字符转换为转义版本。

LDAP v2 Naming Conventions

LDAP v3 must support all LDAP v2 naming conventions

除了 LDAP v3 标准定义的特殊命名语法限制外，符合 LDAP v3 的实现还必须支持符合 LDAP v2 的命名。 LDAP v3 实现无法生成符合 LDAP v2 的名称，但它们必须通过将名称转换为符合 LDAP v3 的标准来接受和处理这些名称。 RFC 2253 第 4 节阐明了这种兼容性。两个版本之间存在明显差异。 LDAP v2 在以下语法点上不同于 LDAP v3：

LDAP v2 uses semicolons as RDN separators.
LDAP v2 allows spaces before and after each of the following:

• RDN separators (either comma or semicolon)
• Equal signs between the attribute type and value
• Plus signs in a multivalued RDN
  LDAP v2 allows quotation marks at the beginning and end of an RDN value, which are not part of the RDN
  attribute value. If you use quotation marks in this way, all the special DN characters that usually require
  escaping do not need to be escaped.
  LDAP v2 allows the textOID. oroid. to prefix an OID attribute type string.

同样，符合 LDAP v3 的目录接受所有这些语法差异，但它会自动将它们转换为正确的符合 LDAP v3 的语法以进行处理

---

将您的目录设计得对人友好

虽然您可以将表 2-4 中列出的特殊字符存储为命名属性值，但请仔细考虑备选方案。例如，假设您计划以姓氏、名字的格式存储一个人对象的 cn。由于 CN 中的逗号，搜索这些人员条目必须转义逗号才能成功找到该条目。用户必须熟悉被认为是特殊的字符，这样他们才能成功地使用该目录。在命名属性值时避免使用特殊字符不是必需的，但这样做将为您的用户创造更友好的体验。

Special LDAP Structural Concepts

随着 LDAP 的成熟，结构功能的扩展迅速发展以反映分布式计算模型。需要某些结构特征来支持位于多个服务器上的目录、更高的目录可靠性、与其他目录的集成以及基于地理的本地化目录数据。复制、引用和别名是用于启用此功能的高级功能。其中一些特殊功能是 LDAP 标准的一部分，而其他功能仅在某些供应商实现中可用。要进一步探索如何扩展 LDAP 命名空间，请参阅第 5 章，该章重点介绍目录管理

Summary

The namespace provides the structure to store and find directory information

总之，LDAP 目录使用的名称空间遵循有序的层次模型。组织中预先存在的 DNS 名称空间通常用于扩充此模型。分层模型提供了许多优点，但也许最关键的是知道条目的名称可以告诉您条目在目录结构中的位置