Administration Guide

Concepts specific to DCE

This section provides some conceptual information regarding the distributed computing environment (DCE) security services. If you need more information, see Suggested reading for using DCE for references.

The DCE security services can be used in the SP environment for authentication by SP trusted services. AIX 4.3.1 and later releases provide AIX authenticated remote commands which support Kerberos V5 authentication. Kerberos V5 is an authentication method that you can use through a protocol provided by the DCE security services. Kerberos V5 can be used in the SP environment for authentication during AIX remote command processing.

Overview of DCE

DCE has established a standard in the client-server arena that is available on all IBM operating systems or platforms, such as AIX, OS/2, MVS, VM, and OS/400. It is also available on competitor platforms. DCE takes complete advantage of the client-server paradigm. It offers a set of services and APIs that you can use to build distributed applications and a set of management tools to manage the distributed environment. It can also interoperate with other environments. Some of the benefits provided by DCE are:

• DCE supports distributed applications.

  DCE provides a high-level, coherent environment for developing and running applications on a distributed system. DCE components fall into two categories; tools for developing distributed applications and services for running distributed applications.

  The tools, such as Remote Procedure Call and Threads, assist in the development of an application.

  The services, such as the Directory Service, Security Service, and Time Service, provide the services required in a distributed system. These are somewhat similar to some of the services that an operating system provides in a centralized system.

  The components and services provided for the application programmer and the system administrator perform many of the tasks that used to require their own code. With DCE, application programmers do not need to write explicit code that handles the network communications between machines or between distributed applications.

• DCE Services are integrated and comprehensive.

  In addition to providing all the tools and services needed for developing and running distributed applications, DCE components themselves are well integrated. Because many of the DCE components are themselves distributed applications, they use each other's services whenever possible. DCE not only supports the development of distributed applications, but also includes services that address some of the new problems inherent in the distributed system itself, such as data consistency and clock synchronization. DCE includes management tools for administering all of the services and many aspects of the distributed environment itself.

• DCE provides interoperability and portability across heterogeneous platforms.

  By design, DCE is oriented toward heterogeneous rather than homogeneous systems. The DCE architecture allows for different operating systems and hardware platforms. Using DCE, a process running on one workstation can interoperate with a process on a second workstation, even when the two have different hardware or operating systems. Therefore, DCE accommodates a wider range of networks, especially networks needing distributed computing for the historical reasons previously listed. Moreover, applications built using DCE are portable to other hardware or operating system platforms that run DCE.

• DCE supports data sharing.

  Another benefit is support of data sharing through the directory service and distributed file service. A user anywhere in the distributed system can share data by placing it in the name space or in a file, whichever is appropriate for the application. The data is then accessible by authorized users throughout the system.

• DCE participates in a global computing environment.

  DCE interacts with the outside world. In addition to supporting cooperation within and between systems, DCE systems can also interoperate with computing environments outside of DCE. In particular, the DCE Directory Service can interoperate with two standard, global directory services (X.500 and Domain Name Service), which allow users from within DCE to access information about the outside world. In this way, DCE participates in a global directory service. One benefit of such participation can be seen in the DCE distributed file system which looks like one global file system and users anywhere in the world can address the same file using the same global name.

DCE security services

Distributed computing encourages a free flow of data between nodes, thereby expanding the capabilities of interconnectivity and interoperability. The DCE Security Service is a building block of the DCE core services based on Kerberos technology that provides secure authentication, authorization, and auditing mechanisms for users and distributed client-server applications. For data encryption, DCE uses either Data Encryption Standard (DES) or the Common Data Masking Facility (CDMF). CDMF works with a 40-bit encryption key in contrast to the 52-bit DES key. CDMF is allowed to be exported from the USA, whereas DES underlies certain export restrictions.

Developers can use DCE Security Service to make their distributed client-server applications or products secure. Most of the DCE security is related to the concept of a principal. A principal is an entity that can be authenticated and can engage in trusted communication. A principal usually represents a user, a network service, a particular host, or a cell. The services that make up the security component are:

• Registry Service (RS) -- a replicated service that maintains the cell's security database. This database contains entries for accounts, principals, groups, organizations, and administrative policies.
• Authentication Service (AS) -- used to verify the identify of principals. It contains a ticket-granting service that grants tickets to these principals and services so they can engage in secure communication.
• Privilege Service (PS) -- certifies a principal's credentials that are going to be forwarded in a secure way to DCE servers. The credentials allow the target server to check the principal's access rights to resources.

DCE entities used by SP security services

For most SP trusted services, access control is based on membership in DCE groups. To manage access, the DCE security administrator adds or removes principal names from each group. The DCE entities used by SP security services are provided by default but can be locally overridden in your installation.

Note:

If local overrides have been made to any DCE entities, be sure to use the names locally placed in the spsec_overrides file in place of the corresponding default names used in this book.

Understanding access groups for SP trusted services

The SP security services configuration files define these SP DCE groups using default names that you can override. There are three types of groups, each with a different purpose:

1. A control group.

   This group controls access to the ACL of all SP security objects. It is used by services that manage DCE ACLs, which are currently the SP system monitor (hardmon) and Sysctl. It is also needed to create the key file for Topology Services. The default name is spsec_admin. During SP configuration processing to set up DCE, the principal name cell_admin is automatically added to the spsec_admin group. As an authorized administrator using the cell_admin principal, you can add more principals to this group for others who are to be security administrators for SP objects. You can also add more group entries to SP ACLs. Do not change any automatically generated ACL entries.

   There is an SP ACL management component of PSSP. Your interface to SP ACL management includes the spacl command and the spauth_spacl SMIT fast path.

