Manage Active Directory Domain Services Users and Groups.
The user account refers to a human being in our organization within our
Active Directory domain. We can use graphical tools like Windows Admin
Center or Active Directory Users and Computers or Active Directory
Administrative Center to create accounts.
But in the name of DevOps and automation practices, we should take a look
now at using the Active Directory PowerShell module.
For example, we use the New‑ADUser cmdlet here to define a new domain user.
Now if you look in the docs,
I give you links in the exercise files where you can see or you
could just do a Google search for a New‑ADUser to visit the
official docs page where there's lots of examples. There are some
properties that are required.
Of course, you're going to need name, data,
SamAccountName, or the short name,
the AccountPassword. You see the ChangePasswordAtLogon $true is critical
because the user is not going to keep their starter password permanently, and
we want to make sure that the account is enabled.
There's a whole bunch of optional properties that you
can add to your New‑ADUser definition.
It depends on how granular you want to be at the outset.
Now our individual users who represent our human beings and
our organization are all well and good.
But when it comes time to giving those folks authorization to
domain resources, we're going to organize those users into groups
and then put groups into groups, as the case may be. Active
Directory has two group types.
One is called the security group.
This is what we're concerned with in this course. This is
about assigning permissions and user rights.
Then we have distribution groups.
These are used strictly for email where you can have an email recipient
mapped to a user, account, and an associated email address.
Active Directory groups operate on four different scopes.
We have the local group that you'll find on standalone
workgroup servers and workstations.
These groups have visibility only within that local machine.
Once you have an Active Directory domain up and your domain controllers
are running, there are built‑in domain local groups, and you, of course,
can create your own that exist on the domain controllers across the
domain and have scope or visibility.
You can use them throughout the domain.
The main tool for organizing your end users would be the global group, which has
forest scope. I'm going to give you some additional info on that. Specifically,
we use the global group to consolidate users who have similar properties. It
could be part of geolocation or job role.
You can assign permissions to a global group anywhere in your forest.
If you're a multi‑domain forest or single domain,
it doesn't matter, and also across forest trusts.
However,
it's important to know that the membership of global
groups is limited only to the local domain.
Global groups can contain user groups,
computer groups, and other global groups from the local domain.
Lastly, we have the universal group.
This is used chiefly with multi‑domain networks, and there are
implications to universal group membership,
particularly as you get sprawl of multiple domains,
multiple domain trees, and multiple forests that we don't
need to get into at this point.
But a couple of things, actually, to keep in mind with universal groups
is that the membership can be anywhere in the forest,
including across forest trusts,
and we can assign user rights and permissions anywhere in the
forest, similarly to how we can assign them to global groups. Let's
sort out the built‑in administrator groups.
The local administrators group appears on non‑domain
servers and workstations, in other words,
those that are in a workgroup environment.
In an Active Directory Domain Services domain,
each domain controller has its own domain local group.
Again, these are shared across all DCs.
The Domain Admins global group is going to be, again, domain‑specific.
This is the easiest way to delegate administrative privileges
in your domain. In the forest root domain,
you have the Enterprise Admin global group.
This is the most critical administrator group in your forest because all
of your top‑level privileges are requiring membership in the Enterprise
Admins group. The Enterprise Admins group is automatically made a member
of the administrator's domain local group in every forest domain across
your enterprise.
When you're doing very high value operations like extending the Active
Directory schema, that's going to require Enterprise Admins.
You're working with sites and services and trusts.
These require highest privileges.
So from a security perspective,
you want to control the membership of Enterprise Admins, above all else.