“Namespace” implies that a name is not simply a name, but holds meaning in terms of structure as well. The term takes two different aspects of the directory and seeks to tie them together: how to name things and how to organize them. The definition of a service's namespace is critical. It may be obvious, but a namespace lets you find things. Namespace is the set of conventions used to identify all the objects in a given environment; in other words, it is the naming system. Without a namespace that we agree on, you and I might be referring to the same thing, but using different languages. A good namespace also ensures that one object's name doesn't conflict with that of another object. Namespace is probably the hardest concept presented in this book, so take solace if it seems confusing. To help introduce the concept of namespaces, the next section examines some examples and the properties of namespaces. The rest of the chapter focuses on the namespace that LDAP employs.
The namespace includes more information than just the immediate identifier
A good analogy that illustrates the use of a namespace in the real world is the postal address system used worldwide. In the postal namespace, a letter is addressed (or named if you will) as follows:
Person's name
Street number Street
City, State/Province/Region Zip code
Country
This name (address) tells us many things by the way it is constructed and the value of each component, while also uniquely designating the recipient. We know that the person lives in the country listed, in the state listed, in the city listed, on the street listed, and so on. We further know the letter is intended for the person who lives at this address, not a person by the same name who lives elsewhere.
By using a hierarchical namespace, you can delegate information management
But consider another point that is well illustrated by this postal example. Because this namespace is organized in a hierarchical fashion with locales of diminishing scope clearly designated, management involving the object (in other words, the recipient) can be delegated. In other words, when the reader drops a letter in the mailbox to this person, it can first be sent to the postal service responsible for the country listed. After that, it can be sent to the state postal service, and so on, until it reaches the local post office and can be delivered. The hierarchy that is inherent in this namespace conveniently provides an effective means for cooperative delegation of management.
You can use the namespace for other management purposes
The postal example illustrates a namespace that is used to uniquely identify objects and establish structured relationships between those objects. Besides identification and structure, the namespace can be involved in accomplishing several other directory management operations. As examples of such functionality, most vendors implement data partitioning and replication. Chapter 5 covers these and other special structural concepts.
Namespace can also refer to a specific directory implementation
When the term “namespace” is used in the context of a specific directory namespace, a slightly different meaning is intended. In this context, it isn't the naming system being referenced. In this context, the term refers to all the objects in that directory and the specific structure that was chosen. With LDAP, there are seemingly two names for every directory term, so be prepared for a multitude of new vocabulary words with duplicate meanings. You may hear the term directory information tree (DIT) being used to refer to a specific directory namespace.
The server's DNS name is the basis for the name of the root of the LDAP directory
The domain naming system forms a portion of the foundation for the LDAP namespace, and it is also a good example of a namespace. Exploring how DNS works will help underline key points about LDAP. As noted in Chapter 1, the DNS name of the LDAP directory server can be particularly important in determining the name of the root of the directory, which is the directory's base DN. Whether DNS is used in naming affects the implementation of an LDAP namespace. A directory's base DN doesn't have to match the DNS name of the directory server, and usually the two don't match when a directory distributed across multiple servers is desired. Aside from this connection to the namespace, DNS can also play a critical role in the process of the LDAP client locating the LDAP directory server. DNS does not have to be used in the location of the server, but frequently it is.
DNS maps a human-readable name to a computer-readable name
DNS is a distributed directory service that is maintained by thousands of servers across the globe. There are billions of records in this directory, which map an IP address to a computer name and vice versa. IP addresses are numbers that are the “name” that one computer uses to refer to another computer. People know computers by alphanumeric names. A sample record could be host.mycompany.com. IN A 127.42.12.6. This record denotes that host.mycompany.com is the human-readable name of the computer at the IP address 127.42.12.6.
A hierarchy is employed to provide a clear basis for authoritative name resolution
These records are distributed across millions of files called zones. Each zone holds a copy of records for the DNS namespace for which it is authoritative. In other words, each zone allows changes to only a small portion of the entire DNS namespace. The host.mycompany.com computer record belongs to the mycompany zone. The mycompany zone belongs to the com zone. The com zone belongs to the root zone. The root zone is the topmost zone in all of DNS. Figure 2-1 shows a diagram of the hierarchy of DNS zones. The zone file is kept on the authoritative DNS server for that zone. Each parent zone is the authority for distinguishing which DNS server is authoritative for any child zone. A single root zone holds the authoritative records for each of the first-level DNS zones. This forms a hierarchy, which client computers can query with a reasonable assurance of getting authoritative name resolution.
The hierarchy provides an efficient way for a client computer to perform name resolution
The DNS namespace provides a system both for organizing computer name records and for resolving the location of the computer name. The client computer is typically directed to query the authoritative DNS server of the local zone for name resolution. For example, the computer host.mycompany.com would be configured to query the DNS server for mycompany.com. Should host.mycompany.com want to know the IP address for unknown.whitehouse.gov, it would first ask the DNS server at mycompany.com. mycompany.com would refer it to the com DNS server. The com DNS server would refer it to the root DNS server. The root DNS server would refer it to the gov DNS server. The gov DNS server would refer it to the whitehouse.gov DNS server. The whitehouse.gov DNS server would then reply to the client with the IP address of unknown.whitehouse.gov. Usually DNS servers cache information about important zones like the root and first-level DNS servers, so in reality the process described would follow a much shorter path.
There are several basic types of DNS records. Table 2-1 lists these records along with a short explanation.
Chapter 1 describes an informal connection between LDAP and DNS. This connection primarily provides a mechanism for an LDAP client to locate the directory server for a particular directory. The RFCs that define LDAP don't refer to DNS, but they allude to it. For example, RFC 2255 defines the LDAP URL syntax, which I return to later in this chapter. On close examination, you would find that the hostname component of this syntax clearly relies on DNS, although DNS isn't mentioned. So the reliance on DNS is informal, but in practice every LDAP product expects LDAP clients to use DNS to locate their LDAP directory server. There are good reasons for this dependency. One reason is that DNS is the dominant name resolution standard, and another is that the transmission protocol that LDAP uses is TCP, which relies on DNS.
Table 2-1. Basic types of DNS records
Record Type | Class | Explanation |
|---|---|---|
Address | A | Address records simply map a computer name to an IP address. More than one IP address can be assigned to a computer name by using a second A record. More than one computer name can be assigned to a single IP address, but you should use a canonical name record for this purpose. |
Canonical Name | CNAME | The canonical name record is sometimes known as the alias record. It is used to allow a computer to be referred to by more than one name; the secondary name is entered in a record with the IP address of the primary name. Multiple canonical name records are allowed. |
Mail Exchange | MX | The mail exchange record is used to indicate the IP address e-mail for a given name. You can designate that all mail for a zone should be delivered to a single IP address. |
Pointer | PTR | The pointer record has the opposite function of an address record. It maps an IP address to a computer name. This allows computer services to verify that a request coming from a client is not being hijacked by a nonauthorized computer. |
Name Server | NS | The name server record is used to denote the authoritative name servers for the zone. |
Start of Authority | SOA | The start of authority record is used to communicate with other authoritative name servers in the DNS hierarchy. Information on how often to check for updates is stored in this record. |
Service | SRV | The service record is used to indicate a network service. Several LDAP vendors use this record to provide client location of a server. |
DNS is used to register a directory service
One important implication of LDAP using the DNS namespace is that by registering a DNS domain name to connect a host or zone of hosts to the Internet, you may inadvertently also register for a directory service namespace. There is a parallel in the e-mail delivery namespace with the MX record and many other network-based services. When I register an A record for mycompany.com with an authoritative DNS server, mycompany.com may become a valid directory service namespace. Most vendors currently expect that your LDAP directory has an A record for each directory server. Some vendors further expect that if you deploy a directory that is distributed across multiple directory servers, you will make each of the directory servers subordinate in the DNS namespace. So for example, if I distributed the mycompany.com directory, the directory servers might have A records of dir1.mycompany.com, dir2.mycompany.com, and so on.
LDAP is making increasing use of DNS for its namespace functionality
In addition to the informal expectations that have become practice, there has been some formal work with regard to the relationship between DNS and LDAP. RFC 2247 provides a clear standard for DNS to easily be incorporated into the namespace that LDAP uses within the directory. The domain component (dc) attribute is defined, and it can be used as a naming attribute in the directory for container objects. Within the IETF, there is other extensive work on using DNS to extend the LDAP namespace functionality. Draft documents include a proposal to use DNS SRV records for clients to locate an LDAP directory for a given namespace. This proposal has gained significant support, as Microsoft's directory implementation of it demonstrates. It will probably supplant the existing informal practice within a few years. Another proposal suggests using DNS SRV records with referrals. Chapter 5 discusses referrals.
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
The structure can make it easier to distribute information across multiple servers. A directory distributed across multiple servers in turn provides greater reliability and the possibility of locating directory information close to remote locations.
The structure can make management of access control simpler.
The structure can enable applications with specific directory requirements to be integrated into your directory.
The structure can simplify directory maintenance by grouping similar entries together.
The structure itself does not provide these benefits. For Mycompany to realize these benefits depends on its directory implementation and design of the namespace. How each of these benefits is provided is a topic in itself (see Chapter 5).
A namespace with a hierarchy of structure has other benefits
As noted in the postal example, organizing directory objects hierarchically provides an effective means for delegating management of the entries. To add entries, you would need some type of delegated authority in the appropriate place in the directory. The layer of management that is created by the existence of a structure helps to enforce consistent data in entries.
Containers enable structure
A hierarchy is possible in the LDAP directory because of container entries. Container entries are special entries that allow other entries to be placed hierarchically beneath them. An entry beneath a container is sometimes called a child of the container, or a subordinate entry to the container. The container is sometimes called the parent of the entries beneath it. You can also refer to the relationship between the container and entries beneath it by saying the entries are contained by the parent.
Only a specific kind of structure is allowed in LDAP
The namespace in an LDAP directory allows no arbitrary connections within the structure. Structures similar to the linked relationship between Web pages (in other words, a Web structure) are not allowed. More specifically, a container can have only a single parent directly above it. A container can have multiple child containers, but only a single parent. This type of structure is commonly called a tree structure. This term may remind you of the alternate term for namespace: directory information tree (DIT). Figures 2-2 and 2-3 show examples of valid and invalid namespace structures. The regulated approach to the structure leads to little service disruption when new entries are added, because only the new entry is written, and no existing entries must be modified.
With LDAP, any entry can become a container
You may assume that containers in an LDAP directory have an attribute that identifies the entry as a container. But this isn't the case. An entry becomes a container when entries are placed under it, but the LDAP directory makes no modification of the container entry when this happens. With LDAP, every entry holds the possibility of becoming a container, and this design supports many hierarchical opportunities.
You create a container by creating an entry below another entry
You might also assume that container entries have an attribute that lists all the entries that are contained within that container. This also isn't the case. The hierarchical structure is not stored by any special mechanisms aside from the name of each entry. You create a container by creating an entry beneath another entry! This concept takes some getting used to, as logic suggests that the container entry would need to be modified. However, specific LDAP implementations may go beyond the LDAP specification and have special attributes for child information in order to offer additional management functionality.
Although every entry can be a container, some object classes may make more sense
In some LDAP server implementations, there may be restrictions on which object classes an entry must have to become a container. These restrictions are called structure rules (for more details, see Chapter 4). In general, there are several object classes that are regularly used as containers for historical reasons. These object classes are favorites because they are the only allowed containers in X.500. Table 2-2 lists these object classes with a short description of each object class along with why they might be useful as a container.
Among these object classes, the organizational unit is used most widely. It is frequently employed for a wider variety of purposes than simply political structure. You don't have to use these object classes as the containers in your directory, but you may find that there are good reasons why these classes are favored.
Structure rules restrict where an entry of an object class can be created
LDAP also supports structure rules specific to an object class (for detail beyond what's here, see Chapter 4). This functionality is not necessarily part of the LDAP standard, but it is implemented by several vendors. Object class structure rules impose restrictions on where an entry of a particular object class may be created. For example, I might associate a structure rule with the organizational unit object class. This structure rule might require that all entries of objectclass=organizationalUnit be immediate children of entries of objectclass=organization. This rule imposes an additional restriction in the namespace, and it also limits functionality. Structure rules are enforced by the schema-checking process. Mycompany will want to review any structure rules specific to its chosen vendor.
Table 2-2. Common object classes used for containers
Object Class Type | Attribute Name | Explanation of Use |
|---|---|---|
Country | c | The country entry can provide geographical structure. As such, you typically use them when you want to split directory information across servers based on geography. |
Locale | l | The locality entry also provides geographical structure to subdivide the country container. |
Organization | o | The organization entry provides a political structure. |
Organizational Unit | ou | The organizational unit entry also provides a political structure. |
Naming contexts are used to refer to portions of a directory
The name of each top-level container has the distinction of also being called a naming context. The naming context is greater than just the container, though. A naming context is a contiguous subtree beginning at a top-level container. For example, if you referred to the Accounts naming context in Mycompany, you would mean the Accounts container, all its child entries, and all containers and entries beneath the Accounts container, as shown in Figure 2-4. In this way, you can conveniently refer to portions of the directory. The naming context is the same terminology as a directory suffix (or a context prefix in X.500). The Accounts naming context is the Accounts suffix.
The directory has no single root entry; instead, all the naming contexts are peers connected by the root DSE
There is really no directory object at the root of an LDAP directory. Instead, there is a special entry that is like a root object, called the root DSE entry, that lists all the naming contexts on the directory server. The directory uses the naming contexts to quickly differentiate whether a request for an entry is within the known naming contexts.
A flat namespace allows quick growth
In a directory with a flat structure, organization and management are typically disregarded, while adding new entries is increasingly easy. As you can see in Figure 2-5, the lack of structure encourages easy growth because there is only a single organizational container in use, with little to no restriction placed on additions. But in this model, consistency and scalability can become a nightmare. Scalability becomes an issue when generic queries regularly return large numbers of entries. Scalability can also be an issue when the number of useful unique names reaches its limit. This limit may be reached because only one entry in any particular container can be named with any specific name. A hierarchical model sidesteps these problems by organizing entries at multiple levels in the hierarchy.
There are four basic divisions of a directory namespace that are useful:
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.
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.
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.
User classification—. Dividing information based on users' needs. For example, you might separate information for managers from information for staff.
With a firm grasp on DNS and the acceptable structures allowed in an LDAP directory, you are ready to consider the internal details of the LDAP namespace. The namespace that LDAP employs is highly flexible, allowing for multiple names for each entry and the possibility that different attributes can be used in forming the name. The naming flexibility LDAP provides doesn't come at the cost of ensuring that each entry has a name that is unique across the directory.
The RDN is an entry's naming attribute; it has a unique value in the container of the entry
The relative distinguished name attribute provides a unique name identifier for each entry within a container. For example, Figure 2-6 shows a person entry with an RDN of cn=Brian Arkills. There cannot be two entries with the same RDN value within the same container. So there can be no other person entry in the People container with cn=Brian Arkills, and within any specific container the cn attribute value must be unique for subordinate person entries to that container. The RDN attribute is one of the entry's attributes, known as the naming attribute for that type of entry. But generally speaking, the naming attribute for any particular object class is not forced to be a specific attribute. In the object class definition, some LDAP vendors do force a specific attribute to be the naming attribute, but this is not part of the LDAP standard. In the example in Figure 2-6, the cn (common name) attribute is the naming attribute of the person object class.
You can substitute a unique string of numbers called an object identifier for the attribute type in an RDN
You can use a special string of numbers called an object identifier (OID) in place of the attribute type. Every attribute type has a unique OID assigned to it. For example, the cn attribute's OID is 2.5.4.3. The OID is used to uniquely identify an attribute type. For example, you might define an attribute type called myattribute. I might also define an attribute type called myattribute. How can we know if they are the same attribute? By comparing the OIDs of the two attributes. For more detail on OIDs, turn to Chapter 4; for now, you need to know that an OID can be substituted for the name of an attribute type. The OID is relevant to namespace when an OID is used as the naming attribute. For example, a valid RDN of the entry in Figure 2-6 is 2.5.4.3=Brian Arkills.
cnis frequently used in RDNs, but other types are possible
The cn attribute is the most commonly used naming attribute; however, there are several other attribute types that are commonly used (see Table 2-3).
You can use any attribute with a unique value in the RDN
You can form the RDN using any attribute type on the entry that has a unique value among the entries in that container. Although this rule may seem confusing, it allows the client more flexibility to identify an entry in an unexpected form. Generally speaking, the schema checker must ensure that each new entry or modification to an existing entry leaves the entry with at least one unique RDN, so the entry has a unique name. Some LDAP implementations do standardize the naming attribute for any given object class; and in this case, attributes that are designated as naming attributes must meet the uniqueness rule that the schema checker enforces. Either way, there is a guarantee that every entry has a name that is unique across the directory.
Table 2-3. Common attributes used as naming attributes
Attribute Type | Attribute Used For: |
|---|---|
cn | common name |
l | locality name |
st | state or province name |
o | organization name |
ou | organizational unit name |
c | country name |
street | street address |
dc | domain component |
uid | user identity |
You can also use more than one attribute in the RDN. This is called a multivalued RDN. This functionality lets you specify a unique entry with an intersection of two attribute values when one or both of the attribute values doesn't meet the uniqueness requirement. For example, consider the situation shown in Figure 2-7. There are two people with the same phone number, and two people with the same surname. You can't use either the phone number or the surname attribute to uniquely indicate Luke Skywalker's entry, but a combination of both attribute types will create a unique combination. The RDN would be sn=Skywalker+telephoneNumber=+1 222 222 2222. Of course, in this case you could more easily use cn=Luke Skywalker as the RDN; but there might be instances in which you do not know the cn value, so it would be more efficient to use the multivalued RDN. Not all vendor implementations fully support this functionality. Use it only with careful planning.
A DN provides a name for users to uniquely refer to each directory entry
The DN provides a fully qualified name to each entry, so it is clear exactly which entry is referenced, and also where in the hierarchical structure that entry is located. Under the LDAP specification, each entry does not store its DN, nor does the directory index the DNs of directory entries. Instead, a DN is primarily for the users of the directory to be able to indicate to the directory which entry is desired. A DN is presented by a client operation request, and the directory dynamically looks to see whether an entry matches this purported DN. Specific vendors may store the DN as an attribute of the entry or index all the DNs, but this is neither required nor expected.
The DN is a concatenation of the entry's RDN and the RDN of every container between the entry and the directory root
Forming a DN can be a bit tricky because the user must know the RDNs of all the containers above the entry. The DN is a string composed of the RDN of the entry concatenated with the RDN of the container of the entry concatenated with each RDN of every container above that container. Commas delimit each component. Here is a simpler, recursive definition of a DN: The DN is the string composed of the RDN of the entry concatenated with the DN of its container. As shown in Figure 2-7, the entry on the right has two possible DNs:
cn=Luke Skywalker,ou=People,dc=mycompany,dc=com
or:
sn=Skywalker+telephoneNumber=+1 222 222
2222,ou=People,dc=mycompany,dc=com
You should treat some special characters differently when they are used in a DN
You must treat several characters specially when they are used in a DN. You can store these special characters as naming attribute values without the escape character; but when referring to these characters in a DN, you must escape them. You specially notate these characters by preceding them with a backslash character () to avoid mistakes in meaning. This is sometimes called commenting or escaping. For example, designating a DN with an RDN that has a comma in its value would cause confusion because the directory uses commas in the DN to separate the DN components. Treat the characters listed in Table 2-4 specially by escaping them in DNs.
RFC 2253 makes it clear that vendors can make other characters special, so take care to examine vendor implementations for special cases.
When using a Web browser as an LDAP client, you should use a special naming format
Most Web browsers today support LDAP client functionality. As a result, you can perform searches conveniently via a browser. The naming format of the LDAP URL is fully specified in RFC 2255. This format is slightly different from that used by standard LDAP clients. URLs have a large set of special characters that must be treated in a special way as designated in RFC 1738, and the different format accommodates this. The LDAP URL-naming format is not exclusively used by Web browsers; standard LDAP clients must also be able to use it to support referrals.
How to use LDAP URL syntax
An LDAP URL begins with the protocol designation ldap://, followed by the hostname and port of the directory server, then the base DN and other designations, such as the scope, filter, and attributes desired. The syntax is
ldap://[hostname][/dn[?[attributes][?[scope]
[?[filter][?[extensions]]]]]
The components of the syntax are
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, andsubare possible values. If the value is left unspecified,subis 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
Given the sample directory shown in Figure 2-6, this search would return the sn attribute of the entry cn=Brian Arkills,ou=People,dc=mycompany,dc=com. The search has the subtree scope, but the entry at the specified base DN has no children, so only one entry is returned.
Special URL characters must be treated in a unique way
There are several illegal and special URL characters. These characters include the special characters noted earlier in this chapter as well as almost all nonalphanumeric characters (the notable exceptions include $-_.!*'()). You must escape these characters when you use them in an LDAP URL component. The escape method is fully described in RFC 1738, but it amounts to substituting the % character and the two-digit hexadecimal ASCII code for the character in question. Most browsers automatically translate illegal URL characters into the escaped version.
LDAP v3 must support all LDAP v2 naming conventions
In addition to the special naming syntax restrictions defined by the LDAP v3 standard, LDAP v3-compliant implementations must also support LDAP v2-compliant naming. LDAP v3 implementations can't generate LDAP v2-compliant names, but they must accept and process those names by translating the names to the LDAP v3-compliant standard. RFC 2253 Section 4 spells out this compatibility. There are distinct differences between the two versions. LDAP v2 differs from LDAP v3 on the following points of syntax:
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 text
OID. oroid. to prefix an OID attribute type string.
Again, an LDAP v3-compliant directory accepts all these differences in syntax, but it automatically translates them to the correct LDAP v3-compliant syntax for processing.
As LDAP has matured, extensions to the structural functionality have rapidly developed to reflect the distributed computing model. Certain structural features are needed to support a directory housed on multiple servers, greater directory reliability, integration with other directories, and localizing directory data on a geographical basis. Replication, referrals, and aliases are the advanced features used to enable this functionality. Some of these special features are part of the LDAP standard, while others are available only in certain vendor implementations. To explore further how to extend the LDAP namespace, see Chapter 5, which focuses on directory management.
The namespace provides the structure to store and find directory information
In summary, the namespace employed by LDAP directories follows an ordered hierarchical model. The preexisting DNS namespace at an organization is usually used to augment this model. The hierarchical model provides many advantages, but perhaps the most critical is that knowing the name of an entry tells you where the entry is located within the directory structure.