Document revision date: 5 July 2000

DCE Integrated Login is currently incompatible with OpenVMS External Authentication. Only one of the two methods for authenticating users with external (to OpenVMS) mechanisms can be used at any one time.

Although the DCE configuration program checks to see if the local system is set up to use External Authentication, the system may experience a conflict due to operator error. If this occurs, the DCE LGI_CALLOUTS will override the OpenVMS External Authentication, disabling the External Authentication and allowing Integrated Login to function normally. Any applications that depend on External Authentication may be adversely affected.

For more information on OpenVMS External Authentication, see the OpenVMS Version 7.1 New Features Manual, Section 3.5, and the OpenVMS Version 7.1 and Version 7.2 Release Notes, Section 4.8.

This chapter provides tips for choosing a cell name and for managing cell names in the Domain Name System (DNS), LDAP, and in X.500. Additional details can be found in the chapter about global and cell considerations in the OSF DCE Administration Guide --- Introduction.

The following are simple guidelines for naming cells:

• Do not configure a cell with the same name as another cell on the same network.
• Choose your cell name carefully.

The last item is especially important, because the naming formats for DNS and LDAP/X.500 are incompatible, and DCE does not currently support changing the name of a cell. Therefore, you must understand which method you are using for intercell communications before you name the cell.

9.1 Intercell Naming with 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 or more (if replicas) resource records for each CDS server that maintains a replica of the cell namespace root. Do not configure a cell with the same name as another cell on the same network.

9.1.1 Intercell Naming Example --- DNS

The following examples show the steps you should take to set up intercell naming between two cells called laser-cell.zko.dec.com and ruby-cell.zko.dec.com . (A summary of this process is provided at the end of this chapter.) The two cells belong to the same BIND domain zko.dec.com . Host laser.zko.dec.com is the master CDS server for the laser-cell.zko.dec.com cell. Host ruby.zko.dec.com is the master CDS server for the ruby-cell.zko.dec.com cell .

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

laser.zko.dec.com. IN A 25.0.0.127 laser-cell.zko.dec.com. IN MX 1 laser.zko.dec.com. laser-cell.zko.dec.com. IN TXT "1 130f1c81-4876-11cc-931d-08002b33f531 Master /.../laser-cell.zko.dec.com/laser_ch 124ded80-4876-11cc-931d-08002b33f531 laser.zko.dec.com" ruby.zko.dec.com. IN A 25.0.0.149 ruby-cell.zko.dec.com. IN MX 1 ruby.zko.dec.com. ruby-cell.zko.dec.com. IN TXT "1 c8f5f807-487c-11cc-b499-08002b32b0ee Master /.../ruby-cell.zko.dec.com/ruby_ch c84946a6-487c-11cc-b499-08002b32b0ee ruby.zko.dec.com"

The information to the right of the TXT column in the Hesiod Text Entry (that is, 1 130f1c81-48...) comes directly from the cdscp show cell /.:/ as dns command. For example, to obtain the information that goes in the laser.zko.dec.com text record (TXT), you would go to a host in the laser cell, and enter the cdscp show cell /.:/ as dns command. Then, when the system displays the requested information, you would cut and paste this information into the record. This method ensures that you do not have any typing errors. If the cell contains one or more replicas, add the additional text record(s) in the same manner. Make sure cell names and hostname text in the record are identical for Master and Read-Only TXT record(s). Only the clearinghouse (x-cell/x_ch) and UUID values change.

On UNIX master bind server systems, ensure that the records that you have entered are valid by issuing a kill -1 named-process-id command. For OpenVMS systems, see the TCP/IP product-specific implementation documentation for equivalent functionality. This causes the named daemon to read in the new hosts.db file.

Your host must access the bind server for the intercell information. To accomplish this, set name service parameters for your particular TCP/IP. This causes cell names to be sent to and resolved by the bind server and not your "localhost". Check the TCP/IP product specific documentation for instructions on setting the name service as well as invoking the nslookup command to obtain the host address:

laser.zko.dec.com> nslookup

Default Server: localhost Address: 127.0.0.1, 25.0.0.32

Next, enter the names of the cells, as shown:

> set type=any > ruby-cell.zko.dec.com

Server: localhost Address: 127.0.0.1

ruby-cell.zko.dec.com text = "1 c8f5f807-487c-11cc-b499-08002b32b0ee Master /.../ruby-cell.zko.dec.com/ruby-cell.zko.dec.com/ruby_ch c84946a6-487c-11cc-b499-08002b32b0ee ruby.zko.dec.com" ruby-cell.zko.dec.com preference = 1, mail exchanger = ruby.zko.dec.com ruby.zko.dec.com inet address = 25.00.127

View the information and ensure that it is complete and correct.

Now that you have set up BIND, you must use the Security Service rgy-edit cell command to create a cross-cell authentication account in the local and foreign cells. This account allows local principals to access objects in the foreign cell as authenticated users and vice versa.

