DCE and DFS for Linux Installation and Configuration Guide

F — Multicell Environments

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

This appendix is copied and modified from the Entegrity PC-DCE Administrator's Guide. That entire guide will be available in a later release.

You may want to create an environment in which DCE principals can interact across different cells. For example, an administrator may want to perform DCE administration for several cells from one system. Or, one company may want to grant access to an in-house database to a subset of people at a different company.

This chapter describes how to configure intercell communication in a multicell environment and contains the following sections:

F.1 Understanding Trust Relationships
F.2 Pros and Cons of Intercell Trust Relationships
F.3 Establishing Intercell Communications

F.1 Understanding Trust Relationships

Trust relationships between cells grant access to principals from one cell to objects in another cell and vice versa. To permit principals in one cell to have authenticated access to objects in another cell, you must establish a trust relationship between the two cells.

Two kinds of trust relationships allow principals in a foreign cell to engage in authenticated access to objects in a local cell. These relationships are:

F.1.1 Direct Trust Relationships

A direct trust relationship involves only two cells. The two cells' authentication services share authentication keys and trust each other to authenticate principals from their respective cells. Each cell considers users from the other cell to be authenticated if the user is marked as authenticated by the other cell's authentication service.

Figure F-1 illustrates the concept of direct trust between two cells. Members of Cell 1 have access to services in Cell 2, on the basis of their membership in the trusted Cell 1, through the account krbtgt/cell 1. Likewise, members of Cell 2 have access to services in Cell 1 through the account krbtgt/cell 2. The trust relationship also allows users in the foreign cell to log into accounts in the local cell and vice versa.

Figure F-1: Direct Trust Relationship



F.1.1.1 User Access to the Foreign Cell

From the user's perspective, access to objects and services in the other cell is transparent and automatic. Once users log into their own cell, they also have access to the foreign cell. No additional login to the cross-cell authentication (krbtgt) account is required.

F.1.1.2 Controlling Authorization for Objects in the Cell

Once trust is established, you can control individual foreign principals' access to specific objects by editing the ACL entries of local resources. DCE ACLs support three levels of trust for foreign principals:

If you do not specifically grant a foreign cell access to a resource, foreign principals are granted the rights specified by the any_other entry (if it exists) in the ACL. You should check the any_other rights on any sensitive resources to ensure the resources are sufficiently protected.

F.2 Pros and Cons of Intercell Trust Relationships

Before configuring intercell trust, review the benefits and security implications described in this section.

F.2.1 Simplified Administration

Intercell trust relationships can simplify administration of users by allowing a trusted cell to manage its own security information. For example, Company A allows a cell from Company B to access Company A's services, and Company B manages the membership of the cell that has privileges to Company A's services.

Because the cell consists of employees of Company B, Company B is best able to manage cell membership and security (user id and password management, organizational and personnel changes).

F.2.2 Simplicity for the User

For end users, intercell trust provides transparent access between their own cell and the cell to which they have access via the trust relationship. For example, Cell B users can access services from Cell A on the basis of their membership in the trusted Cell B. They are not required to enter a login ID and password for Cell A.

F.2.3 Security Implications

In an intercell trust relationship, one organization is trusting another to manage security information. By administering DCE ACLs, Cell A is able to set access privileges for its resources based on foreign cell membership, foreign cell group membership, or for individual foreign principals (see Section F.1.1.2, Controlling Authorization for Objects in the Cell, on page 76).

However, Cell A is still relying on Cell B to properly authenticate the end user. Cell B clients present privileges to the Cell A server that were generated by the security server in Cell B. These privileges include the client's DCE identity and the groups to which the client belongs; no further challenges related to the principal's idenetity are issued by the Cell A server. Thus, setting up an intercell environment makes sense only if Cell A trusts Cell B to properly administer cell membership and security.

F.3 Establishing Intercell Communications

For intercell communication to be successful:

Establishing intercell communications requires you to do the following in the order shown:

F.3.1 Establishing Intercell Lookup
F.3.2 Establishing Intercell Trust
F.3.3 Verifying Account Creation
F.3.4 Modifying the Account Valid Flag
F.3.5 Adding Entries for Replica Servers to DNS

F.3.1 Establishing Intercell Lookup

To establish intercell lookup, add entries for each of the two cells to the DNS server:

  1. Ensure that the names of the two cells between which you will establish communication include the domain name that the DNS server will use. The cell names should look similar to the following: 

    groucho.eng.entegrity.com
harpo.eng.entegrity.com

    Here, eng.entegrity.com is the domain name.

  2. In the local cell, enter show cell as dns from the cdscp prompt.

    Any system in the cell will supply the correct output for show cell as dns; you do not have to use the master system.

    The following example shows the output of this command for the cell harpo.eng.entegrity.com: 

    cdscp> show cell as dns


                  SHOW


                  CELL              /.../harpo.eng.entegrity.com


                  AT                  2000-06-25-12:40:33


                  TXT =           1 002cb551-d2d8-b154-00104b9afb74 Master /.../ \ 
              harpo.eng.entegrity.com/MA1_ch 00282170-d2d8-b9afb74

  3. Refer to the output of the show cell as dns command to create two new entries — an MX record and a TXT record — for the local cell in the DNS management program you are using.

    NOTE: When you initially configure intercell lookup, include entries for master servers only. After intercell communication is established and running correctly, add DNS entries for replica servers.

  4. In the foreign cell, enter show cell as dns from the cdscp prompt. Repeat step 3 to create an MX record and a TXT record for the foreign cell.

F.3.2 Establishing Intercell Trust

Establishing a direct intercell trust relationship between a foreign and local cell indicates that you trust the foreign cell's authentication service to correctly authenticate users in its own cell, and that you consider all users from the foreign cell to be authenticated if they are so marked by the foreign cell's authentication service.

