How to implement PEAP-MSCHAPv2 as authentication method for VPN connections in TMG 2010

As you may know, there is a known security vulnerability for the authentication method MS-CHAPv2.

The following TechNet article provides some detailed information about it:
Microsoft Security Advisory (2743314)

Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure

http://technet.microsoft.com/en-us/security/advisory/2743314

You may consider moving away from PPTP VPN connections which are configured to use this authentication method therefore.

But, what are the alternatives and how can you integrate these in TMG 2010 which is configured as a VPN Server?

As you can see, only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole
authentication method are vulnerable to this issue. If you need to rely on PPTP connections due to down level clients’ requirements, you may consider changing the authentication method for such PPTP connection to PEAP-MSCHAPv2. I will illustrate later how this can be achieved with TMG 2010.

First of all I would like to mention that you should consider using SSTP or L2TP/IPSec connections instead of PPTP.

Both types are also supported and integrated in TMG 2010.

Why you should deprecate PPTP?

PPTP uses Microsoft Point to Point encryption (MPPE). MPPE uses RC4 stream cipher for encryption. There is no method for authentication of the cipher text stream and therefore the cipher text is vulnerable to a bit-flipping attack.

You could use an authentication method like EAP-TLS, PEAP-TLS or PEAP-MSCHAPv2 for a PPTP connection to address the mentioned vulnerability in MS-CHAPv2. But the encryption method does not change by doing that.

So let’s take a look at L2TP/IPsec and SSTP.
The main advantage of Secure Socket Tunneling Protocol (SSTP) is that it is uses TCP port 443 as its server destination port since it relies on SSL which provides transport layer security. Therefore the SSTP packets can pass firewalls and proxies. Unfortunately there is no built-in SSTP support in down level or several 3^rd party operating systems. That’s why the affected administrators need to decide between PPTP and L2TP/IPsec for compatibility reasons.

L2TP/IPsec is well-known and has been widely used for many years. If you need some in-depth information, please refer to the following article:

http://technet.microsoft.com/de-de/library/cc771298(v=ws.10).aspx

Because of that fact that there is no need to reinvent the wheel, I would like to point to Deb Shinder who did a pretty good job writing a step-by-step guide on how to implement L2TP/IPsec in TMG 2010.

http://www.isaserver.org/tutorials/Checking-Out-TMG-2010-Virtual-Private-Network-Server-Part3.html

Though its quality, Microsoft does not adhere for third party information.

Before we look at the configuration of PEAP-MSCHAPv2, let me clarify that PEAP-MSCHAPv2 is NOT affected by the mentioned vulnerability, because the MSCHAPv2 information is only transmitted within a secure channel in PEAP phase 2.
The following article provides further information about the authentication method PEAP-MSCHAPv2 in general:

http://technet.microsoft.com/en-us/library/cc779326(v=WS.10).aspx
One more word before you read ahead. PPTP PEAP-MSCHAPv2 requires a certificate with Server Authentication EKU on a NPS Server from either your organizations PKI or a public CA.

Now let’s focus on how to implement PEAP-MSCHAPv2 in TMG. You may expect that TMG supports PEAP-MSCHAPv2 as valid authentication method, since it is some sort of EAP variant with improved security and because EAP can be enabled in TMG as authentication method. Unfortunately this is not 100% correct. If you choose EAP it in the Remote Access Policy it will cause the VPN connection to fail.

A Windows 7 client will report the following error:

Why does this happen?
The reason is that TMG configures the Routing and Remote Access Service (RRAS) and the Network Policy Service (NPS) which are included in the Windows Server operating system.

Doing this, TMG adds the following authentication method as a valid type to its local NPS configuration:
“Microsoft: Smart Card or other certificate” which is EAP-TLS, but neither PEAP-MSCHAPv2 or PEAP-TLS.

If you change the NPS configuration on the TMG Server, it will only provide a temporary workaround. The reason is that TMG will overwrite the NPS configuration once its service is restarted.

How you can solve that:

You will need to configure TMG to use Radius Authentication. This will result in outgoing Radius packets to a remote Radius/NPS Server. This additional NPS Server can be configured to enable PEAP support.

As next step you will need to define the remote RADIUS Server(s)

This is it from TMG perspective. After you have applied the configuration, you will need to configure the remote NPS Server.

After you have added the required NPS role on your remote server, open the NPS MMC.

First of all you will need to define and enable a RADIUS client there. This will ensure that incoming RADIUS packets from this source will not be dropped.

Next you will need to create a ‘Connection Request Policy’ and a ‘Network Policy’ in the remote NPS Server.

The following article explains the differences between ‘Connection Request Policies’ and ‘Network Policies’.

http://technet.microsoft.com/en-us/library/cc772279(v=WS.10).aspx

When installing NPS, you will have some policies already. Either you can edit them or create some new ones. We will create new ones for this example. Let’s start with a new ‘Connection Request Policy’ by using the wizard.

Then you will have to define conditions when this policy applies. You have lots of possibilities to define granular rules which match your needs. These possibilities are illustrated in the linked article above. To make things as easy as possible for this guide, we only use a Day-and-Time condition. Basically the condition always applies.

Leave the default settings on the next screen. You could forward the requests once more (Radius Proxy feature), but that does not make sense for this example.

If you are using Network Access Protection (NAP) for your VPN clients, you will need to use the setting “Override network policy authentication settings”. If you don’t use NAP, leave the default settings which I do for this straight-forward example.

Leave the settings on the next page to its defaults and click ‘Next’. After you have checked the summary, click on ‘Finish’. That’s it for the ‘Connection request policy’.

Let’s move on to the network policy.

Right click on ‘Network Policies’ and choose ‘New’.

In the next screen define a suitable policy condition which defines, when the network policies is about to be applied for a connection request. Again, you have plenty of options to use granular conditions. This does not only make sense, but may also be required due to your infrastructure needs. For example you may want to use different authentication methods, you may need to create different policies for VPN, 802.1x, etc.

To keep things simple, we use the Day and Time restriction once more. Again, using it in this way, it will always apply this rule.

Skip the next screen by clicking on ‘Next’. This will bring you to the configuration of the valid EAP types.

You will need PEAP-MSCHAPv2 for this scenario. Uncheck the ones which are not required and add PEAP-MSCHAPv2 by clicking on ‘Add’.

Click on ‘Ok’.

You screen should look like this:

Highlight the PEAP entry in the list and click ‘Edit’:

Make sure that you have chosen a valid and trusted certificate. Besides add EAP-MSCHAP v2 as inner method.

Click ‘Ok’, click ‘Next’ three times and then ‘Finish’ completing the configuration.

That’s it. I hope this guide helps you to understand if you need to change your VPN type and if needed, how to do it.

I am happy to answer related questions and read your feedback in the comments below.

Author:

Frank Hennemann

Microsoft CSS Forefront Security Edge Team

Technical Review:

Markus Sarcletti

Microsoft CSS Windows Networking