Dig into Trusts
Outline
Trusts
are a feature of Active Directory that make multi-domain environments possible
by enabling users in one domain to be authenticated by a domain controller in a
different domain. The basic facts concerning trusts are well-known by any
Active Directory administrator, namely:
·
Trusts
between domains within an Active Directory forest are always two-way and
transitive.
·
Trusts
between forest root domains (i.e. forest trusts) can be either one-way or two
way but are always transitive and establish a trust relationship between every
domain in each forest.
·
Trusts
between one forest and a specific domain in another forest (i.e. external
trusts) can be either one-way or two way but are always nontransitive.
·
Trusts
between an Active Directory domain and a non-Windows Kerberos realm (i.e. realm
trusts) can be either one-way or two way, and they can also be either
transitive or nontransitive.
·
Shortcut
trusts can be created between two domains to improve user logon times between
the domains, for example between a domain in one domain tree and a domain in a
different domain tree in the same forest. Shortcut trusts can be either one-way
or two way and are always transitive.
Given
all of the above, what else do we need to know about trusts?
Scripting trust relationships
Trusts
can be created using the New Trust Wizard, the Netdom command-line tool, or
Windows PowerShell. However, there are some caveats. For example, the TechNet page for the Netdom trust command indicates that
you can’t use this command to create a forest trust between two forests.
However, as this article in the TechNet Wiki indicates you can use a
Windows PowerShell script to accomplish this. You can also find more
information about this in this post on Spat’s WebLog, and there’s a script called AD Trust in the TechNet Script Repository
that you can use to create one- or two-way trusts between two domains or
forests.
Trusts under the hood
Trust
relationships are represented within the Active Directory directory database as
a type of object called trusted domain objects (TDOs). Each trust relationship
that is created is associated with a unique TDO that is stored in the System
container of its domain. The attributes of the TDO enumerate the names of the
domains involved, the type of trust created, and whether the trust is
transitive or not. Forest trusts also have some additional attributes. This archived TechNet blog post from 2009 shows how to view
the properties of TDOs.
You can
also use the Get-ADTrust cmdlet of Windows PowerShell in Windows Server
2012 R2 to display all trusted domain objects in a forest or having
specific characteristics such as TDOs having a specified trust partner. There
is also a version of this cmdlet called Get-ADTrusts.ps1 (note the plural) that
you can download as a script from the TechNet Script Repository
which you can use on Active Directory environments running on earlier versions
of Windows Server. Carl “The Accidental Citrix Admin” Webster says however that
he has identified some issues with the Get-ADTrusts.ps1 script in the TechNet
Script Repository, and in this post on his blog he has created his own version of the
script to address these issues.
Trusts and Kerberos authentication
Kerberos
v5 is a mutual authentication protocol used by Active Directory to verify the
identity of users and network services. Trust relationships make it possible
for Kerberos authentication to be extended beyond the domain to other domains
in the forest. But what about authentication beyond your forest? Jorge de
Almeida Pinto has an excellent series of posts that explain how you can extend
Kerberos authentication so it works across an external trust i.e. a trust
between your forest and a specific domain in a different forest. You can find
the final part of his six-part article here and it contains links to the earlier articles in the
series. Note that Jorge’s method only works when the two forests both have
domain controllers running at least Windows Server 2008 R2. Also note that as
far as I know his approach is not officially supported by Microsoft, so use it
at your own risk.
Here are
a couple of other helpful resources that may be of use if you want to use
Kerberos over an external trust:
Trusts between organizational units (OUs)
In
Active Directory, a trust is basically a relationship between two domains, or
two forests, a forest and a domain in another forest, and so on. But forests
and domains aren’t the only “structural” elements of your Active Directory environment,
there are also elements called organizational units (OUs). You can create
hierarchical structures of OUs within each domain to organize the user and
computer accounts and other Active Directory objects in the domain. You can
then link Group Policy Objects (GPOs) to each OU to manage, control or lock
down what those accounts can do or not do.
So, what
about trusts? Can you create a trust relationship between, say, an OU in a
domain of one forest and an OU of a domain in a different forest? Unfortunately,
trusts can’t be created for OUs, but there is a kind of workaround available
called selective authentication that provides a way to control which groups of
users in a trusted forest can access shared resources in the trusting forest.
Basically as this TechNet article explains, selective authentication
allows you to limit the scope of a trust relationship so it applies only to the
Active Directory objects you explicitly specify.
But should you trust another forest?
Trusts
between forests are usually implemented in situations like where one company
acquires another or merges with another. Are there any risks involved in
creating trusts between two forests? Of course, there are, because you’re
basically giving the other company the keys to your kingdom. Even if you’ve
legally acquired the other business, it doesn’t mean you should automatically
fully trust their IT staff! So, before you attempt to create an inter-forest
trust or implement something like selective authentication between two forests,
be sure to read the TechNet article Security Considerations for Trusts.
Trusts between geographically separated forests
Let’s
say you have two forests, one in North America and the other in Asia, and you
want to establish a forest trust between them. It would be nice if you had a
high-speed dedicated leased WAN link connecting the two networks, but you don’t
have that because it would be too expensive. What can you do?
Your
best solution would probably be to create a point-to-point VPN between the DMZ
of one forest with the DMZ of the other forest. You should be able to do that
easily if your DMZ in each forest is using an enterprise-grade firewall
appliance. Once you’ve done this, you should be able to create the trust
between the two forests.
Remote Desktop Gateway and trusts
RD
Gateway is basically a server used as a gateway between your corporate network
(corpnet) and the Internet. RD Gateway is designed to allow authorized remote
users to connect to computers on your corporate network from any computer that
has an Internet connection. RD Gateway does this using Remote Desktop Protocol
(RDP) and Secure HTTP (HTTPS). An important consideration concerning trusts is
that RD Gateway doesn’t support accessing resources from non-trusted domains;
they should at least have a one-way trust between two domain controllers
configured. And if you want to extend your domain into your DMZ in a way that
supports RD Gateway, you should read through this article from Windows IT Pro.
System Center Configuration Manager and trusts
Say you
are using ConfigMgr in Forest A to manage the servers and virtual machines and
other systems in Forest A. You then create a trust between Forest A and a
second forest named Forest B. Can you use ConfigMgr to manage systems in Forest
B? Yes, you can, with the following caveats:
·
You’ll
need to create a new client push account in Forest B and add it to the local
admins group of the systems in Forest B.
·
You
may need to open additional firewall ports in the DMZ of both forests.
There’s
more to it than that however, so you should also read through the four blog posts by Neil Peterson who is a Microsoft Premier
Field Engineer (PFE).
Got questions about trusts?
If you
have any questions about trusts, the best place to ask them is the Active Directory Domain Services forum on TechNet.