Let's take a look at Microsoft's current guidance with reference
to how you actually implement these groups,
whether they're built‑in groups or administrator‑defined groups.
Let's take a look at how we can integrate universal groups, global groups,
domain‑local groups, and individual users.
And this practice has really not changed too much over the last 20
odd years, so it makes a lot of sense for me.
Let's see what you think.
First, we have, as I mentioned before,
organizing your domain users principally by their job function
and access requirements into global groups.
And again,
although the membership of a global group is limited to the current domain,
you can include global groups and access control lists
across your entire forest enterprise.
So users go into global groups.
The global groups can go one or both of the following two ways.
If you're going to implement universal groups, in other words,
if you're in a larger multi‑domain environment,
you want to keep in mind two things.
One, you can do that.
It's nice to conveniently populate related workers across domains or even
across forest trusts into a universal group that you can give permissions to
once instead of having to do it a number of times.
But remember that the global catalog is required to
process any Active Directory logon.
But in particular,
one of the things that the global catalog also does is enumerates universal
group memberships. And it used to be more of an issue 20 years ago, but
depending upon how much available network bandwidth you have, if you have a big
organization with lots of users and you're churning or changing the membership
of the universal groups regularly,
then you've got Active Directory replication and global catalog updates to deal
with, and you can wind up with slower than expected logons.
So it's best to keep your universal group memberships as
static as possible or consider not even using universal
groups if you're in a single domain, single forest environment.
But anyway, that's an option.
The other option would be to populate your global groups
directly into domain local groups.
Remember that domain local groups exist and are available only to your domain
controllers, and we then can use or reference those domain local groups when
we're giving permissions and user rights to our users.
So you can see that separation of duties. You're going to focus
your authorization efforts at the domain local group level and
attach that to your applications, your services,
your files, and folders,
this sort of stuff, Group Policy assignments. Your users are being
organized into global groups, and that way, you can modularly patch in and
patch out global groups into those domain local groups without having to
modify any of your access permissions.
This is a good pattern, like I said. I did mention in the introduction to this
learning path that the Hybrid Cloud Administrator Certification is actually as
an associate‑level cert not intended for beginners,
but I do try to be as well rounded and complete of an instructor as I can. Anyway, let's get going.