DSS Directory Services

by Joe Lucas

This article introduces you to Directory Services, the distributed resource locator for IBM Directory and Security Server (DSS). DSS is one of the IBM Software Servers described in the "Go Cross Platform With the Developer Connection" article on page 1. It adds features to IBM OS/2 Warp Server that let your file and print applications participate in the Open Software Foundation (OSF) Distributed Computing Environment (DCE).

In addition to this article, you might want to review Distributed Computing Environment: Understanding the Concepts. You can open it online with the browser on the DevCon for LAN Systems CD-ROM. It is located in the "DCE Library Folder," which is inside "Product Documentation" under "LAN Systems References".

Directory Services uses the DCE Cell Directory Service (CDS) to let your DSS and DCE client applications locate distributed resources and services in a DCE or DSS network. Directory Services uses CDS to store LAN Server or OS/2 Warp Server alias and public application definitions, replacing the LAN Server 4.0 domain control database (DCDB) as the master directory database.

The DSS Cell

The cell is the basic DSS administrative unit. You can compare it to an OS/2 LAN Server domain, except the DSS cell is much larger in scope and capacity. While an OS/2 LAN Server domain defines all of the resources and users for a single workgroup, a DSS cell defines all of the resources and users for a line of business, a region, or an entire company.

DSS Directory Server

In a distributed network, client applications must be able to locate servers, resources, and services no matter where they exist in the cell. Directory servers allow them to do that. The directory server contains a CDS database of definitions for all the resources and services in the cell. When your application asks to use a resource or service, the directory server provides the location.

In DSS, Directory Services integrates the LAN Server DCDB into the CDS database, adding CDS containers for file, print, and serial device aliases, as well as public application definitions.

When an administrator converts an existing LAN Server to DSS, many LAN Server domains can be integrated into a single DSS cell. Once this is done, client applications can seamlessly access any resource in any domain in the cell, as long as the user has the correct authorization.

This is possible because users are defined in the DSS cell registry only once.

DSS Resource Domains

DSS partitions its use of the CDS directory database into units called resource domains. Resource domains are a way to partition cell resources and their management, with the following benefits:

• Ease of migration - when multiple LAN Server domains are migrated into a DSS cell, LAN Server client and server applications have the same view of their domain's resources as before migration.
• Compatibility - applications written for LAN Server can use the same programming interfaces to locate resources within the client workstation's resource domain.
• Distributed administration - administrative authority can be defined separately for each resource domain.
• Hierarchical administration - a resource domain can be created as a child of another resource domain,so that administrators of the parent resource domain may give themselves or anyone else administrative privilege to a child resource domain.

DSS Resource Domain Structure

Figure 1 shows how DSS uses the DCE CDS hierarchical namespace to implement the directory structure of resource domains.

Figure 1. Resource Domain Directory Service Structure

Figure 2 shows the DSS registry structure used to support the resource domain administration model. DSS creates a predefined set of groups in its registry for each defined resource domain.

Figure 2. Resource Domain DSS Registry Structure

DSS administrators and users do not need to know these structures. The DSS interfaces described in the following section allow users and administrators to locate and manage resources.

DSS Resource Domain Interfaces

You can use or administer resources in a DSS cell much as you would in multiple LAN Server domains, except there is no longer a need to keep user IDs and passwords consistent across domains.

You need the following elements to address DSS directory resources:

• DSS cell - the basic DSS administrative unit. When you access resources in foreign cells (cells other than your own local cell), you must specify the cell name. You do not need to specify the cell name if you are working with resources in your local cell.
• DSS resource domain - A defined set of resources, similar to the domain in LAN Server. You must specify the resource domain||namewhenyouaccessresourcedomainsoutsideyourdefaultresourcedomain. The default resource domain is a required attribute in each DSS user account.
• DSS alias and application definitions - names of individual resources. These are compatible with those of LAN Server, so that LAN Server, OS/2 Warp Server, and DSS resources can all be used within a resource domain. Your existing applications' LAN Server interfaces can be used unchanged to access and manage resource definitions within the default resource domain.

DSS Resource Name Formats

As with LAN Server, applications and command-line-interface (CLI) commands must use the correct format and syntax of server and resource names to successfully locate DSS resources. DSS supports the following resource name formats:

