Without a doubt, Active Directory is one of the most popular user repositories for modern day businesses. While Active Directory is not 'new', it is a very widely used system that works for a large variety of organizations, providing simple and manageable organization.
Many administrators and networks managers use Active Directory's built in function, the Active Directory Trust, to handle multiple domains, and they utilize AD trust as a simple method to organize a larger, possibly even continuously expanding domain architecture.
Active Directory trust is not the end-all solution for providing simple and manageable organization, and it is not by far the only option available for it. For network managers and administrators, the real question is whether to trust or not to trust Active Directory's trust.
To understand whether to trust Active Directory Trust, we have to first define what exactly is AD Trust. Firstly, Active Directory Trust is a sort of contract between two domains. It acts as a relationship between two user repositories for various reasons, but mainly, it enables users in one domain to access resources in another.
Active Directory Trust can be configured in multiple ways, the common setups being:
Additionally, to understand cross-forest trust relationships in Active Directory, you should also know how Microsoft defines their Active Directory logical structure. While there are a variety of setups, they work through a clear hierarchy, from top to bottom. In that hierarchy are: forests, trees, and domains.
Forests represent the complete Active Directory instance and are logical containers made up of domain trees, domains, and organizational units.
Speaking of which, trees are collections of domains within the same DNS namespace, including child domains.
Lastly, domains are the logical groupings of network objects such as computers, users, applications, and devices on the network such as printers.
Active Directory can provide security across multiple domains or forests through domain and forest trust relationships. Before authentication can occur across trusts, Windows must first check if the domain being requested by the user has 'trust' with the domain of the requesting account.
For trust relationships, the most common setup is implicit trust where default trust configuration is applied when an administrator creates a child domain within Active Directory. For organizational purposes, this is a perfectly acceptable trust setups, and it lacks many of the potential pitfalls found with the other trust configurations.
The benefit with using implicit trust is that it allows users to access resources from a separate, external domain without being registered there as well, meaning it includes the ability to share resources without needing to synchronize user accounts or increase user accounts in multiple locations.
Therefore, this function allows users to access resources from a separate domain without being registered there as well which includes the ability to share resources without needing to synchronize user accounts or increase the number of user accounts.
Not only does Active Directory trust act as a method of stopping account proliferation across multiple domains, but also enables Single Sign-on between domains.
Active Directory trust handles authentication through either the native Kerberos 5 protocol or Windows Challenge/Response (NTLM) where Kerberos is not supported, and the method of authentication plays off of established Microsoft protocols. Authorization relies solely on the proper configuration of Access Control Lists (ACLs), but an issue with using trusts lies within the act of trusting administrators in the trusted domain. An improper configuration of the active directory trust can possibly open up the entire domain structure to malicious intent.
Even though it is so widely used, Active Directory is not the most secure method of sharing resources. With default support for only two separate authentication methods, security takes a backseat to usability and access. For certain scenarios, the trust may remain as the most applicable solution, but in an environment where security is a primary concern, more so now than ever before, AD federation stands as a substantial improvement on the initial formula for multiple domain management.
Trusts established with external domains are primarily blacklisting models based on an open approach. Domain A opens its doors to users in Domain B with very little restrictions placed on which aspects of the domain are accessible to external users. With this configuration, access is permitted by default and requires more effort from the administration to determine who really should have access.
On the other hand, AD Federation approaches multiple domain management from the opposite direction: a whitelisting model.
There you have it: considerations to make when deciding whether or not to make use of the Active Directory trust, and an alternative method of achieving similar functionality with potentially better results. Of course, the realm of technology is always changing and what works today might not work as well tomorrow - that is the world we live in. While the AD trust is a great foundation, your organization may be better served with a solution that is prepared to evolve with the changing environment, to keep your domain structure and resources accessible and secure throughout the rising and setting of the tide. It's all about trust - so what do you trust more?