Entegrity DCE and DFS for HP Tru64 UNIX
Installation and Configuration Guide

Software Version 4.3.1

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

2.1 Overview of the DCE Cell

A cell is the basic DCE unit. It is a group of networked systems and resources that share common DCE services. Usually, the systems in a cell are in the same geographic area, but cell boundaries are not limited by geography. A cell can contain from one to several thousand systems. The boundaries of a cell are typically determined by its purpose, as well as by security, administrative, and performance considerations.

A DCE cell is a group of systems that share a namespace under a common administration. The configuration procedure allows you to configure your system as a DCE client, create a new DCE cell, add a master Cell Directory Service (CDS) server, add a replica CDS server, and add a Distributed Time Service (DTS) local server. When you create a new cell, you automatically configure a Security server.

You do not need to create a DCE cell if you are using only the DCE Remote Procedure Call (RPC) and if your applications use only explicit RPC string bindings to provide the binding information that connects server to clients.

If there are other systems in your network already using DCE services, it is possible there may be an existing cell that your system can join. If you are not sure, consult with your network administrator to find out which DCE services may already be in use in your network.

At a minimum, a cell configuration includes the DCE Cell Directory Service, the DCE Security Service, and the DCE Distributed Time Service. One system in the cell must provide a DCE Directory Service server to store the cell namespace database. You can choose to install both the Cell Directory server and the Security server on the system from which you invoked the procedure, or you can split the two servers and put them on different systems.

NOTE: You must run the installation and configuration procedures on the system where you are creating a cell before you install and configure DCE on the systems that are joining that cell.

2.1.1 TruCluster, Sierra Cluster and Cells

Compaq's Tru Cluster and Sierra Cluster run on Compaq's Tru64 UNIX v5.1.Though there were versions of TruCluster for 5.0 and 5.0a, Entegrity began using and supporting v5.1.

A cluster is a group of up to 32 machines that work together based on the TruCluster's "Memory Channel" interconnect. A Sierra Cluster connects up to 128 machines using a "Qswitch". On both, the member machines share the Cluster File System (CFS). On Sierra Clusters, members share the Parallel File System (PFS) as well.

Clusters and cells connect computers for different reasons. A cluster is a group of computers that share disk and memory subsystems and appear to the outside world as one computer. Unlike DCE clients, cluster members need to be on similar machines from the same manufacturer. A DCE cell is a group of computers that uses a network to communicate in a secure manner to eachother.

All machines in one cluster are configured to the same DCE cell.

Entegrity's version 4.1 is designed to work with clusters:

• Several directories and files need to be member-specific on a TruCluster installation. The following need to be member-specific:

  /opt/dcelocal
  /krb5
  /etc/sia
  /etc/krb5.conf
  

  The installation scripts generate Context Dependent Sensitive Links. These CDSLs are symbolic pointers, indicating a member specific configuration in a cluster. Each member (or node or machine) is a DCE client, so in a cluster directory there are member specific pointers.

• V4.1 supports generating forward credentials for DCE-enabled SIA, to provide consistent credentials between cluster members.

• Configuration scripts, dcesetup and dfssetup, are cluster aware.

  The scripts allow for one time DCE client configuration of all cluster members, as DCE clients using the same configuration information.

  For Sierra Clusters, only cluster members that share the same sub-cluster and CFS file system can be configured at the same time. One will have to run dcesetup for each of the subclusters.

2.1.2 Creating a Cell

All DCE systems participate in a cell. If you are installing DCE and there is no cell to join, the first system on which you install the software is also the system on which you create the cell. Remember that this system is also the DCE Security server. You can also make this system your Cell Directory server.

When you create a cell, you must name it. The cell name must be unique across your global network. The name is used by all cell members to indicate the cell in which they participate. The configuration procedure provides a default name that is unique and is easy to remember. If you choose a name other than the default, the name must be unique. If you want to ensure that separate cells can communicate, the cell name must follow BIND or X.500 naming conventions.

