4 — Introduction to the DCE Directory Service

Figure 4-1 represents a hypothetical configuration of two cells that each use X.500 or an LDAP server to access names in the other cell. Names that are stored directly in X.500 or the LDAP Server also are accessible from each cell. CDS is the directory service within each cell. The same organization administers both cells, which are configured based on geographic location and network topology.

Figure 4-1: Cell and Global Naming Environments

DNS is a widely used existing global name service for which DCE offers support. Many networks currently use DNS primarily as a name service for Internet host names. Although DNS is not a part of the DCE technology offering, the directory service contains support for cells to interoperate through DNS.

The GDA is the DCE component that makes cell interoperation possible. The GDA enables CDS to access a name in another cell through one of the global naming environments (X.500, LDAP, or DNS), or through the CDS of the parent cell, if the cell is part of a hierarchical cell configuration. The GDA is an independent process that can exist on a system separate from a CDS server, although by default the DCE configuration script configures the GDA on the same machine as a CDS server. CDS needs to be able to contact at least one GDA to participate in the global naming environment.

Figure 4-2 shows how the GDA helps CDS access names outside of a cell. When CDS determines that a name is not in its own cell, it passes the name to a GDA, which searches the appropriate naming environment (CDS, X.500, LDAP, or DNS) for more information about the name. The GDA returns information that enables the original CDS server to contact the CDS server in whose cell the name resides. The GDA can help CDS find names in a cell that is registered in DNS (Scenario A), a cell that is registered in an X.500 or LDAP server (Scenario B), or a cell that is registered in the originating cell's parent cell (not shown). The GDA decides which name service to use based on the syntax of the name. Section 4.8.2 on page 58 describes name syntaxes in detail.

NOTE: The interface between the GDA and the X.500, GDS, or LDAP server is dependent on the type of server being used. The GDA uses the XDS/XOM API to interface with the GDS client. The GDS client uses the DAP protocol to interface with the X.500 Server. The GDA uses the LDAP API to interface with the LDAP client. The LDAP client uses the LDAP protocol to interface with the LDAP server.

Figure 4-2: Interaction of CDSs, GDAs, and Global Directory Services

4.5 How Cells Determine Naming Environments

In addition to delineating security and administrative boundaries for users and resources, cells determine the boundaries for sets of names. Because different naming components operate in a cell and outside of a cell, naming conventions in the cell and global environments differ as well. The DCE naming environment supports two kinds of names: global names and cell-relative, or local, names. The following subsections introduce the concept of global and local names. Section 4.8.2 on page 58 describes CDS, GDS, X.500, LDAP, and DNS names in detail.

4.5.1 Global Names

All entries in the DCE Directory Service have a global name that is universally meaningful and usable from anywhere in the DCE naming environment. The prefix /... indicates that a name is global. A global name can refer to an object within a cell (named in CDS) or an object outside of a cell (named in DNS), or an object outside of a cell (named in X.500).

The following example shows the global name for an entry in the X.500 namespace. The name represents user Ellie Bloggs, who works in the administrative organization unit of the Widget organization, a British corporation.

/.../C=GB/O=Widget/OU=Admin/CN=Ellie Bloggs

The X.500 name syntax consists of a global prefix /... and a set of elements, called relative distinguished names (RDNs). Each RDN consists of one or more pairs of parts separated by an = (equal sign) character. The items that are separated by an equal sign are multiple attribute value assertions (AVAs). See the OSF DCE GDS Administration Guide and Reference for more information about AVAs. The first part of a pair is an abbreviation that indicates a type of information. Some common abbreviations are Country (C), Organization (O), Organization Unit (OU), and Common Name (CN). The second part of the pair is a value. (See Section 4.9.1 on page 59 for more information on X.500 names.)

The following example shows a global name for a price database server named in CDS. The server is used by the Portland sales branch of XYZ Company, an organization in the United States.

Figure 4-3: Global Name in CDS

As the example illustrates, global names for entries that are created in CDS look slightly different from pure X.500 -style names. The first portion of the name, /.../C=US/O=XYZ/OU=Portland, is a global cell name that exists in an X.500 server or LDAP server. The remaining portion, /subsys/PriceMax/price_server1, is a CDS name.

The cell name exists because cells must have names to be accessible in the global naming environment. The GDA looks up the cell name in the process of helping CDS in one cell find a name in another cell. Cell names are established during initial configuration of the DCE components. Before configuring a cell that will participate in standard intercell communication (that is, the name is resolved via DNS, X.500, or LDAP server), the DCE administrator must obtain a unique cell name from either of the global naming environments, depending on whether the cell needs to be accessed through X.500 or DNS.

