So to create a test profile,
the easiest way to do this is actually just to click on the
Start menu here and then just type in VPN,
and you'll find the VPN settings here.
So go ahead and click on VPN settings, and here click Add a VPN connection.
From the provider drop‑down list, choose Windows (built‑in).
Provide a connection name.
I prefer to call it something very, very simple.
Just Test is fine.
And the server name or address needs to be the VPN server's public hostname.
You always want to use a hostname here, never an IP address,
so we'll add that here.
And then for the VPN type, for now we're going to select SSTP,
or Secure Socket Tunneling Protocol,
because that's the first protocol that we want to validate during our testing.
For the type of sign‑in info, you can choose Certificate.
You can leave the User name and Password fields blank because we're
obviously going to use a certificate for authentication.
And then, uncheck Remember my sign‑in info.
We don't need that information when we're using a certificate.
So click Save.
And unfortunately, it's not quite that easy.
We've got a lot more work to do, but we need to dig down a little bit deeper.
We can't get to all the advanced settings that we need to in this UI.
So over here on the right, or depending on how your screen is oriented,
it may be below this,
but click on the link here that says Change adapter options.
When you go here, minimize this, you'll see our Test VPN connection.
So we're just going to right‑click on that and choose Properties. And I'm going
to jump over to the Security tab, and the first thing I want to do here is
select Protected EAP from the EAP drop‑down list here.
So we're going to select Protected EAP, and then
we're going to click Properties.
So here there is a whole bunch of settings here, so I'm
going to go through all of these in detail.
The first one, probably the most crucial, is this check box next to Verify
the server's identity by validating its certificate.
If we were to uncheck this, this would be a very poor security configuration.
We always want the client to validate the server that it's
authenticating to, and if it's not valid,
we don't want to authenticate this.
This is a security mechanism that's really crucial because it
ensures that it is prohibitively difficult to intercept the
authentication credential exchange between an endpoint or a VPN
client and the VPN server.
This is designed to kind of thwart or prevent man‑in‑the‑middle attacks, so we
want to make sure that this setting is absolutely set. To further improve
security, we actually want to tell the client what is the name of the NPS
server that we're actually authenticating to.
In other words, not only verify that its certificate is valid and trusted,
but is it the actual correct NPS server.
So, in this case, we're going to add the hostname of the NPS server that
we configured previously. I suggest using the fully qualified domain name
because this name needs to match the name that's on the certificate
presented by the NPS server when we're establishing our secure
authentication channel. We'll also need to tell the client which trusted
CA is issuing this certificate.
So here I'm going to go down and find my root CA, and I'm going to select that
option here. By the way, you can't really see much here, and you may in your
environment might have more than one issuing CA.
So if you double‑click on this, you'll get the actual certificate.
I would encourage you to go to the Details,
scroll down to the Thumbprint, and make absolutely certain
that this is the correct certificate.
Again,
if you've renewed certificates in your environment or you've stood up
additional CAs and happened to use the same name, there's a lot of ways
that there could be multiple certificates here that have the same name, but
aren't actually the same certificate itself, so validate that this is the
correct thumbprint for the certificate in your PKI or on your issuing CA,
or root CA in this case.
So, there's a drop‑down list here for Notifications.
This is rather important because the default settings are, again, less
than ideal. What this tells us here is that the default setting is tell
the user if the certificate isn't specified or if there's a problem
with it or something like that.
The problem with this is that we're leaving the job of
determining whether or not to connect up to the user.
What's going to happen is if this connection was intercepted,
an attacker could, you know, again present its own credentials, and the client,
of course, would not trust the certificate,
but it would prompt the user, what do you want to do?
Do you want to continue?
Well, of course, they're just going to click right through that.
So, doesn't really help us from a security perspective. The best
option here is to select Don't ask users to authorize or trust new
CAs because if something comes up there,
we know that, you know,
that's probably bogus or that there's a problem with this connection.
We would rather it fail closed or fail safe, right, and not connect rather
than have the user try to make a determination as to,
you know,
well, is this actually a trusted CA or not. The next thing that we
want to do here is select our authentication method.
We're going to use Smart Card or certificate. And before we
get on to the configuration, there's a couple of little
things I want to touch base on here.
We want to disable fast reconnect because, again,
as I mentioned earlier, that is a Wi‑Fi technology.
It's used to kind of streamline the reauthentication process for,
you know,
typically moving between access points. We don't
want that feature enabled for VPN.
We also want to check the box for Disconnect if server does not
present cryptobinding TLV. Cryptobinding, again,
as I'd mentioned before, is a security mechanism that ensures that the
peers actually communicated directly with each other.
It's designed to detect man‑in‑the‑middle attacks. And so an
attacker could intercept this connection and just simply not send
the cryptobinding TLV to the client.
The client would just say, okay, great, you didn't send me one, then fine.
I'm just going to go ahead and connect.
If that happens,
that is unusual and out of the ordinary, and it is indicative of
an attack, and so we want the client to say,
hey, if you didn't send me a TLV, something's wrong here.
You know, I'm calling bollocks on that, and I'm going to drop out. So in that case, we definitely want this setting here.