Active Directory Trusts
Active Directory supports a variety of directory topologies. While a small organization might have a single domain in their AD installation, larger organizations might have multiple domains in a single AD forest or even multiple forests. Frequently, organizations start out with a simple AD topology but find that over time, as a result of organizational growth (for example, through company mergers and acquisitions), their topology grows more complex.
Regardless of how they get there, organizations that have multiple AD forests often find it useful to create trust relationships between them. Trusts allow user credentials from one domain to be accepted by another domain. If company Acme, Inc. buys Spacely, Inc., instead of creating new user acme.com accounts for the new employees, it can simply connect the companies’ networks and create a trust relationship between the AD forests.
Although this sounds simple enough, trusts can add considerable complexity to Active Directory. AD supports various types of trusts. Most significantly, AD supports one-way and two-way trusts. If Acme sets up a two way trust between acme.com and spacely.com, each domain will accept credentials from the other. On the other hand, if Acme sets up a one-way trust between the domains, one domain will trust the other, but the reverse will not be true. With one-way trusts, the trusted domain is termed the outgoing domain whereas the trusting one is called the incoming domain. If Acme sets up a one-way trust between acme.com and spacely.com, with acme.com as the outgoing domain, then spacely.com will accept credentials from acme.com but the reverse will not be true.
Trusts pose challenges for applications that need to query information from AD. In order to read information from a directory, an application needs to have adequate credentials to perform the operation. Applications that have credentials only on an incoming domain will find that they cannot query data that resides on the outgoing domain directory.
How Likewise Enterprise Supports Trusts
Likewise Enterprise supports both one-way and two-way trusts. Two way-trusts are easy to handle; Likewise Enterprise is able to read directory information across forests without difficulty. When using two-way trusts, the Likewise Enterprise default cell spans across all domains and all trusts. A user enabled in the default cell can access any machine joined to the default cell of any domain in any forest and will be mapped to the same user and group id’s.
With one-way trusts, the Likewise Enterprise Linux/UNIX Agent cannot read the default cell information that resides on the outgoing domain. The Agent only has credentials that are valid for the domain to which it has been joined. When using one-way trusts, the Likewise Enterprise default cell does not span across these trusts. Note, however, that users from outgoing domains can still access computers that are joined to non-default cells in the incoming domain. The mapping information for these users is stored in the incoming domain where the Likewise Enterprise Agent has sufficient credentials to read it.
Other Approaches to the “One-Way Trust Problem”
There are other potential approaches to handling one-way trusts credential problems. One solution is to always store information on the incoming domain (regardless of whether one-way or two-way trusts are present). With this solution, an application never has to worry about lack of credentials on the outgoing domain. The drawback with this solution is that information needs to be duplicated (and maintained) in multiple domains.
A second solution is to provide applications with explicit credentials that allow it to read directories on the outgoing domain. When the application, running on a machine in the incoming domain, needs read information from the trusted domain, it uses these explicit credentials (a username/password or a Kerberos keytab) to perform the read. The drawbacks with this solution are twofold. First, providing these explicit credentials violates the “spirit” of the one-way trust. If the application was compromised, these explicit credentials could be used to attack computers in the outgoing domain. The second drawback of this approach is that it imposes an administrative burden. It is common practice to require that account passwords be changed periodically. Every time the password is changed on the account used for the explicit credentials, all the machines that are using those credentials will have to be updated.