Hi.
Welcome to this video lesson in which
we're going to talk about the Protected Users Group.
Once we discuss the protected users,
we'll actually show a small demonstration that demonstrates
a problem or rather a feature, it's
an expected behavior that occurs for members of this group.
But what I've seen across different environments
is that it's causing a lot of troubles,
and we'll look into that afterwards.
So the protected users group as stated by Microsoft
was designed as a part of a strategy
to manage credential exposure and minimize that, essentially,
in the entire environment.
Every member of this group automatically
inherits certain protections that
will prevent these accounts from caching credentials
and essentially reducing the ability of an attacker to still
produce users' credentials.
Now, the group originally came with those domains 2012R2
and later it was backported to 2008R2.
Even though it was backported, some of the functionality
is just partially there, it's not as good as in 2012.
When we talk about protection by the protected users group,
this protection is divided into different categories
or domains, that would be protection at the host device
and protection at domain level.
Now, I'll go through these two domains
just to show you the actual protection
that the group provides.
So from a host protection perspective
the credential delegation, CredSSP,
will no longer cache plain text credentials of users
at the endpoint, which was the case before.
So if a user RDP's into a server,
the credentials will be cached in plain text.
Right now if a user RDP's, nothing
is going to be cached at the LSASS process.
So tools like Mimikatz, they should not
be able to export any credentials of produced
users that are a member of protected users.
With Windows 8.1 and server 2012 R2
double digest will also not cache plain text credentials
when users are a member of this group.
NTLM will not cache its NTLM hash.
And that's just absolutely fantastic
because we're not talking about only not caching plain text
credentials but we're also not caching NTLM password hashes.
Then Kerberos will no longer use DES or RC4
for users that are a member of this group.
And this is where we start seeing problems
because many applications rely on
or they require RC4 to authenticate their users.
And it's a whole different question
of why would you have an administrative account needing
access to an application such as something that requires RC4?
But the fact is that in many enterprises
this is what people do and when a user is a member of protected
users it might cause applications
to not authenticate or SSO will not work.
I've seen multiple organizations where SSO broke immediately
for users that were a member of protected users
because that SSO relied on RC4 to be allowed with Kerberos
authentication.
The next one that is problematic is
that you can no longer send to machine that is not
on the network, you need actively
to contact a domain controller.
Think about before when you give a workstation to someone,
you first ask them to sign-in once so their profile will
be cached and then they can sign-off afterwards as well.
If you're a member of protected users you cannot sign offline,
you can only sign when you're on the network.
And with that which also comes as domain protection,
and we're going to this in a second,
is that NTLM authentication is not
going to be allowed if you're a member of this group.
So does it sound crazy?
It probably does because now we're really
thinking and talking problems.
Many tools and programs will utilize NTLM to authenticate,
they just simply don't support Kerberos.
Most common ones are VPN providers.
So if you have a VPN likelihood to be using NTLM is very high.
And you will not be able to use that with a user that
is a member of protected users anymore because to authenticate
with VPN you're obviously not on the network
so you can't login with Kerberos,
you can't get your Kerberos ticket
that is a requirement now.
Again, domain-wide we are also blocking
Kerberos pre-authentication with RC4 and DES.
Something great that came afterwards was also that
if you're a member protected users, you cannot be delegated.
So all the delegation attacks that we discussed with Kerberos
delegation in the beginning of this course
will be mitigated if a user is a member of this group.
But this protection is only for that user
or the members of the group, not for the domain.
And the last protection is that the Kerberos TGTs
will need to be renewed after the initial four-hour lifetime.
Now, I want to show you how problematic it
could be to get into a machine which is not on the domain
network if you want to log in as a user that
is a member of protected users.
And this is not because it's problematic,
it's more that it's something you should
be aware of before going forward and having
members of this group.
And while I highly recommend you go forward and have
your produced accounts being members of protected users,
at least tier-0 to begin with, you
should be careful while adding them
and start by taking only a few accounts at a the time
instead of just taking all your accounts
and adding them to this group because you might end up
in a position where you just simply lock out yourself
of your active directory.
Let's look into the demonstration.
Let's begin by looking at the protected users group.
It is located by default in the users OU.
If I double click and look at members,
I already added the account administrator of this domain
to showcase with this account.
Because this account is a member of the group,
now it automatically inherits all of the protections
that this group provides.
And what we're going to see in here
is that domain functional level since 2016
so we are inheriting and benefiting
from all the protections that this group provides.
Now, I'll move away from the domain controller
and go to a server.
I will try to login with the account administrator
and as you'll see there's no issues,
everything works expected.
My server is on the network, I can get on.
And this login is now with Kerberos
because NTLM is no longer allowed.
Now what I'm going to do is I will sign-out and cut
the network connection of this machine.
That would be into my settings, I will just not
have it connected.
Now, you can see immediately that the network changed.
And even though we just saw that I had logged in with this
account in the machine previously,
if I try to do that now I'm getting an error,
the account cannot sign-in.
Now, this might not be very problematic with servers, which
are constantly on the network, it
could be problematic with logging
into workstations with devices which are not on your network.
So having administrative accounts,
member of this group for users that
require to log into a device offline
is going to be very dangerous.
Out of fairness, if only tier-0 are the only accounts that
are members of protected users or the ones
that you start with, you should never use that tier-0 account
out of your network.
You might need to do it during an emergency
if you're urgently needed and you're at home.
So you have to log in through a produced admin workstation
and access your environment.
And that's where we'll keep our regular produced admin
workstation users, not being a member of this group
to gain access to the network but transferring the network,
we can utilize our protected users going forward.