2.1.3 Joining a Cell

Once the first DCE system is installed and configured and a cell is created, you can install and configure the systems that join that cell. During configuration, you need the name of the cell you are joining. Ask your network administrator for the cell name.

2.1.4 Defining a Cell Name

You need to define a name for your DCE cell that is unique in your global network and is the same on all systems that participate in this cell. The DCE naming environment supports two kinds of names: global names and local 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. All Directory Service entries also have a cell-relative name that is meaningful and usable only from within the cell in which that entry exists.

If you plan to connect this cell to other DCE cells in your network either now or in the future, it is important that you choose an appropriate name for this cell. You cannot change the name of the cell once the cell has been created. If you are not sure how to choose an appropriate name for your DCE cell, consult the section on global names in the OSF DCE Administration Guide — Introduction.

Before you can register the cell in X.500, you must ensure that the DIGITAL X.500 Base kit and the DIGITAL X.500 API kit is installed on your CDS server. It is also recommended X.500 administration subset (DXDADXIM) be installed. Optionally, you can install the DIGITAL X.500 Administration Facility kit for debugging and general administrative support.

Entegrity recommends that you use the following convention to create DCE cell names: the Internet name of your host system followed by the suffix _cell, and then followed by the Internet address of your organization. For example, if the Internet name of your system is myhost, and the internet address of your organization is smallco.bigcompany.com, your cell name, in DCE name syntax, would be myhost_cell.smallco.bigcompany.com. This convention has the following benefits:

• The Internet name of your host is unique in your network, so if this convention is followed by all DCE users in your network, your cell name will also be unique.

• It clearly identifies the system on which the writable copy of the root directory of the cell namespace is located.

• It does not prohibit intercell communication with outside organizations.

• It is easy to remember.

If there is already a cell name defined in a previously existing DCE system configuration, do not change it unless you are removing this system from the cell in which it is currently a member and you are joining a different cell.

When the configuration procedure prompts you for the name of your DCE cell, type the cell name without the /.../ prefix; the prefix is added automatically. For example, if the full global name selected for the cell, in DCE name syntax, is /.../myhost_cell.smallco.bigcompany.com, enter myhost_cell.smallco.bigcompany.com.

2.1.5 Defining a Hostname

You need to define a name for your system that is unique within your DCE cell. You should use the default hostname, which is the Internet hostname (the name specified before the first dot (.)).

The following example shows the default hostname derived from the Internet name of myhost.mycompany.com.

Please enter your DCE host name [myhost]: 

This section provides tips on defining a cell name in the Domain Name System (DNS). Names in DNS are associated with one or more data structures called resource records. The resource records define cells and are stored in a data file, called /etc/namedb/hosts.db. The data file is used by the BIND name daemon (named). To create a cell entry, you must edit the data file and create two resource records for each CDS server that maintains a replica of the cell namespace root.

The following example shows a cell called ruby_cell.axpnio.dec.com. The cell belongs to the BIND domain axpnio.dec.com. Host alo010.axpnio.dec.com is the master CDS server for the ruby_cell.axpnio.dec.com cell.

The BIND server must be authoritative for the domains of the cell name. The BIND master server requires the following entries in its /etc/namedb/hosts.db file:

alo010.axpnio.dec.com.  IN   A    25.0.0.149

ruby_cell.axpnio.dec.com.    IN   MX   1 alo010.axpnio.dec.com.

ruby_cell.axpnio.dec.com.    IN   TXT  "1 c8f5f807-487c-11cc-b499- \

  08002b32b0ee

Master /.../ruby_cell.axpnio.dec.com/alo010_ch

c84946a6-487c-11cc-b499-08002b32b0ee alo010.axpnio.dec.com"

NOTE: TXT records must span only one line. The third entry above incorrectly occupies four lines to show the information included in the TXT record. You need to do whatever is required with your text editor of choice to ensure this. Widening your window helps. You should also ensure that the quotes are placed correctly, and that the hostname is at the end of the record.

