Windows RT VPN

Although connections to any third-party server using one of the above protocols should work, we have specifically verified interoperability of the Windows RT in-box VPN client with Cisco and Juniper servers running popular versions of their server software. Following table depicts the interoperability details:

Note
1 This method is supported by the native Microsoft Windows VPN client, but is not tested for interoperability with 3rd party solutions.

For more details, please refer to the Third party VPN Interoperability section in Windows 8 and Server 2012 VPN Compatibility and Interoperability.

Caution
Microsoft recommends using L2TP/IPSec or IKEv2 protocols for connection to third-party servers.

The following apply to both Microsoft RRAS as well as 3rd party VPN servers.Password-based deployment

Windows RT can establish a remote access connection through a variety of password-based PPP authentication protocols, which includes

• Non-EAP methods like PAP, CHAP, MS-CHAPv2, etc., or
  
  
• EAP methods (PEAP, EAP-TTLS etc.)
  
  

The password-based methods which are not considered secure (Non-EAP password based methods) should be deployed with secure TLS methods such as PEAP, EAP-TTLS.

Important
Microsoft recommends using PEAP or TTLS based authentication methods (both available in-the-box in Windows RT) for corporate deployments.

Certificate-based deployments

To support this, an organization needs to support enrolling/importing user certificates. There are many options to deploy a Public Key Infrastructure (PKI) for this purpose and it depends upon the organization’s policy and deployment capabilities. More details on the Certificate enrollment web service can be found on TechNet.

Organizations with more than one business location may choose to have multi-site VPN server deployments. In this case, organizations should use Global Server Load Balancing (GSLB) for resolution of the address and redirecting the client to the nearest VPN server site. If for some reason, that is not an option, then the IT administrator can provide VPN connection profiles per site, thus providing the user with a choice to connect the desired remote server.

GCW is the legacy VPN connection setup wizard, and is available on Windows RT. It provides a simple method for creating VPN connections from the client device itself. If the VPN deployment is simple (password based) and has no complexities like provisioning NAP, Routes, etc., then users can easily create the profile themselves. In this case, a user just configures the remote access server name or IP address as instructed by his network administrator.

If the profile is a more complex then the administrator needs to provide the detailed instructions and/or the configuration scripts.

The TechNet article, Windows 8 VPN Get Connected, provides more details.

Network administrators can create simple PowerShell scripts to help users install and configure the VPN connections on unmanaged devices. These scripts serve dual purposes:

• Create a VPN profile, and
  
  
• Configure network specific settings (e.g. plumbing routes, NAP settings, etc.)
  
  

The admin and user experiences for installing the VPN profile using PowerShell scripts are discussed below.

Admin experience

• Admin creates a PowerShell script and setup instructions. The PowerShell cmdlets to create the VPN profiles are very simple and comprise a few lines of code.
  
  
  1. PS examples, sample scripts & documentation are available on TechNet to help admins create scripts as per their network deployment.
     
     
• Admin delivers the script and instructions to users via email or a web portal. The admin needs to inform users to run the script again each time the script gets updated
  
  

User Experience

• The user navigates to the web portal as instructed and logs-in with his domain credentials.
  
  
• He simply clicks on the VPN configuration link and the setup script gets downloaded to the client device
  
  
• User clicks on the “Run” option from browser download UI and profile gets installed
  
  

Advanced Scenarios

Administrators can club many advanced configurations with this single-click VPN provisioning script to provide a complete client provisioning story for users. These advanced settings could involve

• Deploying additional policies like IPsec, routes publishing or NAP for VPN connections
  
  
• Web-proxy configuration for VPN connection
  
  
• Intranet settings for VPN connection
  
  
• Connection specific DNS Suffix plumbing for VPN connectionv
  
  

On Windows RT devices, an integrated management client called Company Apps is available that can communicate with the management infrastructure and receive LOB apps and VPN connection configuration delivered by the System center.

The IT Administrators can generate the VPN connection configuration XML and configure it with System Center manager to push down to the client devices enrolling for the service.

The clients can browse to Company Apps (in Control Panel) and enroll for the device management infrastructure by using their domain credentials. On successful enrollment, System center management infrastructure pushes the VPN connection configuration information to the client device and the Self-Service Portal agent (on WindowsRT devices) configures the VPN connection on the client device without any user intervention.

The admin and user experiences for profile setup via SSP are discussed below.

Admin experience

1. Open System Center management UI and configure VPN profile configuration XML for clients.
   
   
2. Admin can update the profile (if needed) again through System Center server management UI and no further action is required from user.
   
   

User experience

User needs self-provisioning for WoA machine to get enrolled for the VPN setup.

• Authorized users navigates to the new Control Panel applet called Company apps on their WOA devices and provide their company email address and password.
  
  
• The SSP agent then automatically configures VPN and other features on the client device based on the instructions received from organization’s management infrastructure.
  
  

Note
The above device management solution is not yet released. The release along with documentation is slated for Jan 2013.

