4 — Introduction to the DCE Directory Service

[Previous] [Next] [Contents] [Index]

4.1 Overview of DCE Directory Service

Distributed processing involves the interaction of multiple systems to do work that is done on one system in a traditional computing environment. One challenge resulting from this network-wide working environment is the need for a universally consistent way to identify and locate people and resources anywhere in the network.

The DCE Directory Service makes it possible to contact people and to use resources such as disks, print queues, and servers anywhere in the network without knowing their physical location. The directory service is much like a telephone directory assistance service that provides a phone number when given a person's name. Given the unique name of a person, server, or resource, it can return the network address and other information associated with that name.

The DCE Directory Service stores addresses and other relevant information as attributes of the name. For example, attributes can contain the name of an organizational unit, such as European Sales; a location, such as the first floor of Building A; or a telephone number. Users can search for a name by supplying one or more of its attributes. For example, given the search criteria of John Smith and Chicago, the directory service could produce a list of telephone numbers for users in Chicago named John Smith.

NOTE: Search capabilities are currently limited to the global part of the DCE Directory Service environment.

4.2 How the DCE Components Use the DCE Directory Service

The DCE Directory Service is a fundamental service that applications can rely on and use to their advantage. This section describes how other DCE components use the DCE Directory Service.

The DCE remote procedure call (RPC) interface facilitates the development and use of distributed applications that follow a client/server model. In the RPC model, clients are programs that make remote procedure calls, and servers are programs that carry out the procedures. The DCE RPC software stores information in the directory service about the addresses of RPC servers and the interfaces they support.

When an RPC client wants to make a call to a particular server, it can query the directory service for the information necessary to contact that server. If the client wants to access a specific resource that is named in the directory service, it can query for that specific name. If a client application knows the type of service that it wants, such as C compilers, printers, or employee information, but does not know the address of a specific server, it can also use the directory service to find that information.

The DCE Security Service, which verifies the identity of users when they log in, uses the directory service to store the addresses of its authentication servers.

The Distributed File Service (DFS) provides a location service for filesets (logical groups of files) so that users can access remote files as if they are on the local system. DFS uses the DCE Directory Service to find out how to contact its fileset location servers.

The Distributed Time Service (DTS) is responsible for synchronizing system clocks in the network. Synchronized clocks are important to any distributed application that needs to keep track of the order in which events occur across multiple systems. DTS uses the DCE Directory Service to find out how to locate its time servers.

4.3 How to Use DCE Directory Services

Other than DCE administrators, the people who use directory services normally do so indirectly, through an application interface. An application can interact with the directory service on behalf of users who create a name for a resource and subsequently refer to it by that name.

The following examples, both real and hypothetical, explain some of the ways that users can use the directory service:

The remainder of this chapter explains how the DCE Directory Service environment works with regard to cells. It introduces the main directory service components: the Cell Directory Service (CDS), the Global Directory Service (GDS), and the Global Directory Agent (GDA), which is a gateway between the local and global naming environments. The chapter also discusses DCE support for the Domain Name System (DNS) and LDAP Server, which are global name services that are not parts of the DCE technology offering.

4.4 Directory Services and the Cell Environment

This section introduces the following main components of the DCE naming environment and explains their relationship to the cell:

CDS is a high-performance distributed service that provides a consistent, location-independent method for naming and using resources inside a cell (intracell). CDS can also be used for communication between cells (intercell) when cells are connected into a hierarchy.

GDS supports the global naming environment inside cells (intracell) and outside of cells (intercell). GDS is an implementation of a directory service standard known as X.500. This standard is specified by the International Organization for Standardization (ISO) 9594 and the International Telegraph and Telephone Consultative Committee (CCITT) X.500 series. Because it is based on a worldwide standard, GDS offers the opportunity for a universally interoperable global directory.

The X.500 server is a server that will accept the directory access protocol (DAP) from an X.500 client to access objects in its directory. In DCE, the server is the GDS server and the client is the GDS client. The GDA communicates with the GDS client via the XDS/XOM API. The GDS client and server are based on the 1988 X.500 standard.