The information to the right of the TXT column in the Hesiod Text Entry (that is, 1 C8f5f807-48...) comes directly from the cdscp show cell /.: as dns command. For example, to obtain the information that goes in the ruby_cell.axpnio.dec.com text record (TXT), you would go to a host in the ruby_cell cell, and enter the cdscp show cell /.: as dns command. Then, when the system displays the requested information, cut and paste this information into the record. This method ensures that you do not have any typing errors.

To ensure that the records that you have entered are valid, issue a kill -1 <named-process-id> command, which causes the named daemon to read in the new hosts.db file. Next, execute the following nslookup command to obtain the host address:

alo001.axpnio.dec.com> nslookup hostname

Server:  named.yourcompany.com

Address:  21.222.0.10

Name:    hostname.yourcompany.com

Address:  21.222.0.4

The dcesetup command begins the configuration program. The default responses to prompts in the configuration procedure are based on your existing configuration, if you have one. Otherwise, defaults appropriate for the most common DCE system configurations are provided. At each prompt, press <Return> to take the default displayed in brackets, type a question mark (?) for help, or supply the requested information.

After you install the DCE software, it displays the following message, prompting you to begin the configuration procedure:

You have installed the DCE software which requires further action to 
configure and start it. To do so please invoke "/usr/sbin/dcesetup" and 
select option 1 (Configure DCE services) from the main menu.  from the main 
menu. 

You must be logged in as root to configure your DCE system. When you invoke dcesetup, the DCE Setup Main Menu appears.

 #  /usr/sbin/dcesetup  

or if already at usr/bin/ just

# dcesetup

             ***  DCE Setup Main Menu  ***

                 Version V4.1 (Rev. 1381)

1)  Configure         Configure DCE services on this system

2)  Show              Show DCE configuration and active daemons

3)  Stop              Terminate all active DCE daemons

4)  Start             Start all DCE daemons

5)  Restart           Terminate and restart all DCE daemons

6)  Clean             Terminate all active DCE daemons and remove

                      all temporary local DCE databases

7)  Clobber           Terminate all active DCE daemons and remove

                      all permanent local DCE databases

8)  CVP               Run Configuration Verification Program

9)  Version           Show DCE Version number

X)  Exit

 Please enter your selection: 

NOTE: If you will be creating a new cell or adding a CDS server, choose option 3 (Terminate all active DCE daemons) to stop the DCE daemons in a controlled manner. Be sure to back up your security and CDS databases before proceeding if this has not already been done.

Choose option 1 (Configure DCE services on this system), to view the Configuration Choice Menu.

                   ***  Configuration Choice Menu  *** 

        1) Configure this system as a DCE Client

        2) Create a new DCE cell

        3) Add Master CDS Server

        4) Configure DCE Distributed File Service (DFS)

        5) Modify DCE cell configuration

        6) Configure this system for RPC only

        7) Configure DCE in TruCluster 

        R) Return to previous menu

 Please enter your selection (or '?' for help): 1 

For information on how to configure a DCE cell or add a client, see Chapter 3, "Configuring the DCE Environment." For information on modifying an existing configuration, see Chapter 4, "Modifying Cell Configuration."

2.3 Configuring LDAP, NSI, and GDA

The Lightweight Directory Access Protocol (LDAP) provides access to the X.500 directory service without the overhead of the full Directory Access Protocol (DAP). The simplicity of LDAP, along with the powerful capabilities it inherits from DAP, makes it the de facto standard for Internet directory services and for TCP/IP.

Inside a cell, a directory service is accessed mostly through the name service interface (NSI) implemented as part of the runtime library. Cross-cell directory service is controlled by a global directory agent (GDA), which looks up foreign cell information on behalf of the application in either the Domain Naming Service (DNS) or X.500 database. Once that information is obtained, the application contacts the foreign CDS in the same way as the local CDS.

Once LDAP is configured, applications can request directory services from either CDS or LDAP or both. LDAP is provided as an optional directory service that is independent of CDS and duplicates CDS functionality. LDAP is for customers looking for an alternative to CDS that offers TCP/IP and internet support.