NOTE: The GDA transforms an X.500 cell name to the LDAP name syntax if using an LDAP server to access cell information.

The next example shows the global name of a host at ABC Corporation. The global name of the company's cell, /.../abc.com, exists in DNS.

Figure 4-4: Global Name Including a DNS Cell Name

4.5.2 Hierarchical Cell Names

In a hierarchy of cells, the names of one or more cells, called child cells, are registered in a cell's CDS; this cell is called the parent cell. The cell at the top of the hierarchy must be registered in a global directory service (X.500, LDAP, or DNS server), but the cells underneath do not need to be since they use CDS to communicate. A child has one and only one parent at any given time, while a parent can have more than one child.

The GDA is the communications gateway between the CDS namespaces of cells in a hierarchy, as it is between CDS and the global directory services. When the GDA receives a request for information about a cell, and the cell is a child cell, the GDA returns information about the CDS in the parent cell. The CDS of the parent cell provides the pointers to the child cell.

A child cell's name begins with the parent's global cell name; that is, the name of the cell beginning at the global root /... prefix. (This name is also known as the parent cell's fully qualified name.) It ends with the specific child cell name. The parent's global name can contain CDS syntax as well as X.500 or DNS syntax, depending on where the parent cell is located in the hierarchy.

The following example shows the global cell names of two child cells:

Figure 4-5: Global Names and Child Cells

The global cell name for each child includes:

The parent's global name, /.../C=US/O=XYZ/OU=Portland
The child's unique CDS name, /Sales1 or /Marketing

If a DCE administrator is establishing a hierarchy of cells during initial cell configuration, he or she must obtain a unique X.500 or DNS cell name for the cell at the top of the hierarchy from the X.500 or DNS global directory service authorities. All of the cells beneath this cell share this name. The OSF DCE Administration Guide—Introduction provides details on how to obtain X.500 and DNS cell names.

If a DCE administrator establishes a hierarchy of cells after the cells have been configured, the global names of the child cells change to point to the parent's cell name. The OSF DCE Administration Guide—Core Components provides details on how to establish a hierarchy of cells.

4.6 Alias Cell Names

You can give a cell more than one global name by creating an alias name for the cell. In this case, the cell has a primary name, which is the name that DCE services return for the cell when queried, and one or more cell aliases that the DCE services recognize in addition to the primary name. For example, if your cell is registered in the DNS global directory service, and you want to register it in X.500 as well, you obtain a X.500 name for the cell and set it up as a cell alias. The DNS name remains the primary name.

Chapter 6 of the OSF DCE Administration Guide—Core Components explains how to use the dcecp cellalias task object to manage your cell names. Chapter 21 of the OSF DCE Administration Guide—Core Components explains how to create a hierarchical cell.

4.7 Cell-Relative Naming in a Standalone Cell

In addition to their global names, all CDS entries have a cell-relative, or local, name that is meaningful and usable only from within the local cell where that entry exists. The local name is a shortened form of a global name, and thus is a more convenient way to refer to resources within a user's own cell. Local names have the following characteristics:

They do not include a global cell name.
They begin with the /.: prefix.

Local names do not include a global cell name because the /.: prefix indicates that the name being referred to is within the local cell. When CDS encounters a /.: prefix on a name, it automatically replaces the prefix with the local cell's name, forming the global name. CDS can handle both global and local names, but it is more convenient to use the local name when referring to a name in the local cell. For example, these names are equally valid when used within the cell named /.../C=US/O=XYZ/OU=Portland:

/.../C=US/O=XYZ/OU=Portland/subsys/PriceMax/price_server1

/.:/subsys/PriceMax/price_server1

The naming conventions required for the interaction of local and global directory services may at first seem confusing. In an environment where references to names outside of the local cell are necessary, the following simple guidelines can help make the conventions easy to remember and use:

Know your cell name.
Know whether a name that you are referring to is in your cell.
When using a name that is within your cell, you can omit the cell name and include the /.: prefix.
When using a name that is outside of your cell, enter its global syntax, including the /... prefix and the cell name.
When someone asks for the name of a resource in your cell, give its global name, including the /... prefix.
When storing a name in persistent storage (for example, in a shell script), use its global name, including the /... prefix. Local names (that is, names with a /.: prefix) are intended only for interactive use and should not be stored. (If a local name is referenced from within a foreign cell, the /.: prefix is resolved to the name of the foreign cell and the resulting name lookup either fails or produces the wrong name.)

4.8 Cell-Relative Naming in a Hierarchy of Cells

In a hierarchy of cells, cell-relative names and local names may not be the same. A parent cell can reference a name in a child cell by using cell-relative naming (/.:). Consequently, you can no longer determine whether a cell is in your local cell by merely looking at its name. In the following example, the child cell (eng) is named relative to its parent cell:

/.:/eng

This type of naming allows you to access names in a child cell (for example, /.:/eng/hosts/admin) from the parent cell, without having to specify the global name of the cell.

NOTE: When referencing names in a child cell from a parent cell, you should be mindful that your status is that of a foreign user. Therefore, the child cell may have access controls imposed on it that will deny you access to its namespace.

4.8.1 Local Filenames

When referring to pathnames of files in the local cell, you can shorten a local name even further by using the /: prefix. This prefix translates to the root of the cell file system. The default name of the file system root is /.:/fs, which is one level down from the root of the cell namespace. So, for example, the following are all valid ways to refer to the same file from within the /.../widget.com cell:

/.../widget.com/fs/smith/myfile
/.:/fs/smith/myfile
/:/smith/myfile

(See the OSF DCE DFS Administration Guide and Reference for more information on local file system abbreviations.)

4.8.2 An In-Depth Analysis of DCE Names

The rest of this chapter describes in depth the different kinds of names that make up the DCE namespace. The OSF DCE Administration Guide—Core Components and the OSF DCE GDS Administration Guide and Reference contain further details about valid characters and naming conventions in CDS, GDS, and DNS names.

4.9 CDS Names

Every cell contains at least one server that is running a CDS server. A CDS server stores and maintains names and handles requests to create, modify, and look up data. The total collection of names shared by CDS servers in a cell is called a cell namespace. The cell namespace administrator can organize CDS names into a hierarchical structure of directories. CDS directories, which are conceptually similar to the directories in your operating system's file system, are a logical way to group names for ease of management and use.

In a cell namespace, any directory that has a directory beneath it is considered the parent of the directory beneath it. Any directory that has a directory above it is considered a child of the directory above it. The top level of the cell namespace is called the cell root. You can refer to the cell root either by the global name of the cell or by the short-form /.: prefix.

Figure 4-6 shows a simple cell namespace hierarchy, starting at the cell root. The cell root (/.:) is the parent of the directories named /.:/hosts and /.:/subsys. The /.:/subsys directory is a child of the cell root directory and the parent of the /.:/subsys/dce directory.

Figure 4-6: Sample CDS Namespace Hierarchy

The complete specification of a CDS name, going left to right from the cell root to the entry being named, is called the full name. Each element within a full name is separated by a / (slash) and is called a simple name. For example, suppose the /.:/hosts directory, shown in Figure 4-6, contains an entry for a host whose simple name is bargle. The CDS full name of that entry is /.:/hosts/bargle. Multiple consecutive slashes are turned into a single slash in a full name.

Multiple directory levels enable flexibility in distributing, controlling access to, and managing many names. A directory hierarchy also reduces the probability of duplicate names. For example, the names /.:/subsys/Hypermax/printQ/server1 and /.:/subsys/ABC/spell/server1 are unique.

4.9.1 Names

The operation of X.500 is similar to that of CDS, but some important differences exist in the structure of names and the ways they can be looked up. Like CDS, X.500 and the LDAP Server have a server process that provides access to and management of names for X.500. This process is called a Directory System Agent (DSA). The combined knowledge of all DSAs that participate in the same global directory service implementation is called the Directory Information Base (DIB). This collective knowledge is viewed as a single global directory consisting of many entries.

Information exists in the X.500 global directory in the form of a rooted hierarchy that is called a directory information tree (DIT). The DIT is similar to a CDS namespace. However, unlike a namespace, which has no inherent rules regarding structure and content, the X.500 hierarchy is influenced by a set of rules that is called a schema. Every X.500 DSA must define a standard schema to which all of the entries in its portion of the DIB conform.

Although the X.500 standard does not mandate a specific schema, it does make general recommendations that are based largely on existing X.400 standards for electronic mail. For example, countries and organizations should be named close to the root of the DIT; people, applications, and devices should be named further down in the hierarchy. X.500 supplies a default schema that complies with these recommendations.

Every X.500 entry has a distinguished name, which uniquely and unambiguously identifies that entry. The distinguished name consists of a sequence of valid relative distinguished names (RDNs). Each RDN consists of one or more assertions of the type and value of an attribute at a particular position in the DIT. Attribute types indicate the nature of the information that is stored in the attribute value. A pair consisting of an attribute type and value is known as an attribute value assertion (AVA). RDNs can have multiple AVAs. For example, the distinguished name:

/C=us/O=osf/OU=branch1/CN=nollman,OU=doc-team

consists of four RDNs. The final RDN consists of two AVAs that are separated by a comma.

Figure 4-7 illustrates the concepts of RDNs and distinguished names and how they relate to the DIT. The figure shows the following:

A DIT consisting of a hierarchy of schema-defined attribute types
RDNs that result from assertions of an attribute type and value
Distinguished names that result from a concatenation of the RDNs

An X.500 name is understood by the GDA, and it contacts either an X.500 client (GDS) via the XDS/XOM API or an LDAP client via the LDAP API to resolve the X.500 cell name.

The LDAP server contacted by the LDAP client may be proprietary or could be an X.500 server that supports the LDAP access protocol. Therefore, you may need to contact the supplier of your LDAP server for this information.

Figure 4-7: RDNs and Distinguished Names

The shaded boxes in the DIT represent the entries that are named in the column labeled relative distinguished name. The schema dictates that countries are named directly below the root, followed by organizations, organization units, and names of users. Each attribute value that makes up an RDN (and thus a distinguished name) is called a distinguished value.

As the rightmost column in Figure 4-7 illustrates, the distinguished name of the entry at each level of the DIT is a concatenation of RDNs from the root of the global directory to that entry's level. The lowest entry in the hierarchy, /.../C=US/O=ABC/OU=Sales/CN=Smith, represents the name of a user, John Smith, who works in the sales division of ABC Company, an organization in the United States. The abbreviated attribute type labels stand for Country (C), Organization (O), Organization Unit (OU), and Common Name (CN).

Figure 4-7 shows the global DCE convention for distinguished names. Each distinguished name starts with the representation of the global root (/...). Attribute types and values are separated by equal signs, and RDNs are separated by slashes. These conventions for specifying names are not followed by all X.500 implementations. In addition, these conventions are only used at the X.500 administration interface level. Internally, distinguished names are specified in other ways.

The structure of X.500 names points out another important difference between X.500 and CDS. A CDS name is distinct from its attributes; that is, it consists of a string of directory names ending with the simple name of the entry. In contrast, a X.500 name consists solely of a series of attribute types and their values.

Figure 4-8 illustrates this difference in the construction of CDS and X.500 names. The CDS full name /.:/Admin/Personnel/Employee_DB is the complete directory specification of an entry with the simple name Employee_DB. Attributes and their values are not a part of the CDS full name. The X.500 distinguished name /.../C=US/O=ABC/OU=Sales is a concatenation of attribute types and values, one from each level of a DIT schema.

Figure 4-8: Comparison of CDS and X.500 Names

NOTE: The LDAP name /.../OU=Sales,O=ABC,C=US is not valid in DCE. The name must be specified as an X.500 distinguished name (/.../C=US/ O=ABC/OU=Sales).

X.500 supports the ability to search for names by supplying the values of one or more attributes. This results in what is called descriptive naming; in a sense, users can describe the name they are looking for. Although the search capability is valuable, it can be expensive and time consuming; so, X.500 allows users to restrict the scope of a search. Support for the search operation is limited to the X.500 environment.

4.9.2 LDAP Names

The LDAP name contains the same information as an X.500 name, but differs in its syntax. LDAP names start with the last RDN of an X.500 name and use a comma (,) instead of a slash (/) for RDN separators. The following example shows these differences:

X.500 name: /C=us/O=osf/OU=branch1/CN=nollman/OU=doc_team
LDAP name:  OU=doc_team,CN=nollman,OU=branch1,O=osf,C=us

DCE only supports X.500 cell names. GDA will convert an X.500 cell name to LDAP syntax when accessing an LDAP server via the LDAP client.

To make comments or ask for help, contact support@entegrity.com.

4 — Introduction to the DCE Directory Service

4.1 Overview of DCE Directory Service

4.2 How the DCE Components Use the DCE Directory Service

4.3 How to Use DCE Directory Services

4.4 Directory Services and the Cell Environment