Next let's switch over to dc1, my domain controller,
and if I bring up Active Directory Users and Computers,
we can see in the Users container some new Domain
Local built‑in security groups.
There's our Allowed RODC Password Replication group and here's
our Denied RODC Password Replication group.
And then if we go over to Domain Controllers,
we have a new entry for RODC, which is a read‑only domain controller,
as we've already talked about.
Alright, the other part of this demo is on authentication policy silos,
and let's take a look here.
So what we've got going on is first of all I've got a
couple members of the Domain Admins group.
Let's go to Domain Admins, take a look at its membership,
and besides my own account, we've got Taylor and Karl.
Let's focus in on both of those, and we'll use Karl in our example.
So, these folks are domain admins,
but let's say that we have security such that if we go to Computers,
MEM1, let's say, contains particularly sensitive information and only I,
Tim, should be allowed to sign into that domain member server,
even though Karl, for example,
is a domain admin and normally he would be allowed
to sign into any domain member, whether a server or a client.
We can use authentication policy silos to prevent that sign‑in.
This is one of the value propositions of those silos.
And just like we saw earlier with fine‑grained password policy,
this is something that we have to do with Active
Directory Administrative Center, or ADAC.
You can see right here we have an Authentication node that consists of
Authentication Policies and Authentication Policy Silos.
Now you can just use policies,
but it's best practice to do your granular work at the
policy level and then patch them into silos,
and then you can join your accounts, your user accounts,
your service accounts, your computer accounts,
to a particular silo.
I'll show you how all that works.
So let's go into Policies first.
Let me right‑click and create a New, Authentication Policy.
I'm going to give this a really imaginative name,
how about tim‑mem1‑policy, and I want to make sure,
you can do audit or enforce.
I want to be really sure that I do enforce.
In the past when I've tested this,
I've had problems thinking why isn't the silo actually applying?
And then it turns out I had either a policy or a silo
set to audit instead of enforce, so make sure that you're doing that.
Alright, so if we come down here,
we've got settings depending upon what principle we're talking about,
whether it's a User, a Service account or a Computer account,
you've got some configurable protections.
And, again,
this goes above and beyond the Protected Users global group that
contains just a canned set of protections.
So for User sign‑on, for instance,
we can limit the Ticket‑Granting‑Ticket Lifetime way down to 60 minutes,
as opposed to, I think the default is something like 8 hours.
I mean that's pretty impressive right off the top, wouldn't you agree?
Okay, so let's click OK for now.
We've got our tim‑mem1‑policy.
Now let's go to Authentication Policy Silos.
Again, I'll right‑click and we'll create a new silo using the same pattern,
tim‑mem1, this time it's silo.
Now, again, I want to make sure to choose enforce here before I forget.
And there's two important principles here.
One is,
notice that for Authentication Policy you can patch in different
policies based on what kind of principle it is,
whether it's an interactive User,
a group Managed Service Account or a Computer account.
Now I'm going to use a single monolithic policy
that applies to all of them there, so that's one.
The other aspect of the silo is membership,
or the permitted accounts, the ones that will be associated with this silo.
So let's click Add,
make sure that my Object Type filter has all three
of those principles connected, and let's bring in MEM1.
And now let's do another Add operation and let me bring in my own account,
my tim account, good deal.
We're going to have to make sure that we don't forget to add those users.
See how this has an Assigned field?
Right now they're not assigned.
So actually right now, before I forget, let me head on over to Users,
tim, and we can do all this directly within ADAC,
we don't have to leave it.
We can come down to Silo,
and then we're going to assign an Authentication Policy Silo,
tim‑mem1‑silo, click OK.
And now let me do the same thing, let me go back to domain, Computers, MEM1.
I'll double left‑click it, come down to Silo,
and we're going to assign the tim‑mem1‑silo to the MEM1 server,
good deal, so they should both be assigned.
Alright, so to finish this out, let's go back to our original policy,
tim‑mem1‑policy,
and I want you to see here that tim‑mem1‑silo is
associated for all three types of policy.
We're going to add a condition for User Sign On that in
order for this policy to kick in, we're going to do Edit,
and we're going to make sure in our condition,
Add a condition, that the User,
notice that we can create our conditions based on
Active Directory Group or Silo,
the User AuthenticationSilo Equals the Value. Unfortunately there's
no browse so you have to know what the name is,
User AuthenticationSilo Equals tim‑mem1‑silo.
I think that's looking pretty good so far.
But wait, there's more.
There's one more step.
It seems like there's always one more step,
and that is we need to make sure to enable this technology in Group Policy,
and we need to do that both for our domain controllers,
as well as for our client systems,
and that would include servers and desktop clients.
So let me show you those policies,
because it may in fact come up on your AZ‑801 exam.
So for your Domain Controllers,
notice that I'm going to edit the Default Domain Controllers policy.
And if I walk the tree down, Computer Configuration,
Policies, Administrative Template, System,
KDC.
And for your domain controllers,
the policy in question is called KDC support for claims,
compound authentication and Kerberos armoring.
All we want to do there is do Enabled, Supported.
That also enables Dynamic Access Control by the way,
and that's going to be what we need for our domain controllers.
Then for our member servers and workstations,
I'm going to do this change in the Default Domain Policy.
It's the same path.
So if I go to Policies, Administrative Template,
System, instead of KDC, we go to Kerberos,
and here the policy is called Kerberos client support for claims,
compound authentication and Kerberos armoring.
We just want that Enabled.
And then, of course,
you're going to want to do an Invoke‑GPUpdate to make sure
that all of your machines are on board.
I actually have already done the policy,
as you see, and I've already rebooted the necessary machines.
So to test this out, let me from my current server open up mstsc,
the Remote Desktop Connection,
and let's attempt a connection as Karl to the mem1 server.
Okay, it looks like we've got some issues.
Probably my Remote Desktop is not enabled on MEM1.
Well, we can always go to phase 2, can't we?
And that phase 2 is to connect to MEM1 on a separate RDP,
in other words, interactively sign in.
So I'm going to do a karl@timw.info, supply his password, and he's being let in.
Okay, I think I understand what's going on here.
I'm going to have to reboot again, so hold tight for a moment.
Okay, back from a reboot here on mem1.timw.info.
So remember, Karl is a domain administrator,
and his credentials are correct, but notice that he receives the error,
The computer you're signing into is protected by an authentication firewall.
The specified account is not allowed to authenticate to the computer, hence the use case, or one of the big use cases of authentication policy silos.