Alright, in this demonstration,
we're going to work with built‑in groups, and we'll create a group and
show its scope of action in terms of that hierarchy I mentioned a moment
ago in terms of global groups, universal groups, domain‑local groups and
how that factors into permissions.
So we are on my Windows 11 desktop machine.
And I actually want to start by opening the local
computer management MMC console.
And to let you know, hopefully you know this already,
but when you domain join a client box,
you'll find that the Users group on that machine is
automatically populated with the Domain Users global group in
the domain in which this workstation belongs.
This is what allows domain users immediately to be able to sign on
to any domain‑joined workstation by default.
Likewise, if we look at this workstation's local Administrators group,
we can see that by joining the domain, the domain's
Domain Admins group now is in scope.
This machine is part of the timw.info forest root domain.
That's why it says TIMW\Domain Admins.
But let me bring up Active Directory Users and
Computers, and let's take a look here.
If we look at the hierarchy, again,
I'm on timw.info rootdc1, specifically. Depending upon
how you've configured permissions,
we can right‑click and change to browse to another domain in the hierarchy.
In this case,
I've got my child.timw.info and my timw.info domains. We see here
the built‑in Computers and Users containers.
Those are good to start you off with, but you're going to
want to have organizational units before too long so you can
start applying group policies.
Notice that your Domain Controllers objects are in an OU out of the box.
But in Builtin, we have all our subadministrative groups and
honest‑to‑goodness administrative groups. Particularly, we have the
Administrators domain local security group that has a default membership, as
you can see, of Enterprise Admins and also the Domain Admins.
So once again,
all of your domain controllers will allow domain admins
full privileges on those machines.
Enterprise Admins is, by default, located in the Users container.
This, like I had mentioned a few times, is the most
important group in your forest.
It's a universal security group.
And the only account that's going to be in there by default is your
original domain administrator from your forest root.
And that administrator, in my case, doesn't use the well‑known
name administrator for an account name. Mine is Tim instead.
That's a good best practice, by the way,
is to rename the built‑in administrator so it's not administrator
because anybody who's leveraging an attack against Active
Directory is going to try high‑privileged accounts, and you can't
get higher than administrator.
So, I wanted to create an organizational unit here.
So let me right‑click my domain, come down to New, and
let's pretend that we're supporting a data team that will
be distributed across our forest.
And in our case, remember that we have an acquisition.
So we have a bidirectional forest trust with acq.com, and we want all of our
data team members to be able to work happily together.
So I'm going to call this organizational unit HQ Data Team. And the OU,
organizational unit, is simply a container into which user accounts and
computer accounts go. Now to create a user account, I'm going to actually
use another tool just to make sure I'm covering all of the different tools
to some degree or another.
Active Directory Administrative Center never really caught on in my
experience the way that Active Directory Users and Computers does. It's
going to focus on the local domain here, but if you want to add in
references to other domains in the forest,
we can go to Manage,
Add Navigation Nodes, and I can connect to the child domain and
bring in those OUs and containers if I want to. Here we can see our
HQ Data Team organizational unit, and I'm going to right‑click and
create a new user account.
Let me stretch this window out so we can see it more.
I'm going to populate it,
give it an initial pass. Some important points I want you to see
here is the User Principal Name is in the format of an SMTP
email address, but it's really not.
We're going to see in the next lesson that you may have to add an
additional UPN suffix when you're doing hybrid identity with Azure AD. The
SamAccountName has been that old, old Windows NT format where you have a
short 15 character or fewer logon name, and then backslash, and then just
the NetBIOS portion of the domain.
I like UPN, not only because ideally you've structured the UPN to
resemble or match the user's SMTP email address, but also because it
easily identifies which domain houses that user.
We've got password expiration options over here. Create in,
it's giving us the distinguished name syntax that we've got,
OU=HQDataTeam,DC=timw,DC=info.
That's true.
I want to protect this object against accidental deletion, and I'll
leave just about everything else at the default.
I did populate the email field here, and the job title
for Brett is Nashville Data Team Lead.
So I've created a new user in the OU. So far, so good.
Well, let's switch back to Users and Computers, and let me
refresh my view so we can see Brett. And let's go ahead and
build out some groups now. Number one,
I'm going to right‑click, and in the HQ Data Team OU, I'm going
to create a group, and we're going to make it a global security
group called Nashville Data Team.
And the idea here, again, is that you're aggregating user accounts that
are scoped to the domain, and the global group will be accessible across
the forest and even across forest trusts.
So let's go to Members, and let me look up Brett's
identity here. Click OK. So far, so good.
Now we can stop there if we want to.
We don't necessarily need to create a universal group.
So at this point, we have an OU to contain our relevant team
members, we've got an identity for a user, and we also have a
Nashville Data Team global group.
What if we wanted to create a super group that contains
the data teams from all of our domains?
Let me do another group, and I'll call this Global Data Team,
and make this a universal security group.
So this means I can populate this Global Data Team universal group with members,
not only from the local domain.
First, I'll start with the local domain.
Do a search for Nashville, and bring in the Nashville Data Team.
And now in addition to the Nashville Data Team global group,
let's add the data team from the child domain, the Memphis Data team.
Let's go to add. I've already created that group, by the way.
So in the selection screen,
let's make sure that our Object Types filter includes Groups.
Yes, it does.
And then for Locations, we're going to search our directory
here for child, and we've got Child Data Team.
Let's do a search for m, and there we have it, Memphis Data Team.
See how that works? So we've organized our
site‑specific users into global groups.
And now I've created a universal group that I can add to access lists
all around the forest and across the forest trusts.
You'll use your domain local groups for permissions.
So now what I'll do is I'll create a new group, and this time I'll make a
domain‑local security group, and I'll call this Data Managers.
So presumably, I would give high privilege to anybody on access control lists,
maybe for file shares and other assets, and it would just be selected
folks. Or actually, let me create one called Data Readers because that
one would presumably be more wide spectrum.
So I've got domain local. And now what I can do if I want to
make the Data Reader security group include as wide spectrum as
possible in terms of our data team,
I can just simply nest the universal or global group inside. Because I
want to reach across domains and potentially even forests, I'm going
to add in the universal group right now.
I'll do a search in my local directory for global, and there it is.
Click OK, and we're good to go.
And just to demonstrate that scope, remember that we have a forest
trust going on. Let me go back to our universal group, Global Data
Team, and let's say we want to add in the folks in the acq.com
domain across the forest trust.
I'm imagining they're in Orlando, Florida.
We may have global or universal groups defined over there for their
data team that want to be data readers or we want to give them data
reader access in our domain environment.
So in this domain‑local security group, let's go to Members, Add.
And if we go to Locations, you see that we can stretch across that forest trust.
Remember that resources trust accounts.
So in this case, timw.info is the trusting domain,
and acq.com is the trusted domain.
Let me do a search for Orlando.
I didn't find that.
Let me think about what that structure is over there.
Ah, yes.
I called it ACQ Data Team.
So let me search the acq directory for acq, and now we can see that in our
Data Readers domain local group, on which I'm going to grant permissions to
resources, I'm able to bring in global and universal groups from the local
environment and even global or universal groups from across the forest trust, as you can see here.