With LDAP directory service available, GDA can look up foreign cell information by communicating through LDAP to either an LDAP-aware X.500 directory service or a standalone LDAP directory service, in addition to DNS and DAP.

NOTE: Entegrity DCE for Tru64 UNIX does not automatically install LDAP. Prior to installing DCE, a DCE administrator must obtain LDAP software and install it as an LDAP server in the environment. Next, a DCE administrator must choose LDAP during the DCE installation and configuration procedure and intentionally configure LDAP directory service for a cell.

2.4 Kerberos 5 Security for telnet, rlogin, rsh, ftp

The DCE authentication service is based on Kerberos 5. The Kerberos Key Distribution Center (KDC) is part of the DCE security server secd. The authorization information that is created by the Entegrity DCE for Tru64 UNIX privilege server is passed in the Kerberos 5 ticket's authorization field.

2.4.1 Kerberized Network Tools

Communication with remote machines across a network creates risks. A very major risk is to the security of passwords. Transmitting a user's password in clear text can compromise an account. It allows unauthorized individuals to intercept the packets on the network.

The Kerberized network tools, rsh, telnet, rlogin, and ftp are set up to prevent the risk of interception. Security is achieved through a standard client-server authentication protocol implemented in the telnet and telnetd processes. This protocol is extensively outlined in RFC 1510 with its application to the telnet protocol outlined in RFC 1416.

The Kerberos authentication protocol is employed to mutually authenticate the client and server as follows:

A user sends a request to the authentication server (AS) requesting "credentials" via the dce_login process. The AS provides these credentials in the form of a login context. The user's client process and the associated server process "negotiate" the authentication mode. When the mode is successfully negotiated, the server requests, and the client sends, a mutual authentication credential which the client acquires (using its login context) from the Kerberos Ticket Granting Service (TGS). If the server can accept the credential received from the client, then both of the following are true:

• The server has proof of the identity of user represented by the client, and

• The client has proof that it is talking with the intended server

At this point the server can grant the user appropriate rights on the remote machine, and the client and server may negotiate the data policy (integrity or privacy via encryption) to be applied to their subsequent communications.

The steps for using the Kerberized tools are:

• Do a dce_login. (To use the tools a user must have a DCE account.)

• Execute a kinit -f to mark the user's login context as forwardable. This step is optional; it is necessary only if the user intends to forward his or her login to a trusted server system. See Section 2.4.3 on page 65.

• For telnet, a user must set autologin. This can be done in an initialization file, ".telnetrc," with "set autologin." This step may not be necessary; use the display command to determine if autologin is set by default.

The loading process places the executables in the /opt/dcelocal/bin directory. When the installation of the tools is confirmed, the setup process modifies the /etc/services file to indicate to the inetd daemon that the Kerberized telnetd, ftpd, and rlogind daemons are located in the /opt/dcelocal/bin directory. Original non-Kerberized executables are not removed from the system. The administrator has the responsibility for moving them or storing them.

The administrator is also responsible for placing executables in a location appropriate for users to access. The installation procedure does not automatically move the Kerberized client executables from the /etc/dcelocal/bin directory to a place where they will be discovered for execution during user PATH processing. The installation of the client binaries is the responsibility of the system administrator.

After the installation of the software is complete, the inetd daemon must be directed to reread its configuration file (/etc/inetd.conf). The recommended way of doing this is to send a HUP signal to the inetd process (alternatively, the process may be stopped and restarted).

dcesetup uses kcfg to intall the Kerberized tools. kcfg is also available for use by an administrator. To find out more information about the kcfg program, execute two commands. To display individual command switches and their arguments:

kcfg -?

If that doesn't work with your shell, try an alternative entry, "kcfg -\?" It tells the shell to pass a question mark to the executable as opposed to resolving the "?"character as a regular expression.

To display a short description of the command and what it does:

kcfg -h

