DCE and DFS for Linux Installation and Configuration Guide

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

3.1 Before You Configure DCE
3.2 Overview of the DCE Cell
3.3 Using the dcesetup Utility
3.4 Setting Environment Variables in setup_state
3.6 Kerberos 5 Security for telnet, rlogin, rsh, ftp

3.1 Before You Configure DCE

Before configuring, you should obtain the following cell information and password from your cell administrator (for a lightweight client you only need the cell name):

• Your DCE hostname (your machine)

• The name of your DCE cell

  If you choose to enter the cell information manually in step 5 of the configuration (Section 4.3, Configuring Your System as a DCE Client with Runtime Services), also obtain:

  • The hostname of the Master CDS server for this cell.
    
  • Whether your host can broadcast to the host where the master CDS server is installed.
    

• The principal name and password of an account that has cell administration privileges (Cell administrator name and password).

• Whether your existing DCE cell is restricted to using TCP only or UDP only.

• The following LDAP server information (if this is will be an LDAP client):
  • The hostname [default is provided]
    
  • The port number [default is provided]
    
  • The authentication domain name (DN)
    
  • The password of the authentication DN
    
  • The cell DN in LDAP syntax
    

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.

3.2.1 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.

3.2.2 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.

3.2.3 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.

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.

3.2.4 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.entegrity.com. The cell belongs to the BIND domain axpnio.entegrity.com. Host alo010.axpnio.entegrity.com is the master CDS server for the ruby_cell.axpnio.entegrity.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.entegrity.com.  IN   A    25.0.0.149

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

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

  08002b32b0ee

Master /.../ruby_cell.axpnio.entegrity.com/alo010_ch

c84946a6-487c-11cc-b499-08002b32b0ee alo010.axpnio.entegrity.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.entegrity.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.entegrity.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.

1. 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  
   

             ***  DCE Setup Main Menu  ***

                 Version V2.3 

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) Version Show DCE Version number

X) Exit

 Please enter your selection: 

1. 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.

2. 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

   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 4, Configuring DCE. For information on modifying an existing configuration, see Chapter 6, Modifying Cell Configuration.

3.4 Setting Environment Variables in setup_state

The setup_state file sets site parameters at configuration time. You can set certain site-specific parameters for DCE and DFS by setting environment variables before running DCE or DFS. These parameters fall into two general catagories: those that modify the behavior of the cell, and those that modify daemon runtime behavior. Those that affect the cell must be set before the cell is initially configured. Those controlling daemons must be set prior to starting the daemons each time.

All of these parameters are modified via environment variables, as set in the file /opt/dcelocal/etc/setup_state. The setup_state file and dfs daemon manpages explain requirements and syntax.

You may add other behavior-modifying variables as you need them, as long as DCE or DFS supports them. Currently, the set of parameters you can change in this way include the following:

Variables that Modify the Behavior of the Cell

These environment variables modify cell creation, and are only used when creating a new cell:

PERSON_LOW_UID="default" — Sets lowest Unix ID for new principals at cell creation

GROUP_LOW_UID="default" — Sets lowest Unix ID for new groups at cell creation

Variables that Modify Daemon Runtime Behavior

These environment variables modify runtime behavior, and are used each time DCE and DFS start.

RPC_SUPPORTED_NETADDRS="" — Restricts supported network addresses for RPC operations.

RPC_UNSUPPORTED_NETIFS="" — Prevents RPC from using listed network interfaces

RPC_RESTRICTED_PORTS="" — Causes RPC to restrict use of communication ports to those listed

RPC_RESTRICTED_SERVER_PORTS="" — Causes servers to only advertise on these ports

DFSD_OPTS="" — Passes options to dfsd at startup. (see dfsd man page)

DFSBIND_OPTS="" — Passes options to dfsbind at startup. (see dfsbind man page)

3.5 DFSFXD_OPTS="-mainprocs 7" — Passes options to dfs fxd daemon at startup. (see fxd man page)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 and DFS for Linux 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.

3.6 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 Gradient DCE and DFS for Linux privilege server is passed in the Kerberos 5 ticket's authorization field.

3.6.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:

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

2. 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 3.6.3, Ticket Forwarding, on page 24.

3. 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.

3.6.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.

3.6.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."

3.6.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.

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

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

Copyright © 2001-2004 Entegrity Solutions Corporation & its subsidiaries