To establish intercell trust, use rgy_edit or dcecp registry connect to create an account for the foreign cell in the local cell.

NOTE: If you mistype the parameters for these commands, the account may be created as a local, rather than foreign, account and you will receive error messages when you try to establish the intercell connection.

NOTE: You must create the local and foreign groups and organizations before you run rgy_edit or dcecp registry connect.

Supply the following parameters with these rgy_edit or dcecp registry connect:

Foreign cell host name

Foreign account — The foreign account must have the permissions required to create principals and accounts (for example, cell_admin). The account accesses the foreign registry to create the account that represents the local cell in the foreign account's registry.

Foreign account's current password

Local group name — Group name to be associated with the account in the local cell (the registry requires all accounts to be associated with a group).

Foreign group name — Group name to be associated with the account in the foreign cell.

Local organization name — Organization name to be associated with the account in the local cell (the registry requires all accounts to be associated with an organization).

Foreign organization name — Organization to be associated with the account in the foreign cell.

Expiration date (optional) — Time and date that both the local and the foreign cell's accounts expire, and the peer-to-peer relationship is ended, prohibiting any further authenticated communications between principals in the two cells. To renew the account, change the date in this field. The default is none.

Your password

Example

The following example uses rgy_edit to create an account in the local cell for the foreign cell. In this example, the administrator associates the new account with the default group none and the default organization none. These associations can be changed later. 

rgy_edit=> cell /.../harpo.eng.entegrity.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:-dce-
Enter account id to log into foreign cell with: cell_admin
Enter password for foreign account:-dce-
Enter expiration date [yy/mm/dd or "none"]: <none>
Principals and Accounts have been created.

The following example shows the same procedure using dcecp registry_connect: 

dcecp> registry connect /.../harpo.eng.entegrity.com -facct cell_admin \ 
-facctpw -dce- -group none -fgroup none -org none -forg none -mypwd -dce-
dcecp>

F.3.2.1 What Happens When You Create an Account for the Foreign Cell

Entering the rgy_edit or registry connect command does the following:

The new accounts have the default account attributes except for the following differences:

These attributes apply to all foreign principals when they access objects in the local cell. Similarly, the attributes of the account created in the foreign cell for the local cell apply to all principals in the local cell when they access objects in the foreign cell.

F.3.3 Verifying Account Creation

To view the new accounts, enter the dcecp command principal catalog. Each cell now includes two krbtgt accounts: its own account (krbtgt/harpo.eng.entegrity.com) and the new foreign cell's account (krbtgt/groucho.eng.entegrity.com): 

dcecp> principal catalog
/.../harpo.eng.entegrity.com/nobody
/.../harpo.eng.entegrity.com/root
/.../harpo.eng.entegrity.com/daemon
/.../harpo.eng.entegrity.com/sys
/.../harpo.eng.entegrity.com/bin
/.../harpo.eng.entegrity.com/uucp
/.../harpo.eng.entegrity.com/who
/.../harpo.eng.entegrity.com/mail
/.../harpo.eng.entegrity.com/tcb
/.../harpo.eng.entegrity.com/dce-ptgt
/.../harpo.eng.entegrity.com/dce-rgy
/.../harpo.eng.entegrity.com/cell_admin
/.../harpo.eng.entegrity.com/krbtgt/harpo.eng.entegrity.com
/.../harpo.eng.entegrity.com/hosts/harpo/self
/.../harpo.eng.entegrity.com/hosts/harpo/cds-server
/.../harpo.eng.entegrity.com/hosts/harpo/gda
/.../harpo.eng.entegrity.com/krbtgt/groucho.eng.entegrity.com

F.3.4 Modifying the Account Valid Flag

For accounts that represent foreign cells, the account valid flag is set to no by default.

After you establish intercell lookup and trust, do the following:

  1. Log into the local cell as cell_admin.

  2. Use dcecp to change the acctvalid flag of the new account that represents the foreign cell to yes.

  3. Log into the foreign cell as cell_admin.

  4. Use dcecp to change the acctvalid flag of the new account that represents the local cell to yes.

This establishes that the new accounts are valid. If one or both accounts are invalid, no intercell communications can take place.

For example, log into the cell, groucho, and modify the account valid flag for the krbtgt/harpo account as follows: 

c:\dce_login cell_admin -dce-
Password must be changed!
c:\dcecp
dcecp> account modify krbtgt/harpo.eng.entegrity.com -acctvalid yes
To verify that the account valid flag has been changed to yes:

Enter the dcecp account show command. This command displays the attributes assigned to the new accounts.. 

dcecp> account show krbtgt/harpo.eng.entegrity.com
{acctvalid yes}
{client no}
{created /.../groucho.eng.entegrity.com/cell_admin\ 
2000-07-02-10:12:11.000-04:00I-----}
{description {}}
{dupkey yes}
{expdate none}
{forwardabletkt yes}
{goodsince 2000-07-02-10:11:53.000-04:00I-----}
{group none}
{home {}}
{lastchange /.../groucho.eng.entegrity.com/cell_admin\ 
2000-07-02-10:12:13.000-04:00I-----}
{organization none}
{postdatedtkt yes}
{proxiabletkt yes}
{pwdvalid yes}
{renewabletkt yes}
{server yes}
{shell {}}
{stdtgtauth yes}

F.3.5 Adding Entries for Replica Servers to DNS

After you have verified that intercell communication has been successfully established, use the information in Section F.3.1, Establishing Intercell Lookup, on page 78 to add entries for replica servers to DNS.

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

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

Copyright © 2001-2004 Entegrity Solutions Corporation & its subsidiaries