Now let me address a very important point, indeed.
If you've spent quite a bit of time outfitting one of your
Windows Server hosts with custom policy here in Windows
Defender Firewall with Advanced Security,
you certainly aren't going to want to manually recreate those rules,
especially if you might have dozens of servers to work with.
Now one solution, of course, is to use central policy with Group Policy,
but another one is you can actually right‑click the root node here,
and notice that you can do Import/Exports.
Isn't that convenient?
And so we can export this, I'm on dc1, as a WFW policy file,
and then on another server, we can import that policy,
and that provides you one way to share policy in Windows Defender
Firewall with Advanced Security on multiple hosts.
All right, so let's finish this by coming into Group Policy Management,
and let's operate on the Default Domain Policy,
and let's say that we have a use case where our security is such that all
communication that takes place between two of our servers,
MEM1 and DC1, should be encrypted and provide mutual authentication.
So there's a good real‑world example of using IPsec isolation rules.
And we can deploy this policy,
we probably want to be more intentional than linking it to the domain,
but I'm going to do this demo, nonetheless I'm going to forge ahead,
at the Default Domain Policy.
All right, so what we want to do here is come down under Policy,
Windows Settings, Security Settings,
Windows Defender Firewall with Advanced Security,
and notice here that we can come in and we can
right‑click and we can create Inbound, Outbound,
and Connection Security Rules specific to this Group Policy,
right?
Right‑click Security Rules and click New Rule.
Now the type of IPsec connection security you can do,
there is the list right here, of course you've got Custom.
Tunnel would be something akin to a VPN,
and technically,
Tunnel would work fine in this case where DC1 is one end
of the tunnel and MEM2 is the other, but instead,
I want to authenticate between two servers.
Now, there's some other variants that we might want to look at.
The Isolation policy restricts connections based on authentication criteria.
That would allow you to create a rule, for instance,
that would involve encryption and authentication depending upon who
is making the connection from machine to machine.
But I'm just going to choose Server‑to‑server in this.
So regardless of the calling user who's making use of that
server‑to‑server network connection,
I want to make sure that the connection is
authenticated and potentially even encrypted,
and we can leverage IPsec for this.
In this case, the computers that are Endpoint 1 are going to be specific IPs.
Now of course, this means I need to do a little bit of homework here,
so let me invoke a PowerShell session,
and let me just try an IPv4 ping on dc1.timw.info,
and let me do the same thing on mem1 so I can get its IP address.
So it looks like 10.1.10, and then we've got 163 and 165, 10.1.10.163.
Now notice we can do a predefined computer set,
but that's not granular enough,
I want to specifically pick out IP addresses here.
Now that's 163, that's node 1, and then Endpoint 2 is going to be 10.1.10.165.
So that's defining our two endpoints in the Server‑to‑server rule.
And here we first are asked,
are we requesting authentication or are we requiring it?
And even at that, are we requiring authentication only for inbound,
or are we requiring authentication mutually for inbound and outbound?
That's the most secure option.
Let's click Next.
Now the ways that the servers can authenticate to each other,
the preferred way if you have a public key infrastructure,
would be to use computer certificates that are installed on each server,
but we can also go to Advanced and there's some more relaxed options here.
Notice you can choose a fallback,
you can choose a First and Second authentication type.
Let's click Add.
The least overhead option is Kerberos V5.
You also can do NTLM, which I wouldn't recommend,
it's an old protocol, or we've got certificates,
or we've got preshared key.
Kerberos I think is going to be fine in this case,
and I won't do a second level authentication,
I'll just do the first one.
Click Next.
We're asked, what rules does this apply to?
I'm going to say that this applies only to the Domain profile.
Let me go back to make sure I didn't miss something here.
Okay.
And I'm going to call this dc1‑mem1‑auth.
Well, let's click Finish.
All right, now we could create an analogous rule.
We can create an inbound rule to each machine that
enforces IPsec encryption as well.
That would be something else we could try.
Now let me right‑click Inbound Rule, and we'll go Custom here for all programs,
all protocols and ports, and the IP addresses are going to be the same as before,
10.1.10.163 is one endpoint, the other endpoint is 10.1.10.165.
We're going to allow the connection only if it's secure.
We're already doing authentication,
so I'm going to say Require the connection to be encrypted,
all right?
Next, this is where we can layer in, since we went down the Custom route,
where we can only allow connections from particular
Active Directory users and groups as well.
I won't do that.
Only allow connections from these computers, and then we have Exceptions.
I'm already specifying those machines,
but I might as well just add them in here to be safe,
DC1 and then MEM1.
Sometimes I'm a little superstitious.
And we want this rule to apply at the Domain scope,
and I will call this dc1‑mem1‑encryption,
and click Finish.
And so now we have a custom Inbound Rule,
as well as a Connection Security Rule set defined in Group Policy.
You're wondering how you can track this.
I mean, we'll need to propagate Group Policy for this to go into effect.
We can always open up that Advanced Security security console on each server,
or we could open up an MMC console and just make a remote connection.
But you can come under Monitoring to take a look at your Connection Security
Rules that are active; and then specifically the mechanics,
the key and integrity and key integrity status,
all of that kind of stuff of the Security Association that that server is involved with, is surfaced here as well.