Remote Access Design Guidelines – Part 3: Tunnel selection, Authentication, Authorization and Accounting

Hello Customers,

In this post, I will walk through the most important topic – which authentication protocol, VPN tunnel to use, how to authorize access of your VPN users.

Lets have a look:

3.1 User Authentication

The remote access user is authenticated by the VPN server during VPN tunnel establishment phase.

The following table highlights the various recommended deployment options for user authentication. It highlights the deployment requirements for a given authentication protocol on the client side as well as the network side (RRAS server, Radius server end) - going down from highest security level to lowest level

To enable user authentication, RRAS server to be configured for Radius based authentication and Radius server is joined to Active directory domain in order to authenticate users. The Radius server itself may be running on the same server as RRAS or on a different server.

** The same authentication protocol must be configured on both ends of authentication i.e. VPN client as well as Radius server. Within Radius server, a policy should be created for NAS type as RRAS server. And within this policy, the specific authentication protocols must be configured inside policy “condition” . Additionally RRAS server must be configured to accept the specific authentication protocol.

Note: The above table doesn’t include certain third party EAP methods (like RSA SecurID) also supported by RAS based remote access solution.

3.2 Tunnel Types

There are different VPN tunnels that exist inside Windows OS. First, let us compare the different tunnels on general and network centric parameters

Now let us compare these VPN tunnels on the various security related parameters: 

Where,

* PPTP, SSTP tunnel does PPP based user authentication (password or certificate based as explained in earlier section including EAP as well as non-EAP based authentication protocols).

** L2TP/IPSec tunnel first does IPSec level machine authentication (pre-shared key or certificate based) followed by PPP based user authentication (password or certificate based as explained in earlier section – including EAP as well as non-EAP based authentication protocols). The machine authentication is done between VPN client and RRAS server, whereas user authentication is performed between VPN client and Radius server.

*** VPN reconnect (IKEv2) tunnel supports machine authentication (certificate only) or user authentication (only EAP based authentication using password or certificate based authentication as given in earlier section). The machine authentication is done between VPN client and RRAS server, whereas user authentication is performed between VPN client and Radius server.

**** The certificate requirements on the VPN client side or on the network side are additional to the authentication requirements that are described in user authentication section above. The certificates mentioned here are required for initial part of tunnel (like IPSec session for L2TP scenario or SSL session for SSTP scenario) to come up before performing user authentication. Please note: this doesn’t mean this requires separate set of certificates need to be managed for initial part of tunnel and subsequent user authentication (e.g. if PEAP is used with SSTP, then the root certificate on the client side for PEAP can be same as root certificate for SSL negotiation) – thereby easing out deployment. However, if RRAS server and Radius server are deployed on different machines, then different machine certificates are required - one on the RRAS server side (for L2TP/IPSec or IKEv2 or SSTP) for the initial part of tunnel negotiation and other on the Radius server side (for PEAP or EAP-TLS authentication). However the client side certificate remains the same.

3.3 Tunnel Selection

As described in the above section, there are different types of VPN tunnels that is supported by Windows based VPN client and server.

RECOMMENDATION: Based upon the feature set, our recommended tunnel types are IKEv2 followed by SSTP.

As a network admin, your main goal is to enable smooth migration of your existing PPTP or L2TP/IPSec users to IKEv2 followed by SSTP based deployment. But that requires each remote access user to change their operating system – which may not be possible at once. This means multiple tunnel types needs to be supported on the server side during the migration timeframe. This is where you can leverage the VPN tunnel strategy feature inside Windows VPN client that helps you specify the order in which VPN tunnels are tried – till a given tunnel type is able to successfully connect to the VPN server.

For further details, please read this blog.

3.4 Authorization

Authentication (as given above) allows a remote access user to identify itself to the remote access server and the remote access server verifying the user identity. Whereas, authorization that is done after the user authentication allows admin to specify what the remote access user can access. Some examples of authorization policies are: allow user to access specific IP subnets, allow VPN access during particular time of the day, allow access with x minute idle timeout, etc.

To enable user authorization, RRAS must be configured to use Radius based authorization provider. And on the Radius server side, within the authentication policy different authorization rules can be added as “constraints” . If there are multiple constraints, the authenticated VPN connection will be subjected (or enforced) to each of those constraints.

3.5 Accounting

The activities of the remote access users can be accounted using Radius based accounting. These activity logs include username, session start time, session end time, transmit/receive bytes and transmit/receive packets.

To enable user accounting, RRAS must be configured to use Radius based accounting provider. The Radius server must be configured to log accounting information in a file OR inside a database.

3.6 Health check

RRAS Server allows Network Access Protection (NAP) based health check (AUTHORIZATION) of the remote VPN users before they are granted access to the intranet. The health definition can be: checking VPN client machine running firewall and antivirus, enabled for Windows update, is running latest patches etc.

To enable VPN NAP deployment, VPN client and the Radius server policy must be configured for PEAP as authentication protocol with NAP quarantine check enabled inside PEAP configuration. Why only PEAP. This is because the client PC’s health information is relayed from the VPN client to the Radius server inside PEAP protocol and hence no other authentication protocols can be used. And within PEAP, any inner EAP method like EAP-MSCHAPv2 or EAP-Smartcard or user certificate can be used. This can also include other 3^rd party EAP methods like one-time password that plugs into RAS EAP framework. VPN NAP is supported for all VPN tunnel types i.e. PPTP, L2TP/IPSec, SSTP and IKEv2.

Radius server must be enabled for NAP based deployment. This includes creating of remote access policies for healthy as well as unhealthy clients and creating the appropriate connection request policy.

To restrict unhealthy clients to a quarantine zone hosting remediation servers (like antivirus signature server, patch update server), remediation server group must be created inside Radius server. Remediation server group allows you to specify the IPv4 and/or IPv6 address of the remediation servers. This list will be sent by Radius server to the RRAS server once it determines the VPN client is unhealthy and RRAS server applies this list as IP filters on that particular VPN sub-interface - means “allow packets to/from these IP addresses and drop rest”. Once the client becomes healthy, Radius server informs RRAS server which removes these filters from that particular VPN sub-interface. And if there are any other IP filters that are sent for the VPN interface (which have been added as “IP Filters” of remote access policy representing healthy clients), they will be applied.

To reiterate, remediation server group and the IP Filters configured inside given remote access policy have separate meanings on RRAS server. The former (i.e. remediation group) are used explicitly for NAP i.e. gets applied on specific VPN sub-interface on RRAS server when the VPN client is unhealthy and removed when the VPN client becomes healthy. However the later ones (i.e. IP filters) are added to VPN client even if NAP is not enabled OR applied when NAP is enabled but the VPN client has become healthy.

3.7 Further Readings

Here are the references to other relevant posts

Remote Access Design Guidelines – Part 1: Overview

Remote Access Design Guidelines – Part 2: VPN Client Software Selection

Remote Access Design Guidelines – Part 4: IP Routing and DNS

Remote Access Design Guidelines – Part 5: Where to place RRAS server

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided “AS IS” with no warranties, and confers no rights.]

Comments

• Anonymous
  January 01, 2003
  Hello Customers, In last few releases, we have added plenty of “cool” features in RAS – like NAP based

• Anonymous
  January 01, 2003
  Hello Friends, In my previous posting related to VPN tunnel selection , I discussed various scenarios