This provides information on the configuration file management, principal registration, and service configuration.

2.4.3 Ticket Forwarding

The telnet and ftp processes allow the user's client process to designate that its login context (or TGT) be securely forwarded to the associated server process as part of mutual authentication. The user may choose this functionality by invoking the client process with the "-f" flag. If the user's TGT was not designated as forwardable by the AS, then the Kerberos infrastructure of the server machine will reject the forwarded TGT. A user may obtain a forwardable TGT by issuing the kinit -f command (following a successful dce_login).

A user would choose to forward the TGT to a server when he or she wants the server process to impersonate the user's network identity when performing actions on behalf of the user on the target machine. Independent of credential forwarding, the server will impersonate the local operating system identity of the user. Network identity impersonation is useful when there are resources that the server will not be able to access on behalf of the user unless the server operates with the user's network/Kerberos credentials. A DFS file protected by an ACL which authorizes access only to (Kerberos) authenticated users would be an example of such a resource.

A word of caution about forwarding TGTs to server systems. The Kerberos infrastructure stores TGTs, including forwarded TGTs, in files. Access to these files is protected by the local operating system. Any user who has system administrator privilege, or who has managed to subvert the system's security, can read any Kerberos credentials stored on the system. This allows the user to assume the network identity represented by the credential, and use it to impersonate the associated network identity on any system that recognizes it. For this reason, users would be wise to be conservative in their use of ticket forwarding.

The dcesetup configuration script insures that all new accounts will be able to request forwardable TGTs via the kinit -f mechanism. A forwardable TGT should not be forwarded to a server system by the telnet or ftp clients unless the user designates that it be forwarded.

2.4.4 Modifying the Registry

All machines within a cell that use the Kerberos-enabled rtools need to check and possibly modify the registry and the krb5 configuration with the kcfg executable.

To make sure that Kerberos version 4 interoperates with Kerberos version 5, an administrator can execute "kcfg -k" to change the /krb5/krb.conf entries into two separate files, /krb5/krb.conf and /krb5/krb.realms. This command needs to be executed on each machine in the cell.

The registry must contain a principal entry that describes the host machine of the KDC server. This principal entry is of the form host/<hostname>. The principal and the associated keytable entry can be created with "kcfg -p." This verifies that the host entry exists; if not, it creates the host entry.

NOTE: A potential problem that can defeat the installation and operation of the rtools is to be found in the different ways "hostname" is determined. The kcfg command uses the function gethostname() to create the host principal entry in the registry. The gethostname() function acquires the hostname as it is configured with the hostname command at startup. The telnet process gets "hostname" using the gethostbyname() function, which gets the hostname out of either the /etc/hosts file or the DNS/BIND database. Difficulties arise, for example, if the hostname is configured at startup as "mycomputer" but is registered in /etc/hosts and the bind database as "mycomputer.here.com." If the telnet process looks for the host server, it looks for "host/mycomputer.here.com." If the kcfg process configures the host entry in the registry, it configures "host/mycomputer."

2.4.5 Uninstalling the Kerberos Tools

To reverse the installation of the Kerberized tools, go to the Modify Configuration Menu and choose Option 9, Disable Kerberos. Then go to the configuration file, /etc/initd.conf and, if necessary, remove all references to the tools.

2.5 Creating a Private Key Storage Server

Entegrity DCE for Tru64 UNIX adds public key security technology as provided in OSF DCE Release 1.2.2. It refers to a security model that works by requiring a public and a private key pair to lock or unlock information. Private keys are too long for memorization, hence the requirement for secure storage. A private key storage server (PKSS) can be enabled during installation to store users' software-generated private keys.

Private keys are used most often at login. That presents a key management problem if the keys appear where they might be corrupted or stolen. Short of issuing smart cards, enabling the private key storage service provides the best assurance that messages encrypted under one of the key pairs can be decrypted using another pair without being intercepted and read in transit.

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

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

Copyright © 1997-2004 Entegrity Solutions Corporation & its subsidiaries