Active Directory has been around since Windows 2000 Server.
Way back in 1999 Microsoft introduced this.
Prior to Active Directory, we had the Windows NT flat domain space.
Active Directory as an LDAP store just has so many advantages.
We need to review now the logical and physical components of Active Directory.
Logical components begin with the forest. This the outermost
authentication boundary of your environment.
Businesses that are truly siloed may decide to have multiple forests
and optionally build trusts between those forests.
This is, as I said, the topmost,
outermost ring of the Active Directory ecosystem.
The forest consists of one or more domain trees and individual domains.
The domain, again, is a security boundary within the forest.
And we'll see as we go on in this module and the next module,
in particular,
the trust relationships that are defined by default within a domain tree.
The tree signifies a hierarchical structure, and that's absolutely true,
as we'll see.
The schema is a forest‑wide construct that refers to the specific rules
and regulations of your forest in Active Directory,
in particular.
In other words,
what are the allowed properties or attributes for all
of your Active Directory objects.
Your users all have a number of schema, properties,
so do your groups, your computer accounts.
We can extend the Active Directory schema in the forest,
but we've never been able to delete the modified schema.
You can deactivate a schema extension, but you can't remove it, so
it's obviously a very highly privileged task,
indeed.
An Active Directory partition is a way to subdivide what is
replicated among your Active Directory domain controllers.
This isn't as big of an issue as it was, say, 15 years ago.
Nowadays, high‑speed access, network access,
both local area network, wide area network,
and the internet is almost a given.
But this used to be much more of an issue to where if you had
multiple sites with domain controllers in each site,
you might have low‑speed connectivity to some sites,
so you'd want to modify the volume of data that's being replicated.
We still do have that ability to control domain controller
replication by using these built‑in,
as well as administrator custom‑defined application
partitions in the Active Directory database.
The organizational unit represents a container that's
used for organizational purposes, obviously,
of your user, group, and computer accounts,
but also it's central for delegated administration.
You may want to give your support staff,
for instance, or a delegated manager certain privileges,
not to everybody in your Active Directory domain,
but just a subset of users or groups.
This could be done at the organizational unit, or OU level.
A container is a parent object that normally we've got a couple.
There's more than just users and computers,
but those are the main ones that you cannot really do much with.
They're just built‑in containers that serve as a default
store for your user and computer accounts.
But you'll absolutely want to create an organizational unit
structure and move those accounts into those OUs.
Another thing I almost forgot to mention is Group Policy‑based management,
whereas we can link Group Policy Objects or GPOs to organizational units.
We cannot do so on those containers.
So that was the logical structure of Active Directory physically.
The physical components would be your domain controllers.
These don't have to be physical servers,
they could be virtual machines, but you need to think physically
about where those domain controllers are placed and the Ethernet
networks and subnets they're on,
as well as their connectivity throughout your local site,
as well as other sites in your infrastructure.
The Read‑Only Domain Controller, or RODC, or R‑O‑D‑C, is a
specialized kind of domain controller that has a read‑only
copy of the Active Directory database.
We'll talk more about RODCs later.
The global catalog is essentially a lookup service.
Again, times have changed where nowadays it's recommended,
Microsoft recommends that unless you have a compelling reason to not do it,
you should have just a single domain in your forest and enable the
global catalog on all of your domain controllers.
The global catalog contains a partial attribute set of all
of the objects across your entire forest.
Global catalog is an important service because it needs to be available to
process logons and to enumerate a user's group memberships.
But if you're enabling the global catalog on every domain controller,
you have that base covered.
A data store refers to the sys file directory where you can replicate file
system objects like logon scripts among domain controllers.
A site refers to a physical collection of high‑speed links.
So if your business is centered in Chicago,
let's say, in the States, in one building,
pretty easy. You've got one collection of subnets,
but then you have a branch office in Los Angeles.
Now, depending upon how you're connecting those offices together,
there may be enough bandwidth to where you still could do a single
site, but you have the ability in Active Directory to model the
physical infrastructure of your network and then control the scope of
replication that happens among those sites.
Because we want to think about,
as your domain controllers are working from day to day,
you've got administrators creating, modifying,
and deleting objects, your domain controllers need to be able to share those
updates so that all of those DCs are in sync with each other.
Lastly, within the site, we have our IP subnets.
Now, don't worry,
the AZ‑800 and 801 doesn't get into the weeds with IPv4 subnetting.
That isn't the scope here.
There is one certification now,
AZ‑700 is the exam; it's the Azure Network Engineer certification.
That one does deep dive into subnetting and IP,
but here we're just concerned more from a higher‑level perspective.
As I mentioned,
the Active Directory forest is the outermost
isolation layer in Active Directory.
Now,
some businesses that are siloed where they want to manage their own
users and groups but still keep central administration,
you might have a single forest with multiple domains.
You see,
for instance, on the left side of the slide we have a forest root domain.
This is the first domain that's deployed in a new forest.
And then we have a child domain, and notice the DNS‑like naming syntax.
That was a big change that Microsoft gave us when
they invented Active Directory, this using DNS for name resolution,
and then you have this hierarchical structure with your domains.
So the multi‑domain single forest model gives a certain level of
isolation, but you still have that trust relationship between the
child in the forest root domain, in this case.
You might have a single forest with multiple domain trees.
That happens a lot of times with migrations and domain consolidations.
But Microsoft's official guidance nowadays,
in 2021, 2022,
is that because a single Active Directory domain can scale to
billions of objects, or at least a billion,
I think, at last check,
unless you have hard and fast isolation and administration boundaries,
you might just want to simplify and stay with a single domain,
single forest.
Now,
it is certainly eminently possible to have multiple forests within a single
organization and optionally build trust relationships between them for
resource sharing and selective authentication,
this kind of thing.
Again, this is appropriate sometimes when a business has separate business units,
maybe through an acquisition where the acquired company is
going to keep or retain its existing forest,
at least for the time being.
There are tools available you can use to migrate domains
out of one forest and into another, but 800 doesn't get into that, 801 does.