| Note: | The DCE Version 1.2.2 code does not provide support for the transitive trust relationships discussed in this section. |
To give explicit permission for principals in other cells to engage in authenticated access to objects in your cell, you must establish a trust relationship with that cell. You do this using the dcecp registry connect command to create two special accounts: One in your cell's registry to represent the foreign cell and one in the foreign cell's registry to represent your cell. Establishing these accounts indicates that you trust the foreign cell's authentication service to correctly authenticate foreign users and, therefore, you consider all users from this cell to be authenticated if they are marked as authenticated by the foreign cell's authentication service.
Once the trust relationship is established, you can control foreign principals' access to specific objects with ACL entries just as you do for principals in the local cell. The trust relationship also allows users in the foreign cell to log into accounts in the local cell and vice versa.
Two kinds of trust relationships allow principals in other cells to engage in authenticated access to objects in your cell. These relationships are direct trust relationships and hierarchical transitive trust relationships. Throughout this chapter, the term transitive trust relationship is used to indicate the DCE implementation of hierarchical transitive trust relationships.
In a direct trust relationship, two cells' authentication services share authentication keys and trust each other to authenticate principals from their respective cells. Therefore, both cells consider all users from each cell to be authenticated if they are marked as authenticated by their respective authentication services. The shared authentication keys are derived from a single password (one for each cell) that is used by all principals from one cell to be authenticated to the other cell. A direct trust relationship involves only two cells.
Use the registry connect command to establish direct trust and transitive trust relationships. Note that, although you can create a direct trust relationship between any two cells, you can create a transitive trust relationship only for those cells connected by a transitive trust path.
This command creates two special accounts: One in your cell's registry to represent the foreign cell, another in the foreign cell's registry to represent your cell. The command creates the accounts' principals at the same time. Once the trust relationship is established, users in the foreign cell can log into accounts in the local cell and vice versa. You control foreign principals' access to specific objects with ACL entries, just as you do for principals in the local cell.
When the accounts are created, the registry connect command performs two tasks that you should be aware of. First, it automatically generates one password that is shared by both accounts. This means that users who log into a cell with which their cell has a trust relationship are seen as the same principal and share the same password. Second, the registry modify command generates a UNIX number that is shared by all principals that are in a given foreign cell. This shared UNIX number helps prevent collision between the UNIX numbers of local and foreign principals when objects on a local machine are accessed.
Within the registry and for the purposes of network access, principals are identified by a UUID that represents their fully qualified names; for example, /.../dresden.com/dce/users/mahler for the principal mahler. However, the local operating system on a local machine identifies principals by UNIX number. Because UNIX numbers are not required to be unique across cells, it is possible for two principals from different cells to have the same UNIX number. Thus, a foreign principal that is accessing files in the local cell could have the same UNIX number as the local principal and be seen by the local system as the owner of the local user's files on the local machine.
Creating a UNIX number that is applied to every principal from a given cell that accesses the local cell prevents this from occurring. However, you need to be aware that, because the foreign users all have the same UNIX number, the very feature that prevents them from accessing the local user's files allows them to access each other's files. Because each user from the same foreign cell is seen as the same user, every file on the local machine that is owned by a foreign user can be accessed by every other foreign user from the same foreign cell.
To prevent the widespread proliferation of trust relationships that could result in unwieldy administrative burdens and weakened security, the DCE Security Service imposes the following three rules on transitive trust relationships:
The ramifications of these rules are explained in the following paragraphs.
Rule 1:
Any number of descendent cells can be traversed in a hierarchical trust relationship, and any number of ancestor cells can be traversed by a transitive trust relationship.
For example, in Figure 53, peer Cells A and B have a direct trust relationship. Cell A has a transitive trust relationship with cells B/C and B/C/D.
Figure 53. Direct and Transitive Trust Relationships
|
The previous configuration also makes possible the transitive trust relationship between B and cell B/C/D shown in Figure 54.
Figure 54. Cell Traversal in Transitive Trust Relationships
 |
Rule 2:
No more than one direct trust peer relationship can be traversed by a transitive trust relationship.
For example, in Figure 55, cells A, B, and C are peer cells. Cell A has a direct trust peer relationship with cell B, and cell B has a direct trust peer relationship with cell C. Cell A does not have a transitive trust relationship with cell C because to do so would traverse more than one direct trust peer relationship (A to B and B to C).
Figure 55. Limited Direct Trust Peer Traversal in Transitive Trust
 |
Note that it is not required to traverse a direct trust peer relationship to have a transitive trust relationship. In Figure 56, no direct trust peer relationships are traversed. In the figure, a transitive trust relationship exists between the following:
Figure 56. Transitive Trust Without Direct Trust Peer Traversal
 |
Rule 3:
Once a hierarchical trust relationship traverses a direct trust ancestor and a direct trust peer, it cannot traverse to an ancestor of the cell.
For example, consider Figure 57. The A_Conglomerate cell hierarchy and the B_Conglomerate cell are connected by direct trust relationships. Additionally, there is a direct trust relationship between A_product in the A_Conglomerate hierarchy and B_product in the B_Conglomerate hierarchy. In this configuration, no transitive trust relationships are possible because they cannot traverse to an ancestor after traversing a direct trust peer.
Figure 57. Limited Trust Traversal to Cell Ancestors
 |
The type of trust relationship shown in this figure might be used by two companies that have a very limited agreement to cooperate on product development.
Figure 58 shows another transitive trust path.
Figure 58. Alternate Trust Traversal to Cell Ancestors
 |
In the path, the B_product cell has a transitive trust path up to its ancestor, B_Company, and from B_Company to A_Company. But from A_company, the transitive trust path cannot continue up to A_Company's ancestor, although it can continue down to A_Company's descendants. Because this transitive trust relationship has traversed up to a trust ancestor (B_Company) and across to a trust peer (A_Company), it cannot then continue by going up to A_Company's ancestor (A_Conglomerate). This type of relationship might be used by two companies that have decided to combine operations at a very high level.
Note that a principal accessing a foreign cell through transitive trust relationships is not authenticated by each cell transited in the trust path, but only by the target cell itself. The authentication service in a transited cell simply gives the principal a ticket to the next cell in the path, stamping the ticket with the hierarchical name of the transited cell, until the principal acquires a ticket to the target cell.
To determine whether or not to give a principal a ticket to the next cell in a transitive trust path, the authentication service in each transited cell examines the ticket and compares the last cell transited to the next cell in the path and applies the rules of transitive trust described in this section. If the next cell to be transited is consistent with a valid transitive trust path, then the authentication service gives the principal a ticket to the next cell; otherwise, the authentication service refuses to issue a ticket.