Previous chapters in this guide described the DCE administration tasks that are performed within individual cells. The administration of a multicell environment, which is one in which principals from foreign cells access objects in the local cell, has additional tasks and considerations that arise from the interaction of principals across different cells.
In fact, you can have two types of system administrators: one for local cell administration and one for intercell administration of the multicell environment. If you set up groups for the two types of administrators, you can set the ACL for the krbtgt directory, which contains cell principals, in the registry database to allow updating only by the group of intercell administrators. Be sure, however, to allow all other users read access to the krbtgt directory or intercell access will be denied to those users. Note that, if you protect the krbtgt directory in this way, ensure that all directories below the krbtgt directory also have the proper ACLs. The easiest way to accomplish this is to change the object ACL and the initial creation ACLs on krbtgt directory after the registry is created.
This chapter describes the trust relationships between cells that allow principals from foreign cells access to objects in your cell and vice versa.
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 Service. 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.
A transitive trust relationship comes about as a result of a direct trust relationship. In this relationship, cells in a direct trust relationship trust (with some constraints) each other's Authentication Service to authenticate principals not only from their respective cells but also from the cells with which they have direct trust relationships. A transitive trust relationship can involve three or more cells. A transitive trust relationship is illustrated in the figure titled "Transitive Trust Relationships."
In this figure cell A trusts peer cell B (the cell with which it has a direct trust relationship) to authenticate the principals in cell B and to guarantee the authentication of the principals in cell B/C (the cell with which it has a transitive trust relationship).
Because cell A trusts cell B's Authentication Service, it allows authenticated access to all principals whose authentication is guaranteed by cell B's Authentication Service. These authenticated principals include principals from cell B and principals from cell B/C.
Use the registry connect command to establish a 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 (also called a UID). 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, in file systems, such as LFS, that use extended credentials (which are communicated using secure RPC), foreign principals can be uniquely identified using their UUID. But UFS is limited in what it is able to record about users; it holds just the UNIX number. Therefore, an LFS file that is created by a foreign user is correctly reported as owned by that foreign user when examined with DCE tools. However the UNIX tools are only able to report the foreign principal's UNIX number, which may correspond to a different user in the local cell.
Since native UNIX file systems store only the UNIX number, they do not have the ability to uniquely identify foreign users, as LFS does. For exported UFS partitions, DFS maps every foreign principal to the predefined principal, nobody. The nobody principal is also used for unauthenticated access. So the very feature that prevents foreign principals from accessing the local user's files also allows them to access each other's files. With UNIX file systems, each user from a 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 as well as by unauthenticated users.
To prevent the widespread proliferation of trust relationships that could result in unwieldy administrative burdens and weakened security, the 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 the following figure, 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.
The previous configuration also makes possible the following transitive trust relationship between B and cell B/C/D as shown in the following figure.
Rule 2:
No more than one direct trust peer relationship can be traversed by a transitive trust relationship.
For example in the following figure, 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).
Note that it is not required to traverse a direct trust peer relationship to have a transitive trust relationship. In the following figure, no direct trust peer relationships are traversed. In the figure, a transitive trust relationship exists: 1) between B_Division and C_Division and C_organization and 2) between C_Division and B_Division and B_organization.
In this figure a transitive trust relationship exists: 1) between B_Division and C_Division and C_organization and 2) between C_Division and B_Division and B_organization.
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 the following figure. 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.
The type of trust relationship shown in the above figure might be used by two companies that have a very limited agreement to cooperate on product development.
The following figure shows another transitive trust path.
In the path, the B_product cell has a transitive trust path up to its ancestor, B_Company and from B_Company to the A_Company. But, from the 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 (the 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.
To create peer-to-peer relationships, follow these steps:
When you use the registry connect command, you must supply the fully qualified name of the foreign cell with which you will establish a peer-to-peer relationship. This name is stripped of the full pathname, prefixed with krbtgt, and used as the primary name of the account's principal. For example, if you enter a cell name of /.../dresden.com, the principal name is krbtgt/dresden.com. The unchanged cell name is stored as the principal's fullname. Note that registry connect uses your local cell name for the primary name of the local cell's account principal. This name is stripped of the full pathname and prefixed with krbtgt, just as the foreign cell name is.
Table 23-1 lists additional information that you can supply to the registry connect command.
| Option | Meaning |
|---|---|
| -mypwd | The registry connect does not prompt you for a password for the accounts that you are creating; it generates this password randomly. However, you must supply your password with the mypw option as to validate your identity. |
| -facct and -facctpw | The system administrator in the foreign cell must provide you with the name and password of an account in the foreign cell. The foreign account must have the permissions that are required to create principals and accounts. You need the account to access the foreign registry in order to create the account that represents your cell in the foreign account's registry. The lifetime and creation quota of this account should be limited to only that necessary to complete the task. |
| -group and -fgroup | The group name to be associated with the account in the local cell (-group) and the foreign cell (-fgroup). These groups have no meaning for the accounts and are not associated with any users in the foreign or local cell. You must enter them because it is a requirement of the registry that all accounts be associated with groups. If the group does not exist, it will be created. |
| -org and -forg | The organization name to be associated with the account in the local cell (-org) and the foreign cell (-forg). These organizations have no meaning for the accounts and are not associated with any users in the foreign or local cell. You must enter them because it is a requirement of the registry that all accounts be associated with organizations. If the organization does not exist, it will be created. |
| -expdate | The time and date that both the local and the foreign cell's account expires, 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. |
The following sample registry connect command is used to create an account for the foreign cell identified by /.../dresden.com. The local account is associated with the group named cell_group_local and the organization named cell_group_dres and the organization named cell_org_dres. The expiration date for the accounts is allowed to default to none.
dcecp> registry connect /.../dresden.com \ -facct cell_log -facctpw music -group cell_group_local \ -fgroup cell_group_dres -org cell_org_local -forg cell_org_dres \ -mypwd cell_admin dcecp>
Note that the \ is the line continuation character.
The accounts and principals that are created by the registry connect command are given default attribute values listed in Table 23-2. These attributes apply to all foreign principals when they access objects in your cell. Likewise, the attributes of the account created for your cell in the foreign cell apply to all principals in your cell when they access objects in the foreign cell.
| Information | Meaning |
|---|---|
| Account Principal Name | The local cell name for the local cell's account, or foreign cell name for the foreign cell's account stripped of its full pathname and prefixed with krbtgt. |
| fullname | The cell's pathname. |
| quota | Set to none. This quota applies to all principals who use the cross-cell authentication accounts to access objects in foreign cells. This means, for example, that, if you change the object creation quota to 10, the total number of objects that can be created in your cell's registry by all foreign users who use the account to access your cell cannot exceed 10. It is not 10 per foreign principal. The object creation quota that is set for your cell's account in the foreign cell places the same restriction on the number of objects that your cell's principals can create in the foreign cell's registry. |
| description, home, shell | Set to blank. |
| server | Set to yes; that is, the account is a server that can engage in authenticated communications. |
| client | Set to no. |
| pwdvalid | Set to yes (valid). |
| acctvalid | Set to no (not valid). |
| postdatedtkt | Set to yes; that is, the account can be issued tickets with a start time in the future. |
| forwardabletkt | Set to yes; that is, the account can be issued a new ticket-granting ticket with a network address that is different than the present ticket-granting ticket. |
| renewabletkt | Set to yes; that is, the account's tickets can be renewed. |
| proxiabletkt | Set to yes; that is, the account can be issued tickets with a different network address than the present tickets. |
| dupkey | Set to yes; that is, the account's ticket can have duplicate keys. |
| goodsince | Set to the date that the account was created. |
| maxtktlife | Set to the registry policy. |
| maxtktrenew | Set to the registry policy. |
You can change the account that is created by the registry connect command at any time using the standard dcecp account operations. However, you should be aware of the following cautions.
Never set the account's pwdvalid attribute to no (invalid). For standard accounts setting the attribute to no, causes the user to be prompted to change their passwords at the next login. Passwords for cross-cell authentication accounts, however, are shared by the Authentication Services in two cells. If you change one, this synchronization is destroyed and cross-cell communications end. If you want to change the passwords that are shared by Authentication Services, you must rerun the registry connect command to recreate the accounts and create the properly synchronized passwords.
Generally, do not delete the accounts or the account's principals unless you are breaking the peer-to-peer relationship with the cell. If one of the accounts is deleted, you must run the registry connect command to recreate both accounts and restore the peer-to-peer relationship.