In the laser-cell.zko.dec.com cell, you must use the rgy-edit cell command to create an account for /.../ruby-cell.zko.dec.com . Refer to the Security Service commands in the OSF DCE Administration Reference for details on the cell command. After adding the account for /.../ruby-cell.zko.dec.com in the laser-cell.zko.dec.com cell, you should have an account entry that looks like the following:

krbtgt/ruby.zko.dec.com [none none]:*:101:12::/::

Note that the cell name is stripped of the path qualifier and is prefixed with krbtgt . The resulting name is used as the primary name for the cross-cell authentication account. You should now also have a principal entry that looks like the following:

krbtgt/ruby.zko.dec.com 101

If a cell is reconfigured, changing its namespace and clearinghouse UUIDs, the krbtgt principal created by the cell command must be deleted using rgy_edit in the foreign cell. Note that for Compaq DCE for OpenVMS VAX and OpenVMS Alpha Version 3.0, the krbtgt principal must be deleted on both cells before the cell command is reexecuted between two cells. To test for proper configuration, show the cell information for the foreign cell. For example, in the laser-cell.zko.dec.com cell, use the cdscp show cell command to show information about the ruby-cell.zko.dec.com cell. To do this at a laser cell host, execute the following command:

cdscp> show cell /.../ruby-cell.zko.dec.com

To perform a similar operation from a ruby-cell cell host, execute the following command:

cdscp> show cell /.../laser-cell.zko.dec.com

9.2 Intercell Naming with X.500

The DCE configuration program automatically creates an entry in the X.500 namespace for the cell when it is configured if the following conditions are true:

• The parent entry already exists.
• The cell name entry is not in use.

The following examples show the steps you should take to set up intercell naming between two cells called /c=us/o=compaq/ou=lasercell and /c=us/o=compaq/ou=rubycell . (A summary of this process is provided at the end of this chapter.) The two cells belong to the same X.500 namespace /c=us/o=compaq . Host laser is the CDS master server for the /c=us/o=compaq/ou=lasercell cell. Host ruby is the CDS master server for the /c=us/o=compaq/ou=rubycell cell.

Answer "Yes" to the question "Do you want to register the DCE cell in X.500" during configuration of the cell. This puts the required DCE CDS information into the X.500 namespace for later use by GDA. This operation requires an X.500 DUA on the host system. Refer to DEC X.500 Directory Service --- Management for more information about installing and configuring X.500.

Execute an intercell command similar to the following command to show the root of the new cell and to see if everything works:

cdscp> show cell /.../c=us/o=compaq/ou=rubycell

Enter the preceding command from an unauthenticated, nonprivileged account.

Now that you have configured and set up X.500, you must use the Security Service rgy_edit cell command to create a cross-cell authentication account in the local and foreign cells. This account allows local principals to access objects in the foreign cell as authenticated users and vice versa.

In the /c=us/o=compaq/ou=lasercell cell, you must use the rgy_edit cell command to create an account for /.../c=us/o=compaq/ou=rubycell . (Refer to the Security Service commands in the OSF DCE Administration Reference for details about the cell command.) After adding the account for /.../c=us/o=compaq/ou=rubycell in the /c=us/o=compaq/ou=lasercell cell, you should have an account entry that looks similar to the following:

krbtgt/c=us/o=compaq/ou=rubycell [none none]:*:101:12::::

Note that the cell name is stripped of the path qualifier and is prefixed with krbtgt . The resulting name is used as the primary name for the cross-cell authentication account. You should now also have a principal entry that looks like the following:

krbtgt/c=us/o=compaq/ou=rubycell 101

If a cell is reconfigured, changing its namespace and clearinghouse UUIDs, the krbtgt principal created by the cell command must be deleted using rgy_edit in the foreign cell. Note that for Compaq DCE for OpenVMS VAX and OpenVMS Alpha Version 3.0, the krbtgt principal must be deleted on both cells before the cell command is reexecuted between two cells. To test for proper configuration, show the cell information for the foreign cell. For example, in the /c=us/o=compaq/ou=lasercell cell, use the cdscp show cell command to show information about the /c=us/o=compaq/ou=rubycell cell. To do this at a laser cell host, execute the following command:

cdscp> show cell /.../c=us/o=compaq/ou=rubycell

To perform a similar operation from a /c=us/o=compaq/ou=rubycell cell host, execute the following command:

cdscp> show cell /.../c=us/o=compaq/ou=lasercell

9.3 Intercell Naming with LDAP

The DCE configuration program automatically creates an entry in the LDAP namespace for the cell when the following conditions are true:

• The parent entry already exists.
• The cell name entry is not in use.

The following examples show the steps you should take to set up intercell naming between two cells called /c=us/o=compaq/ou=lasercell and /c=us/o=compaq/ou=rubycell . (A summary of this process is provided at the end of this chapter.) The two cells belong to the same LDAP namespace /c=us/o=compaq . Host laser is the CDS master server for the /c=us/o=compaq/ou=lasercell cell. Host ruby is the CDS master server for the /c=us/o=compaq/ou=rubycell cell.

