Hi.
Welcome to this individual lesson on Active Directory
Tiering.
This is the second video in a series of two.
For the first part, we looked at Active Directory Tiering
and the theory behind it.
While in this part, we'll look into the actual implementation
of this.
I'll begin by a short demonstration, or rather
a drawing, just to make sure that the theory is understood
by everyone.
Then we can move into the environment
and do the practical implementation.
What we were discussing in the previous video
is that we'll take the Microsoft approach with having
three tiers by default.
I have seen an environment where the tiers can
grow quite a bit of up to 20, and that's really a lot.
Although, it gains--
Or gives, rather, a next level security
against potential theft, because you have different accounts
for different kind of access.
But if we take the three tiers, we'll
represent them by drawing them.
And we'll have tier two at the bottom, then tier one,
and tier zero is on the top.
You can think of these tiers as somewhat a military based
ranking where we have the generals on top
and the lower ranks on the bottom.
And by default, lower ranks are not
going to be able to go above and talk to the generals,
while the generals can give commands
to everyone underneath.
So what will the different tiers representing?
In tier two, we're going to have our most untrusted devices
and users.
So that would be our workstations,
our regular users, this is our normal employees
and their accounts.
And the reason why we had them here
is because these are the ones that are primarily phished,
or those of the users who download and then exploit
malicious files, and so on.
We also have this tier, the level
of administrative accounts.
So that would be tier two admins.
This is representing users workstations and also groups.
So each tier will have this representation within it.
Now, if we should move further in tier one,
we will consider tier one to be our normal member
servers in the domain.
That would be also the users that
have access to those servers.
So that is tier one users.
And we're also going to have a bunch of different groups
which are going to represent certain access
to those servers.
So for example, some users might need local admin rights,
others just might need more privileged rights.
So I would just say that we also have some groups in this tier.
And finally, in tier zero, we'll have our crown jewels
of our environment.
And if we take it as a general approach towards organizations,
this is going to contain our domain controllers,
our PKI infrastructure, there is going
to be a WSUS for updates of tier zero, and so on.
It will contain our tier zero accounts, tier zero users,
which are going to be users such as domain admins, enterprise
admins, and those really privileged groups
who should only be allowed to access our most important
assets in the environment.
So we will also have those privileged groups.
And I would just say, for example, that be domain admins.
Now, what we're trying to display here
is this kind of categorization.
Because the lies that we just drew,
we haven't really enforced anything.
Right now, we're just categorizing
what do we want to consider as a different tier.
And to enforce the tiers, we're going
to implement technical controls that
are going to forbid one tier from interacting
in another tier unless they're allowed to.
So what we're going to forbid, for example,
is that tier two users will not be able to connect to tier one,
and they will also not be able to connect to tier zero.
We will have a technical control which
forbids every tier two users from performing this action.
While on the other hand, tier zero users,
they will not be able to connect to other tiers in this design,
but they will able to control the other teachers.
So they have direct control over the tiers.
And now because we're going to deny this connection where
tier zero account is connecting to tier one or tier two
systems, that means the tier zero
account credentials are not going
to be cached in any other tier except tier zero.
So if one tier goes down--
Or rather, if you look from a risk based approach
towards this tiering design, we'll
see that a worst case scenario that can occur
is that a highly privileged tier based account is compromised.
So for example, a tier two admin might
get compromised that has access to big part of tier two.
But the worst case scenario in here
would be that only tier two can go down
while the rest of our environment
is actually still standing.
And now it's working, we can reduce from that point.
It's not like we are losing our interactive directory.
And what is better even is that we
will assume that at least one of our devices
can get compromised.
But with all of the active directory
checks that we have discussed so far in the course,
we'll try to make sure that, if one workstation is compromised,
then the damage, or rather the impact towards our environment
will be limited only to that one workstation.
And it's going to be very hard, or nearly impossible
for an attacker to move away or move laterally
from that workstation into other assets into the environment.
And for this tier model to work really well,
what is really important is device hardening.
And I'll give you an example.
Let's take tier two workstations.
I'll draw two different workstations in here.
So we're going to have workstation one and workstation
two.
Let's assume that an attacker from the internet
compromises workstation one.
Now, we will have this attacker living into the workstation
and having full control over this one workstation.
But because of the hardening that we have performed,
or that we should have performed,
this attacker will be running a slow, privilege-less user.
Even if the attacker escalates their privileges,
there will be nothing on this machine
that they can steal to move laterally to other machines.
For example, the built-in administrator accounts password
is going to be unique by using Labs in our environment.
So each device will have its unique Labs password.
Furthermore, what we could do as an action, and something
that I usually recommend, is that every workstation,
every device in tier two, should have its built-in Windows
Firewall configured to deny incoming connections
unless they're coming from a management server,
or they can just deny all connections completely.
So if we take workstation two, for example,
what we could perform, if we assume
that this is the firewall.
The firewall will just simply block
connections that are over SMB, over WMI, over PowerShell
Remoting, and over RDP.
So in the case of this, even if an attacker
was to compromise the privileged user,
they have no ability to move laterally in the environment
because none of our devices will accept that connection.
So just on network level alone, even if an attacker
had those credentials, they can't move laterally
in our workstations.
And this is where we can really see how hardening
can shine to our workstations.
But if an attacker was to compromise that workstation
and we have actual logging on it,
we will be able to see that the attacker is performing
all kind of reconnaissance actions
that he's trying to connect to workstations.
And even though that connections will be unsuccessful,
we'll still be able to see that.
And that's going to be a very easy way
for us to identify that there's attackers into the environment.
And I hope that this tiering model actually, really
starts to make sense now, especially when we
can see it drawn like this.
It's a really simple concept.
But just the ability to deny accounts to move around
different category systems, for example,
from trusted to non-trusted, it will really
prevent this from the credential theft of privileged users.
Now, in order to achieve this tiering, one way to do it
is by using Group Policy Objects.
And that is probably the most common way of seeing companies
doing it across the world.
But what we need to be aware of is that, to achieve this,
we need to have some kind of consistency
in our organizational units.
Because consistent OUs is going to be much easier to actually
push and define different things.
And one thing that I really want to show now
is an example of how we can structure
our organizational units to have a predefined OUs and different
tiers and naming conventions, so we
can follow all those naming conventions
across the different tiers.
So let's just look into tier two.
I'll just give this example, and then we
can see the full implementation once we
move on to the environment.
But this is just so you get the brief overview before we just
start showing the technical stuff behind it.
So if we look into an OU, everything
that is rectangular in this diagram is going to be an OU.
So we'll start by looking at tier two OU.
So we're going to have an OU called tier two.
And inside this tier two OU, we can create a few more
OUs in the structure.
Where we're going to have accounts,
we are going to have also groups,
and we're also going to have workstations for our devices.
Now, we can expand this even further.
In accounts, we can have a new OU for internal users.
Then we can have an OU for external users.
Another one for disabled users.
And perhaps, one for privileged users.
This would be privileged users within tier two.
Then in our groups, we will end up
having groups that are defined for applications.
And this is rather uncommon for tier two,
because we expect our applications
to be running in tier one, on our member servers.
But it could be the case that we have something going
on the workstations, and you want
to define it and structure it in here.
For other groups, we will also have groups that
provide local admin access.
So local admin.
This would be a unique group for each workstation,
and this is easy to script.
But generally, this is going to be
a unique group for each workstation that is
managed from Active Directory.
Then you can manage which local admin
on which device will cause the entire environment, simply
from managing it only in Active Directory itself.
So if you want to add someone--
Let's take an example.
If we have a device in our environment called Workstation
001.
And then the group under local admin
is going to be the host name of the device underscore admins.
So if we want to add someone to be local admin on Workstation
001, we simply have to modify only this group and add
the user inside.
And we have the ability to do this centrally.
And this is great, as you will see later.
Now, under the new OU of workstations,
we can create other OUs.
Depending on how big our organization is,
we might need to even divide this even further into say,
for example, countries.
So we can have Denmark, we can have UK, and so on.
U.S.
And if our organization is that big,
we might also need to split our internal employees
based on countries.
And doing this will give us the ability
to push out certain GPO restrictions per country.
It all depends on how deep we want to go with this.
But good structure is always beneficial.
Now, with similar approach towards organizing
our environment--
I'll move into the environment, just
to show you an example of how I have created a organization
ability structure, and then how I have implemented the tiering
so we can prevent and allow access to certain users
across different tiers.
All right.
So now I'm connected to our environment.
And in this case, I am assuming that our environment
is brand new.
We're building it from scratch, which is most likely not
going to be the case with you.
So to accommodate with that, I have
started to create a new OU on the top of the domain called
Tiers.
And this is something that you can actually
use in a environment which already exists.
But to achieve this, you have to move your Active Directory
objects into the right containers
that we have created for them now.
And that might be problematic based
on certain GPOs or other settings
that you might be pushing out.
So you have to be very careful if you
start moving your current infrastructure and the OUs
that you have, into these new layers,
because you have to test them before moving something
without testing before that.
Now into the Tiers OU, I have three different tiers
representing the default three tiers
that Microsoft recommends.
The most I have seen is 18 years of a company.
And that's because their administrators
were really afraid that a compromised administrator
account might lead to compromise of many devices.
So what it did is, basically every single type
of application they had, they considered
that a whole separate tier.
But their administrators ended up with 20 different accounts.
And that might be too much for some,
but the minimum that you should aim for is at least 3.
So in our tier two structure, we have the same OUs,
which I was just showing on the slides.
You have the accounts, computers and groups.
So under accounts, we will have disabled, external, internal
and privileged users.
And then for each of the users, we
will, again, have different countries.
As you can see here.
Now, it's very important to have a really good naming convention
across your entire domain.
So if we take, for example--
I'll be showing this across different tiers,
so you can see the difference.
Let's take our regular users.
Our naming convention for regular users
is that we'll simply use the first two
letters of their name.
First name, and the first letters of their last name.
And this is going to be across all our users of tier two.
So everything that has four character user name
will be regular tier two user.
That will be the same for Johnny Johnson.
In this case, the username is going to be JoJo.
Now, if we move forward, we will have privileged users.
And the name recognition for privileged users
is tier two underscore the first two
letters from the first name and the first two
from the last name.
And then this becomes really consistent,
because now we can also trace users
that have user accounts in different tiers.
And one thing that we can achieve from this
is, we can later on check whether users
in different tiers had the same passwords.
Because giving an administrator account 10 users,
but if he's using the same password on all of them,
he's essentially bypassing the added security from all tiers.
So it's very important for us to have a way
to verify that the same user is not
using the same password across all the different accounts.
But generally, this consistency will
help into automating most of this tiering.
It can be really easy to achieve if we have consistency.
If we look at the workstations, or under our computers,
again, we will have the different countries
so it matches with our design for the users.
And our naming convention for workstations is very simple.
It's just WS10-001.
And for each other workstation, we just increase this number.
Of course, this can be whatever you like,
as long as there's consistency behind it.
And now, the good thing about having this consistency
in workstations, is that we can achieve
creating this group, which is SG, which stands for Security
Group, underscore the hostname for our workstation,
underscore admins.
Now, if you want to control who should be admin to workstation
10 001, you simply have to modify this group in Active
Directory, and it will give access that user,
administrative access.
Then we can remove it from here as well.
To push out this groups into each of the workstations,
we have a very unique way.
Because in a Group Policy Object,
we can push exactly this line that
will resolve the hostname and the domain name
to the current one.
But it's only going to append the admins to the end.
So for each workstation, it's going
to resolve its own hostname.
So one single command will hit all our workstations
and servers, and resolve the correct values for all of them
at the same time.
With the same consistency, we can go forward into tier one.
Again, we have accounts, groups and servers.
And for expansion into Accounts, we'll
see similar OUs as previously, while now we'll
have also Service Accounts.
For internal users, we have a new naming convention,
which is going to be tier one underscore--
And again, using the first two letters of the first name
and the first two letters of the second name.
Again, we're keeping the consistency.
For service accounts, we'll name all service accounts with svc
underscore the server that they're being used for
and what is the application that they're running.
You can go forward and also add additional data.
For example, if this is a read user, you can at sql read.
In our case, it is an admin user,
and we only have admin user.
So it was not necessary to create more explanation.
But the username itself, will give us
the information of where this user is being used,
what it's being used for, and most importantly, that this
is a service account.
And again, having this consistency,
we can put restrictions on service accounts
as we go forward.
Where we can add service account into different groups
as we go forward, because we have this naming convention
that we can use all across.
And, I think, this is the moment to mention group managed
service accounts, which is a concept that
exists since Windows 2012, the main functional level.
And that's something that Microsoft
created as Active Directory managed service account.
And the difference is that that service accounts password
is going to be managed by Active Directory.
You, as an admin, you'll never have to know it.
And Active Directory will automatically
rotates the password without breaking
the way that services work.
It will ultimately also update things with services
that the service accounts are being used for.
Unfortunately, there are some limitations with this.
And that is primarily that this group
managed service accounts will work only
with Microsoft services.
So if you have services, such as external tools that you might
have purchased in your organization,
you might have to go back to the traditional way of having
these service user accounts.
But what is important for them is that they need
to have very strong password.
And we'll talk about passwords in upcoming video.
For our groups, again, we have the same naming convention
for server admins.
So for each server object, for each computer server
object in our environment, we will have this security group,
the hostname of the server underscore admins.
Then we can control host admins.
And actually, in this case, I'm only showing admins.
But what could be really nice to have as well,
is the same group or the same style, but for RDP access.
So for each server, we have the same group,
we'll give RDP access to that server.
Because not every user connected to a server requires local
underwrites.
RDP rights might be more than enough.
For the servers, we'll have multiple OUs again.
And the OUs are going to be structured
based on the application that the servers are hosting.
And this is usually good when you have hardening in place,
because you can push out different hardening
policies depending on the application
that you're hardening.
Because certain features might break one application,
but it might be just fine with another one.
So instead of having to live with not hardening something
because of one application, while the rest 200 applications
are just fine with it, you can have this approach
to take the different applications
and make sure that they'll support what they need.
For tier zero, we'll have pretty much exactly the same structure
with our accounts.
Now, we have Martin Rollin account again in here.
The naming convention though, is going
to be tier zero underscore.
And now, we have a naming convention
which is going to be unique but the same for each tier.
Unique, because we have the tier zero, tier one,
tier two underscore, but the username persists the same
across all tiers.
And the regular user is going to be just maro.
Service accounts will contain the same naming convention.
We want to give them svc underscore, to recognize
this is a service account.
External users are interesting, because occasionally we
need to have consultants or other parties that
are helping us.
So our naming convention for them is also important.
In this case, my suggestion is that we
have ex underscore the tier that the account should operate
in, and then again, the first two
characters of the first name and the first two
characters of the last name.
Now, moving forward, we will have
groups for local admin servers again
and different applications.
We will have our servers in tier zero.
And we will also have previous accessed workstations.
This is a concept we have not discussed yet in the course,
but we'll get into this shortly.
But these are essentially the workstations
that we need to use to access a tier zero system.
Because tier zero system is the core infrastructure
of our environment.
It is so critical, you want to have
different device that is the only device which
can access this tier.
Or, in many cases, this of course
can be devices for redundancy.
It doesn't make sense to be only one device.
Now, we have this tiering model, but how do
we control who can access what, and who can control what?
That brings us into our group policy tiering that we're
going to present now.
I have already applied Group Policy Objects
to the different tiers for the servers,
where I am applying different user right assignments for all
the different tiers.
And that is exactly what you can see now
as I am expanding through the different organizational units.
Now, let's start with tier two.
Let's look at the settings which are currently configured
in this organizational unit.
What we are going to see is that, when
we come into the allow and deny access,
we'll see that in Allow log on locally,
we're allowing users and administrators to login.
But also, at the same time, if we look at Deny log on locally,
we're explicitly denying log on.
We'll see that we have actually listed
all the privileged groups and all the tier zero accounts,
all the tier one accounts, and so on.
So, Account Operators, Backup Operators Cryptographic
Operators, Distributed COM Users, Print Operators,
Domain Admins, Enterprise Admins, all of our tier zero
accounts, all of our tier zero service accounts,
all of our tier one accounts, all of our tier one service
accounts, and Server Operators.
They are explicitly being denied to access this workstation.
So privileged users cannot login to this workstation.
So this immediately tells us that users from tier zero
and tier one cannot login to tier two.
And that is the case, not just the physical login,
but with login as a batch.
So these users cannot access this machine by running
a scheduled task.
They cannot be running a service.
They cannot login through RDP either.
And what is more, in fact, is that these users will not
be able to access our workstation over the network
as well.
So SMB, VMI, all these protocols,
they're not going to be allowed for our privileged users.
And this is how we deny access to our privileged accounts
from accessing workstations in the environment.
Now, I'm already mentioning groups
that are showing all our tier zero accounts and all
our tier one accounts.
These groups I had already created in our structure,
which you might have seen.
They are located under the groups OU for each
of the different years.
Here I have SG All Tier zero Accounts,
which will contain all our tier zero accounts.
So we can put a restriction to all tier
zero accounts immediately, just by referring to this group.
Now, there are multiple ways to maintain
the membership of this group.
Something that is automated is that you
can create a PowerShell script, which runs every six minutes,
say, every 5, or 10 minutes, or 15 minutes in your environment.
Checks that, if an account starts with tier zero
underscore, or X tier zero underscore, then
that account will automatically be added
to be a member of this group.
And that's how the consistency that we were talking about
before is becoming really helpful for us.
Because we can automate maintaining this membership
and applying our different tiering
restrictions to our accounts.
And now, similarly, for tier two accounts--
Sorry, for tier one accounts, we'll
have the same restrictions.
But the difference now, is going to be that we have now tier two
accounts and tier zero accounts that cannot access tier one.
And, of course, that just makes sense to everything
that we have been discussing so far.
Similarly, tier one will have the same,
but now the previous groups are gone.
We allow the previous groups to actually access tier zero.
There are some privileged groups we simply
don't allow, because these groups should just not
be used at all.
But if you look into domain admins and enterprise admins,
we allow those groups to connect to our tier zero systems.
And, of course, it's highly recommended
to create your own custom groups that
will provide only the access that you may need,
instead of using the default groups.
Because the default groups are just way too privileged.
There's many hidden privileges that you're not
aware of when you assign someone.
Let's take, for example, the Account Operators look.
I hear many administrators saying
that account operators is a good group because they
can go and reset the password to many users
and they'll just inherit that right.
But, while that is true, they will also
inherit the right to modify all the users which
are located under this Users organizational unit.
And that is crazy, if you think about it.
Because account operators will be
able to change now the password for the account administrator
as well, which is placed here by default,
or the MSO account, which is the default
account for performing password synchronization with Azure AD.
And this account has the ability to act as a domain controller,
it can do [INAUDIBLE].
So an account operator has the ability
to change the password on this account,
and essentially steal your entire Active Directory.
And this doesn't make sense because account operators are
not as privileged as domain administrators,
but they can gain this right, and essentially
breach our tiering model.
The last thing that I wanted to mention here and discuss
with you, is that now we have the ability
to use this Group Policy Object to manage
who is local administrator on our devices.
And in this case, we can set the built-in administrators group
to have all its members deleted, whether the member is currently
a user or groups, and then set new members who
should be local administrators on our devices.
And in this case, we're setting that SG underscore
computer name underscore admins, should
be set to all workstations.
And again, the great thing about this comment
is that computer name will get result
to the hostname of the machine.
So each machine will dynamically assign its own group
to be local administrator.
And this is absolutely fantastic.
Then we have the group SG LA All Tier Two.
This group is going to be set to be
local administrator on all workstations
across the entire environment.
And I don't really recommend using this group,
it's only really for emergency purpose.
For example, if you get compromised,
or if you need some kind of disaster recovery
team on your workstations and you need access
to many workstations at the same time simultaneously,
you can add yourself to be a member of this group
and gain that access for a limited time.
What I also recommend is that you add this group,
so that members of this group are not
allowed to access workstations remotely.
They have to be physically in the machine
or utilize a tool, such as a Team Viewer or one
of the other tools that has this ability,
and can let you perform local login,
even though you're coming from the network.
So let's demonstrate our tiering in action.
I will connect now to workstation--
I want demonstrate in the workstation
because it should be sufficient to showcase how this works.
So what I'm going to do first is that I
will try to log in with the administrator
account of the domain.
So that would be prod/administrator.
Now, this account is a member of the group domain admins,
and that means this account should not
be allowed to log in.
So if you try to log in, you will immediately get an error.
This sign-in method you're trying to use is not allowed.
And that'd it.
They simply cannot access the workstation.
The workstation will deny access to the account,
even though this account is domain admin.
And this is how we can enforce that this account, essentially,
doesn't get used on our one privileged devices.
Now, let's use a regular user and try
to login as this account.
I wanted to show you how our GPO has applied
across the workstation, and has also taken into effect
the different local admin groups, which
we want to be assigned here.
One thing which I didn't mention before
is that the account administrator will always
be a member of this group, regardless
of whether we define that account in the Group Policy
Object or not.
We did not define the accounts explicitly,
but it's implicitly being a local admin group.
So if I run the command net localgroup administrators,
I get a list of the users and groups
who are members of the local built administrators
group on this workstation.
Running the command, I will get Administrator, our workstation
specific group, and the group that
is local admin on our workstations.
And this really works the way we expect it to do.
And that's fantastic, because now we
can manage local admin groups.
And even if someone escalates and adds themselves
to this group, next time Group Policy Objects runs,
they'll get deleted.
And the built-in administrator account,
even if someone obtains the password, or the password
hash for this account, if we're managing this with Laps,
the password will be protected automatically.
And they usually recommend that the password of Laps
is rotated every day.
It could be the case with you that you
might want to have more local admin groups,
or they could be different.
For example, if you have workstations
across different countries, and helpdesk
for each of the countries, then you
want that helpdesk to have local admin rights, perhaps,
only for that country.
So you can define the group only for the country,
and it's going to be applied only
on computers in that country.
And applying these GPOs is going to be very easy
because we have that consistency across the naming convention,
but also we have defined the--
Or we have structured our organizational units
in a way that is going to be very
easy to apply certain GPOs to the different organizational
units.
This is pretty much all there is behind tiering.
The concept is very easy, but yet, it's a very effective
to prevent privileged users from accessing
non-privileged devices, caching their credentials,
and then allowing attackers to abuse those cached credentials.