• Simple resource name (alias or application name) - identifies a specific resource definition. You can use this name alone when accessing resources from the user's default resource domain.
• Resourcedomainname - identifies the resource domain of the requested resource. It is required when accessing resources of resource domains other than the user default resource domain. For command line requests, such as NET ALIAS and NET APP, the resource domain name is specified with the /DOMAIN switch.
• Cell name - identifies the cell of the requested resource. The cell name is required only when accessing resources of cells other than the local cell. The /CELL switch is used to specify a cell name.
• Extended resource name - lets you use one entry to identify the simple name, resource domain name, and, if needed, the cell name of a resource. This allows lists of resources, such as user logon assignments or application resource lists, to specify alias resource definitions that exist in different resource domains.

  The format of an extended resource name is: resourcename@resourcedomainname@cellname where resourcename is the simple resource name, @ is the required element separator, resourcedomainname is the resource domain name, and cellname is the name of the cell where the resource exists (needed only for foreign cell access). Note that the DCE cell prefix (/.../) must precede the cell name.

• Globalname - DSS supports a full resource specification starting with the CDS root. As with filesystems, these names can be lengthy and cumbersome. For example, the following name would be used to refer to a DSS file alias named FALIAS1 in the resdom1 resource domain: /.:/resources/realms/resdom1/files/FALIAS1

Global Directory Service

DSS directory database access is not limited to a cell. Cross-cell access is supported if you use a global directory server such as Domain Name Service or X.500 to join multiple cell namespaces into a single global namespace. Using DCE foreign cell authentication and access control, integrated DSS clients will have access to resources of other DSS cells.

Distributed or Replicated Directory Database

The DSS directory database can be distributed by partitioning the hierarchical namespace so that each partition's master copy is kept on a separate directory server machine. For a large multi-domain cell, resource domains can be distributed so that each directory server serves local users. Even if the local directory server contains only a single resource domain, clients can still access other directory servers' resources as needed.

The DSS directory database can be replicated. That is, multiple directory servers can contain copies of a cell's directory database. This improves performance for cells with many concurrent users.

Migrating OS/2 LAN Server to DSS

DSS provides utilities to migrate LAN Server resource definitions to the DSS directory.

Because LAN Server domains are each migrated into a separate DSS resource domain, alias and application resource names remain unique. So multiple LAN Server domains can be migrated into a cell without name conflicts.

In LAN Server, certain user-specific attributes and resource definitions (such as logon assignments, application selector lists, and private application definitions) are stored in the DCDB USERS subdirectory. DSS migrates these as extended registry attributes into the user object of the DSS Registry database, but the new location for these items is transparent, and does not affect application or user interfaces.

DSS Interoperability

DSS cells can support a mixture of DSS clients and servers along with LAN Server or OS/2 Warp Server clients and servers.

In this heterogeneous environment, the LAN Server clients and additional servers use the existing LAN Server protocols, which do not recognize DSS Directory Services. To give the LAN Server or OS/2 Warp Server clients the same consistent view of the DSS resource domain as a DSS client, DSS synchronizes the LAN Server DCDB with the DSS directory server on the DSS domain controller. A directory synchronization service (DIRSYNC), running on the DSS domain controller, propagates all DSS directory database updates made to the resource domain in which the domain controller is defined.

Several types of clients can be used with DSS. Existing LAN Server clients can be used unchanged (although, in general, these clients cannot be used to administer DSS directory resources). LAN Server clients with appropriate access control rights can access resources anywhere in the cell. In addition, these clients can still be used to access resources of LAN Server or OS/2 Warp Server domains that are not part of the DSS cell.

DSS clients can access not only DSS server resources, but also additional servers and domain controllers in existing LAN Server domains. DSS clients can also administer LAN Server domains.

Resource Domain Maintenance Utilities

DSS provides the following utilities to maintain and administer resource domains:

• RESDOMMG can be used to merge an existing resource domain and its resources with another resource domain.
• RESDOMMV can be used t omove a resource domain and its children to a different location in the hierarchical administrative structure.
• DSSFIXUP can be used to check a resource domain for inconsistencies and optionally fix problems it discovers.
• SRVCHG can be used to move a DSS server from one resource domain to another.

Summary

This article has introduced you to some key concepts of DSS Directory Services that your client applications can use to participate in large open technology networks. DSS for OS/2 Warp Server will be available later this year. For more information about this and other features of IBM's cross-platform development strategy, see "Go Cross Platform With the Developer Connection" on page 1.

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation