7 — Multicell Environments

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

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:

7.1 Understanding Trust Relationships
7.2 Pros and Cons of Intercell Trust Relationships
7.3 Establishing Intercell Communications

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

• Direct trust relationships

• Transitive trust relationships (not supported by OSF DCE Version 1.2.1)

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 7-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 7-1: Direct Trust Relationship

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

7.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. To edit object ACLs, you can use the graphical interface provided by the Visual DCE ACL Editor. See the Visual DCE ACL Editor online help file for additional information. DCE ACLs support three levels of trust for foreign principals:

• foreign_cell — Grants or denies access to all users from the foreign cell.

• foreign_group — Grants or denies access to foreign users based on group membership.

• foreign_user — Grants or denies access to a particular user from the foreign cell.

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.

7.2 Pros and Cons of Intercell Trust Relationships

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

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

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

7.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 7.1.1.2 on page 104).

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.

7.3 Establishing Intercell Communications

For intercell communication to be successful:

• Both cells must use the same DNS server.

• Each cell's name should be the same as the machine name of its Master Security Server. For example, if the Master Security Server hostname is robin.acme.com, the cell should be called robin.acme.com.

• The master systems must be able to contact each other over the network (to test, ping each system from the other system).

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

7.3.1 Establishing Intercell Lookup
7.3.2 Establishing Intercell Trust
7.3.3 Verifying Account Creation
7.3.4 Modifying the Account Valid Flag
7.3.5 Adding Entries for Replica Servers to DNS

7.3.1 Establishing Intercell Lookup

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.

   • MX Record - Gives the entry a preference. Use the cell name, not the machine name, as the hostname of the master server (for example, harpo.eng.entegrity.com). Use a preference of 1 for master servers and a lower preference for replica servers.

     The following example shows how an MX record would appear when entered into the Microsoft DNS Manager:

     
     

   • TXT Record - Enter the hostname (for example, harpo).

     Complete the text field. Use the TXT = output from the show cell as dns command, and add the system hostname at the end of the entry. For example, a text entry might read:

     1 002cb551-d2d8-b154-00104b9afb74 Master /.../harpo.eng.entegrity.com/ harpo_ch 00282170-d2d8-b9afb74 harpo.eng.entegrity.com

     In this example, harpo.eng.entegrity.com is the system hostname that you add to the end of the entry.

     NOTE: Ensure that you enter the information exactly as it is displayed in the TXT = output of the show cell as dns command.

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.

5. In each of the two cells, start the GDAD (Global Directory Agent) process.

   To do so, access the More Servers tab of the PC-DCE Configuration Panel, enable the Global Directory Agent option. Remember to enter the cell_admin password on the More Servers tab:

   
   

   After you click OK, the Configuration Status dialog displays the progress of the configuration.

6. After the GDAD process has been started successfully, click Close to close the Configuration Status dialog.

7. To close the PC-DCE Configuration Panel, click Cancel (this does not cancel the GDAD process).

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>

Entering the rgy_edit or registry connect command does the following:

• Creates two cross-cell authentication accounts and the accounts' principals. One account is created in the local cell's registry to represent the foreign cell, and another account is created in the foreign cell's registry to represent the local cell.

  New account principals are named according to the original cell name and the prefix krbtgt; for example, krbtgt/<foreign_cell_name>.

• Assigns a UUID that is shared by all principals in the foreign cell. Each user in the foreign cell is now identified with the shared cell UUID as well as its own user UUID. The ACL manager uses the cell UUID/user UUID pair to determine access.

  NOTE: In the specific case that you are using DFS with a UFS partition, the system uses only the foreign cell UUID to determine access, not the user UUID. This means that foreign users accessing the UFS partition are seen as the same foreign user, and files on a local system that are owned by a foreign user can be accessed by every other foreign user that is a member of that foreign cell.

The new accounts have the default account attributes described in Table 3-1 on page 42 except for the following differences:

• acctvalid — set to no
  
• client — set to no
  
• dupkey — set to yes
  
• postdatedtkt — set to yes
  
• proxiabletkt — set to yes
  

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.

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

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

Enter the dcecp account show command. This command displays the attributes assigned to the new accounts. Refer to Section 3.8.4 on page 45 for information about modifying these parameters.

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}

After you have verified that intercell communication has been successfully established, use the information in Section 7.3.1 on page 106 to add entries for replica servers to DNS.

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

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

Portions of this document were derived from materials provided by Compaq Computer Corporation. Copyright © 1998-2003 Compaq Computer Corporation.

Copyright © 2003 Entegrity Solutions Corporation & its subsidiaries.

All rights reserved.