Once a VPN profile is created, the need to modify the profile may arise occasionally. This section describes the common settings and how these settings can be modified by the administrator or the user.

• Edit and delete experiences for GCW profiles are described in the Windows 8 VPN – Get Connected TechNet article.
  
  
• For VPN profiles created using powershell scripts (managed by the administrator),
  
  
  • The administrator can create and share another single-click script to remove the profile and corresponding settings from client device.
    
    
  • The new script may also be used to
    
    
  • Delete an existing VPN connection, and then provision a new one, or
    
    
  • Edit an existing connection, or add a new connection
    
    
• If the IT administrator wants to make any changes to the VPN profile deployed on client systems, he can simply create a new VPN profile configuration XML and update that in management infrastructure. The new VPN profile will be used for provisioning from then on.
  
  

The Windows 8 VPN – Get Connected TechNet article provides more details on the client experience for VPN profile management.

Split-tunneling, which allows Internet-bound traffic to bypass the VPN connection, can be set up as follows on Windows RT devices:

Rather than the user executing the above steps, the administrator can also enable split-tunneling using the configuration PowerShell cmdlet as described in this TechNet article.

For split-tunneled VPN connections, the corporate network routes have to be configured on the client device after the VPN connection is established. The administrator can do this using one of the following two methods:

DHCP based routes publishing – When a client is connected to the corporate network via a VPN connection, it gets its IP address from the DHCP server designated for the same purpose. This DHCP server can also supply the required routes along with other configuration.

One-click script (scheduled tasks) – The administrator can enable the configuration of routes through a script. The script adds a scheduled task in the client device, which is triggered every time the device establishes a connection with the remote VPN server, and plumbs the required routes on the client, enabling it to access corporate resources. If the administrator is already using a single-click script to provision other settings (IPSec policies, DNS suffix etc.), then route-provisioning can also be clubbed with the same script.

In the case of force-tunneling, a web proxy needs to be configured on the Windows RT devices for them to be able to access Internet sites. Also, the intranet settings have to be enabled for a VPN connection to suppress repeated credential prompts while accessing intranet sites. The following sections discuss these configurations for Windows RT devices.

Web-proxy

Force-tunneling requires the VPN client to use corpnet web proxy for all the internet traffic. The administrator can either provide the required web proxy information to the users via e-mail and have them configure the web-proxy themselves, or he can configure a VPN-specific web proxy by using a PowerShell cmdlet. This cmdlet can be included in the one-click script used for VPN connection provisioning or can be distributed separately.

Intranet Settings

Enabling intranet settings is another requirement for accessing corporate sites without repeated credential prompts for the user while connected via a VPN connection. Intranet settings determine whether accessed web sites are a part of the local intranet zone and require domain credentails. If intranet settings are enabled for a VPN connection, the VPN credentials are automatically used for authenticating the user while accessing the local intranet sites.

For unmanaged Windows RT devices, VPN connection is not automatically recognized and intranet settings are not turned ON by default. This results in a credentials prompt every time the user navigates to a local intranet site. To resolve this, users need to turn on the intranet settings by following the procedure below:

Alternatively, the administrator can configure certain registry settings on the Windows RT device via scripts to enable the intranet settings when the client is connected to corpnet via a VPN connection.

An organization desiring RSA OTP authentication must complete the following configuration steps

Client Side

Configure the Microsoft VPN Client profile on Windows RT to use TTLS-PAP authentication protocol. TTLS-PAP is a new password-based, secure EAP method in Windows 8 that is used to transport the user’s username, password and OTP token

Server Side

• Deploy RSA’s authentication manager and configure it to accept and process TTL-PAP authentication requests
  
  
• Configure the VPN server (Microsoft RRAS or a 3rd-party server) to redirect all authentication requests to RSA’s authentication manager.
  
  

To authenticate with RSA OTP the user just dials the VPN profile and enters his OTP username and passcode (consisting of his password followed by the OTP token code). TTLS-PAP protocol terminates on the authentication manager which authenticates the username, password and token code.

Note

This alternate mechanism for OTP authentication is currently being validated by Microsoft and RSA with Microsoft and 3rd-party VPN servers. The solution does not provide the following capabilities offered by the regular RSA OTP authentication method. PIN Changes During first time authentication, or PIN expiry, the user is required to set a new PIN. Once the PIN has been changed the authentication is completed and the user is connected. NEXT Tokencode If the authentication succeeds after a certain number of failed token attempts, or if the token presented is invalid but is within the allowed time-window, then the user is prompted to enter the NEXT token code to check for validity and for a possible time sync issue. A workaround for these limitations is to set up a Web-login page hosted by IIS server (or any third party Web-server) and protected by the corresponding RSA Web Agent. RSA web agent is capable of performing Challenge-Handshake with the Authentication Manager and provides the users with an ability to reset their OTP PIN. RSA web-agent can also prompt the user in the case where NEXT Tokencode is required, and enable the users to login / time sync the hardware / software tokens.