2. A user access group.

   User access groups give their members access to SP security objects, allowing members to perform administrative tasks using commands or graphical user interfaces. Some user access groups are defined by default. These groups generally have no members by default, though some might. As the security administrator, you add user principals as members of user access groups according to the security policy of your organization. You can add, change, or delete principals as members, using the standard DCE interface for those actions whenever you need to.

   For a list of each group and its purpose, see Table 2.

3. A service access group.

   Members of groups of this type are SP trusted services which are given access to other SP trusted services and their objects. Members are principals that are created by default for and managed by SP trusted services. Administrators are not to change, add, or delete service access group or principal names.

Understanding the naming convention for access groups

SP trusted services generally implement access controls by granting privileges to one or more groups when using DCE authentication. These access groups are created at configuration time as defined at installation time by the spsec_defaults and spsec_overrides files. There is no pre-defined format for group names.

Understanding the naming convention for principals

Within the local cell, a server that has a separate instance for each SP system partition uses a principal name of the form:

principal = package/partition/service

Within the local cell, a server that has a single instance uses a principal name of the form:

package/DCEhostname/service

where:

principal is the derived principal name.

package is the name of the installed software component. It is the first element, like ssp, ppe, and rsct, from the SERVICE entries in the /spdata/sys1/spec/spsec_overrides file.

partition is the syspar name by which an SP system partition is known.

DCEhostname is the name assigned when DCE was installed and configured on the server host.

service is the second element, such as sdr, hardmon, and hats, from the SERVICE entries in the /spdata/sys1/spec/spsec_overrides file.

For example, ssp/part4/sdr would be the principal name used by the instance of the sdr server in the SP system partition named part4 which was installed from the ssp package. The principal name LoadL/master.xyz.org/Schedd is an example of one used by the Schedd server, installed from the LoadL file set, that serves all system partitions from a host with the DCE host name master.xyz.org.

Understanding the naming convention for Keytab objects and files

Keytab objects and files are created using the create_keyfiles command. They are used by daemons and service clients to log in to DCE. The name of a given object and file is the same as that of the service principal for which it is created. The name is derived from the principal name used by the service. The path name for a keytab file is derived using the /spdata/sys1/keyfile/principal. For example, the previous example sdr server would use the /spdata/sys1/keyfile/ssp/part4/sdr keytab file.

Keytab files can also be created by users in order to run jobs such as cron which use trusted service client interfaces from scripts running in the background. This kind of keytab file contains the user's key, the encrypted DCE password, rather than the key for a service principal. The user's background script specifies the file when invoking the dsrvtgt command. This keytab file can have any path name but it must be accessible only by the owner of the UID running the command and the client interfaces.

Understanding the naming convention for CDS paths

Entries in the Cell Directory Service (CDS) database are required for servers that use DCE ACLs to locate the servers that own objects protected by ACLs. The CDS is a tree-structured database with directory objects for branches and rpcentry objects for leaf nodes. The CDS path to a server will have the form:

/.:/subsys/principal

where

principal is the principal name derived as previously described and used by the server.

In the CDS naming convention /.:/subsys/package and /.:/subsys/package/DCEhostname are names of directory objects. Each server (ACL manager) is represented by an rpcentry object with a path name like /.:/subsys/package/DCEhostname/service.

To an administrator using DCE ACL management interfaces, each object (and its ACL) is known by a CDS path name that consists of the local cell, the subsystem path for the particular server instance, and the residual name of the object. The residual name is all that is used by the server locally in its ACL database operations. To illustrate DCE object naming, consider a frame object owned by the hardware monitor running on the control workstation with the DCE hostname cws3.xyz.com. To derive the CDS path name, the following happens:

• The hardware monitor daemon creates the object frame2/slot1 which is the residual name.
• When manipulating the ACL for the object, an administrator (member of the spsec-admin group) uses either the SMIT or the command-line interface. Those interfaces access the object through the CDS path name /.:/subsys/ssp/cws3.xyz.com/hardmon/frame2/slot1 for this example.

Suggested reading for using DCE

You can find these and other DCE publications from the Web address http://www-4.ibm.com/software/network/dce/library

• IBM DCE Version 3.1 for AIX: Release Notes contains last minute information that could not be included in other documents
• IBM DCE Version 3.1 for AIX: Quick Beginnings describes DCE and explains how to plan for, install, and configure the product.
• IBM DCE Version 3.1 for AIX: Introduction to Distributed Computing Environment provides an overview of DCE and serves as an introduction to the rest of the DCE documentation. It also contains a glossary of terms used in the DCE documentation.
• IBM DCE Version 3.1 for AIX: Administration Guide-Introduction provides conceptual and task-oriented information for the DCE administrator. The first part is an introduction to DCE administration. The second part explains configuring and starting up DCE.
• IBM DCE Version 3.1 for AIX: Administration Guide-Core Components provides concepts and procedures. Describes the core components of DCE and how to use them.
• DCE Version 3.1 for AIX: Administration Commands Reference provides reference material for DCE commands, including administrative commands.
• DCE Version 3.1 for AIX: Problem Determination Guide lists error messages and recovery actions along with administrative tips.
• IBM DCE Version 3.1 for AIX: Application Development Guide-Introduction and Style Guide provides information for the distributed application programmer. It provides conceptual and task-oriented information for developing an application using DCE and describes programming with DCE in general, using various components and facilities.
• IBM DCE Version 3.1 for AIX: Application Development Guide-Core Components describes the APIs for the various DCE components.
• IBM DCE Version 3.1 for AIX: Application Development Guide-Directory Services describes the DCE naming and access to CDS through XDS, the use of the X/Open Directory Service Interface, and the Object Classification Tables and other information on XDS, X500 Directory, and GDS objects.
• IBM DCE Version 3.1 for AIX: Application Development Reference provides reference material for the DCE programming interfaces and has command references for commands needed by the DCE programmer.