The LDAP client is a client that is implemented in two libraries, libldap.a and liblber.a and they are shipped with DCE. The client is based on the University of Michigan 3.3 source code. The LDAP client accepts the LDAP API from the GDA and communicates with the LDAP server via the LDAP protocol.

The LDAP server is a server that will accept the LDAP protocol from an LDAP client to access objects in its directory. The LDAP server may be an X.500 server that also accepts the LDAP protocol or any proprietary directory service that accepts the LDAP protocol. The LDAP server is not provided by DCE and must be provided by the user. The GDA communicates with the LDAP client via the LDAP API.

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:

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:

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:



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:

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:


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:


(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:


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:

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.

4.9.3 DNS Names

The DCE naming environment supports the version of DNS that is based on Internet Request for Comments (RFC) 1034 and RFC 1035. Many networks currently use DNS primarily as a name service for host names. The most commonly used implementation of DNS is the Berkeley Internet Naming Domain (BIND). The BIND namespace is a hierarchical tree with its topmost levels under the control of the Network Information Center (NIC). (See the OSF DCE Administration Guide—Introduction for information on how to contact the NIC Domain Registrar to register a domain name.)

The names directly under the root of the BIND namespace include 2-letter codes for countries, such as us and gb, as defined in ISO Standard 3166, "Codes for the Representation of Names of Countries." Other names one level below the root include several generic administrative categories, such as com (commercial), edu (educational), gov (government), and org (other organizations). The owners of these names can grant permission to companies and organizations to create new subordinate names. Figure 4-9 shows a sample portion of the BIND namespace. (The double quotes indicate that the root of the namespace has a null name and is not addressable.)

NOTE: Like CDS names, DNS names are not typed; that is, they do not consist of pairs of attribute types and values.

Figure 4-9: Sample Portion of the BIND Namespace

A DNS name consists of a string of hierarchical names that are separated by . (dots) and arranged right to left from the root of the namespace. For example, the name ai.mit.edu represents the branch of the namespace owned by the Massachusetts Institute of Technology artificial intelligence department.

NOTE: The order of elements in the name is the reverse of the order for CDS and GDS names.

To use a DNS cell name as part of a global DCE name, specify the DNS name intact between two slashes. For example, a cell whose DNS name is ai.mit.edu might contain a directory whose CDS name is /.:/profiles. Users should enter /.../ai.mit.edu/profiles to refer to the directory by its global name.

4.9.4 Names Outside of the DCE Directory Service

Not all DCE names are stored directly in the DCE Directory Service. Some services connect into the cell namespace by means of specialized CDS entries called junctions. A junction entry contains binding information that enables a client to connect to a server outside of the directory service.

For example, the security service keeps a database of principals (users and servers) and information about them, such as their passwords. The default name of the security service junction is /.:/sec.

The following example illustrates the parts of a global DCE principal name:

Figure 4-10: Global DCE Principal Name

The cell name, /.../C=US/O=ABC/OU=west, is a GDSan X.500 name. The sec portion is the junction entry in CDS, and principals/mozart is a principal name that is stored in the security service database.

Another service that uses junctions is DFS. The DFS fileset location service keeps a database that maps DFS filesets to the servers where they reside. The junction to this database has a default name of /.:/fs. The following example illustrates the parts of a global DCE filename:

Figure 4-11: Global DCE Filename

The global name contains a DNS cell name, /.../ai.mit.edu. The fs portion is the file system junction entry in CDS, and /users/mozart/myfile is the name of a file.

Thus, the DCE namespace is a connected tree of many kinds of names from many different sources. The GDA component of the directory service provides connections out of the cell and to other cells through a global namespace, such as GDS or X.500 or DNS. In a similar manner, junctions enable connections downward from the cell namespace to other services.

[Previous] [Next] [Contents] [Index]

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

Copyright © 2001 Entegrity Solutions Corporation & its subsidiaries.

Copyright © 1998-2001 Compaq Computer Corporation.

All rights reserved.