Answer "Yes" to the question "Do you want to register the DCE cell in LDAP" during configuration of the cell. This puts the required DCE CDS information into the LDAP namespace for later use by GDA. No special LDAP client code is required on the host system---everything necessary was installed as part of the DCE installation. Refer to the documentation from your LDAP server vendor for more information about installing and configuring an LDAP server.

Execute an intercell command similar to the following command to show the root of the new cell and to see if everything works:

cdscp> show cell /.../c=us/o=compaq/ou=rubycell

Enter the preceding command from an unauthenticated, nonprivileged account.

Now that you have configured and set up LDAP, you must use the Security Service rgy_edit cell command to create a cross-cell authentication account in the local and foreign cells. This account allows local principals to access objects in the foreign cell as authenticated users and vice versa.

In the /c=us/o=compaq/ou=lasercell cell, you must use the rgy_edit cell command to create an account for /.../c=us/o=compaq/ou=rubycell . (Refer to the Security Service commands in the OSF DCE Administration Reference for details about the cell command.) After adding the account for /.../c=us/o=compaq/ou=rubycell in the /c=us/o=compaq/ou=lasercell cell, you should have an account entry that looks similar to the following:

krbtgt/c=us/o=compaq/ou=rubycell [none none]:*:101:12::::

Note that the cell name is stripped of the path qualifier and is prefixed with krbtgt . The resulting name is used as the primary name for the cross-cell authentication account. You should now also have a principal entry that looks like the following:

krbtgt/c=us/o=compaq/ou=rubycell 101

If a cell is reconfigured, changing its namespace and clearinghouse UUIDs, the krbtgt principal created by the cell command must be deleted using rgy_edit in the foreign cell. Note that for Compaq DCE for OpenVMS VAX and OpenVMS Alpha Version 3.0, the krbtgt principal must be deleted on both cells before the cell command is reexecuted between two cells. To test for proper configuration, show the cell information for the foreign cell. For example, in the /c=us/o=compaq/ou=lasercell cell, use the cdscp show cell command to show information about the /c=us/o=compaq/ou=rubycell cell. To do this at a laser cell host, execute the following command:

cdscp> show cell /.../c=us/o=compaq/ou=rubycell

To perform a similar operation from a /c=us/o=compaq/ou=rubycell cell host, execute the following command:

cdscp> show cell /.../c=us/o=compaq/ou=lasercell

9.4 Summary

The following steps summarize the intercell naming process. Refer to the chapter on managing intercell naming in the OSF DCE Administration Guide --- Core Components for more information.

9.4.1 DNS Bind

For DNS bind:

1. Execute a cdscp show cell /.:/ as dns command.
2. Edit the hosts.db file and add the cell name.
3. Execute the kill -1 named-process-id command on UNIX systems to instruct the server to reread the database records. On an OpenVMS system acting as the DNS Master Bind Server, see the TCP/IP specific information for database update and nslookup instructions.
4. Perform an nslookup operation to verify that the cell information can be read. All three records (A, MX, and TXT) are returned.
5. Execute an intercell command similar to the following command to show the root of the new cell and to see if everything works:

   cdscp> show cell /.../ruby-cell.zko.dec.com

   
   Enter the preceding command from an unauthenticated, nonprivileged account.

6. Run dce_login , and log in as cell_admin .
7. Run rgy_edit , and execute a cell command similar to the following:

   rgy_edit> cell /.../laser-cell.zko.dec.com Enter group name of the local account for the foreign cell: none Enter group name of the foreign account for the local cell: none Enter org name of the local account for the foreign cell: none Enter org name of the foreign account for the local cell: none Enter your password: Enter account id to log into foreign cell with: cell_admin Enter password for foreign account: Enter expiration date [yy/mm/dd or 'none']: (none) none

For X.500:

1. Answer "Yes" to the configuration question "Do you want to register the DCE cell in X.500".
2. Execute an intercell command similar to the following command to show the root of the new cell and to see if everything works:

   cdscp> show cell /.../c=us/o=compaq/ou=rubycell

   
   Enter the preceding command from an unauthenticated, nonprivileged account.

3. Run dce_login , and log in as cell_admin .
4. Run rgy_edit , and execute a cell command similar to the following:

   rgy_edit> cell /.../c=us/o=compaq/ou=lasercell Enter group name of the local account for the foreign cell: none Enter group name of the foreign account for the local cell: none Enter org name of the local account for the foreign cell: none Enter org name of the foreign account for the local cell: none Enter your password: Enter account id to log into foreign cell with: cell_admin Enter password for foreign account: Enter expiration date [yy/mm/dd or 'none']: (none) none

	privacy and legal statement
6532_DCE_PG_PRO_005.HTML