Now more about Active Directory domains in that tree‑like hierarchy.
The forest root domain is the most important one, that's where
your enterprise admin group lives and this is where the heavy
lifting of the forest happens, at least initially.
Some businesses actually will use the forest root for
management purposes, and then for your users and your
workloads, bring out child domains.
Again,
we're using domain name system DNS listening on TCP
and UDP port 53 for name resolution.
So we, therefore, have a DNS namespace that makes it easier for you to see
the relationship between the parent and child domains.
Now notice you can do a disjoint namespace.
You don't have to have your child domain of
company.pri, denver.company.pri.syracuse,
you know, you don't have to do that.
That's an architectural question how you're dividing your child domains
if you need to. Most of the time, in my experience,
it's by physical location. You've got your headquarters in the root and then
you have your branches defined by their geolocation. Some businesses will do
child domains on business unit levels, but again,
I would strongly recommend you simplify as much as possible,
especially given the high cost of a security breach,
so you can do a non‑contiguous or a disjoint namespace.
Again,
I would recommend against that, unless you're in the middle of a
migration and you just have to retain that disjoint name because it
makes DNS a lot more difficult to configure. You're using the
traditional delegated subdomain model, it's much,
much easier,
particularly when you're replicating your DNS zone or
zones in Active Directory itself.
But as you can see,
you can build out your tree to several levels and we've got these
two‑way transitive trust relationships among them.
So a user who signs into test.denver.company.pri can be given access
to resources in any other domain, and part of the DNS is lookups
travel from child domain to the parent.
You can actually create a shortcut trust relationship,
for example,
between test.denver.company.pri directly to company.com in
order to shorten that name resolution path,
but more in time, we'll get to trusts, believe we cover
that in the next module in more detail.
As I mentioned,
the domain controller is the authentication source. By default, your domain
controllers host your DNS zones with Active Directory so you want to think
about high availability for these, at the very least,
having more than one domain controller for each domain.
Now, whether you have single domain or multiple domain,
if you're broken out into Active Directory sites,
you'll also want a couple of domain controllers in each site
as well so that you can ensure that authentication requests
happen in a time‑efficient manner.
Speaking of which, as I said,
sites are mapped normally to the physical network infrastructure of your
organization and you'll see that in Active Directory, if you don't
already know, there are a number of tools that allow you to map those
locations and you can place your domain controllers associated with
particular sites and subnets.
And this is great, again,
because we want to give users and other security principles
that need to interact with Active Directory an efficient
communication path between them.
In other words,
we don't want somebody in Denver being authenticated in Las Vegas unless
Denver domain controllers are unavailable for some reason,
but notice that that will happen automatically,
that if the DCs are offline in Denver, then a user may be authenticated either
in Las Vegas or Phoenix depending upon how the knowledge consistency checker,
or KCC, component of Active Directory determines the lowest cost route to a
remote site for a domain controller.
Here is another graphic that just shows some of the flexibility that you have as
an Active Directory administrator in laying out your sites.
Now you might be wondering, how does this relate to Azure AD and running,
say, a hybrid cloud environment between local and Azure Virtual Networks.
The general guidance from Microsoft is to create sites for
your virtual networks. Even though you may have a very fast
connection from on‑prem and Azure,
maybe you have an express route circuit, still,
the guidance is to create sites for your Azure Virtual Networks, place those
domain controllers in those subnet objects in those sites and make sure that
you've got the Azure VNets involved in your sites and services topology.
Organizational units, like I mentioned, consist of top‑level containers that
are given to you by default, one for users and one for computers.
You cannot attach a Group Policy Object to these containers, but the idea is
that you can create a collection of organizational units.
Maybe you're doing it by, in this example,
finance users you're organizing by job role, but I've also seen businesses
that organize their OUs by location, or geo division, or organization
within the organizational chart of the company.
It's totally an architectural question that you and your team need to
decide, but those built‑in containers are just given as a starter and then
it's presumed that you're going to create OUs to organize your users and
computers for both delegated administration, as well as most efficient Group Policy Management and processing.