Remote Access

Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016, Windows Server 2012 R2, Windows 10

The Remote Access guide provides you with an overview of the Remote Access server role in Windows Server 2016, and covers the following subjects:

For more information about other networking technologies, see Networking in Windows Server 2016.

The Remote Access server role is a logical grouping of these related network access technologies: Remote Access Service (RAS), Routing, and Web Application Proxy. These technologies are the role services of the Remote Access server role. When you install the Remote Access server role with the Add Roles and Features Wizard or Windows PowerShell, you can install one or more of these three role services.

Do not attempt to deploy Remote Access on a virtual machine (VM) in Microsoft Azure. Using Remote Access in Microsoft Azure is not supported. You cannot use Remote Access in an Azure VM to deploy VPN, DirectAccess, or any other Remote Access feature in Windows Server 2016 or earlier versions of Windows Server. For more information, see Microsoft server software support for Microsoft Azure virtual machines.

Remote Access Service (RAS) — RAS Gateway

When you install the DirectAccess and VPN (RAS) role service, you are deploying the Remote Access Service Gateway (RAS Gateway). You can deploy the RAS Gateway a single tenant RAS Gateway virtual private network (VPN) server, a multitenant RAS Gateway VPN server, and as a DirectAccess server.

RAS Gateway — Single Tenant. By using RAS Gateway, you can deploy VPN connections to provide end users with remote access to your organization’s network and resources. If your clients are running Windows 10, you can deploy Always On VPN, which maintains a persistent connection between clients and your organization network whenever remote computers are connected to the Internet. With RAS Gateway, you can also create a site-to-site VPN connection between two servers at different locations, such as between your primary office and a branch office, and use Network Address Translation (NAT) so that users inside the network can access external resources, such as the Internet. In addition, RAS Gateway supports Border Gateway Protocol (BGP), which provides dynamic routing services when your remote office locations also have edge gateways that support BGP.

RAS Gateway — Multitenant. You can deploy RAS Gateway as a multitenant, software-based edge gateway and router when you are using Hyper-V Network Virtualization or you have VM networks deployed with virtual Local Area Networks (VLANs). With the RAS Gateway, Cloud Service Providers (CSPs) and Enterprises can enable datacenter and cloud network traffic routing between virtual and physical networks, including the Internet. With the RAS Gateway, your tenants can use point-so-site VPN connections to access their VM network resources in the datacenter from anywhere. You can also provide tenants with site-to-site VPN connections between their remote sites and your CSP datacenter. In addition, you can configure the RAS Gateway with BGP for dynamic routing, and you can enable Network Address Translation (NAT) to provide Internet access for VMs on VM networks.

The RAS Gateway with multitenant capabilities is also available in Windows Server 2012 R2.

• Always On VPN. Always On VPN enables remote users to securely access shared resources, intranet Web sites, and applications on an internal network without connecting to a VPN.

Routing

You can use Remote Access to route network traffic between subnets on your Local Area Network. Routing provides support for Network Address Translation (NAT) routers, LAN routers running BGP, Routing Information Protocol (RIP), and multicast-capable routers using Internet Group Management Protocol (IGMP). As a full-featured router, you can deploy RAS on either a server computer or as a virtual machine (VM) on a computer that is running Hyper-V.

To install Remote Access as a LAN router, either use the Add Roles and Features Wizard in Server Manager and select the Remote Access server role and the Routing role service; or type the following command at a Windows PowerShell prompt, and then press ENTER.

Web Application Proxy

Web Application Proxy is a Remote Access role service in Windows Server 2016. Web Application Proxy provides reverse proxy functionality for web applications inside your corporate network to allow users on any device to access them from outside the corporate network. Web Application Proxy pre-authenticates access to web applications using Active Directory Federation Services (AD FS), and also functions as an AD FS proxy.

To install Remote Access as a Web Application Proxy, either use the Add Roles and Features Wizard in Server Manager and select the Remote Access server role and the Web Application Proxy role service; or type the following command at a Windows PowerShell prompt, and then press ENTER.

Securing a Remote WMI Connection

To connect to a remote computer using WMI, ensure that the correct DCOM settings and WMI namespace security settings are enabled for the connection.

WMI has default impersonation, authentication, and authentication service (NTLM or Kerberos) settings that the target computer in a remote connection requires. Your local machine may use different defaults that the target system does not accept. You can change these settings in the connection call.

The following sections are discussed in this topic:

DCOM Impersonation and Authentication Settings for WMI

WMI has default DCOM impersonation, authentication, and authentication service (NTLM or Kerberos) settings that the a remote system requires. Your local system may use different defaults that the target remote system does not accept. You can change these settings in the connection call. For more information, see Setting Client Application Process Security. However, for the authentication service, it is recommended that you specify RPC_C_AUTHN_DEFAULT and allow DCOM to choose the appropriate service for the target computer.

You can supply settings in parameters for the calls to CoInitializeSecurity or CoSetProxyBlanket in C++. In scripts, you can establish security settings in calls to SWbemLocator.ConnectServer, in an SWbemSecurity object, or in the scripting moniker string.

For a list of all the C++ impersonation constants, see Setting the Default Process Security Level Using C++. For the Visual Basic constants and scripting strings for using the moniker connection, see Setting the Default Process Security Level Using VBScript.

The following table lists the default DCOM impersonation, authentication, and authentication service settings required by the target computer (Computer B) in a remote connection. For more information, see Securing a Remote WMI Connection.

Computer B operating system	Impersonation level scripting string	Authentication level scripting string	Authentication service
WindowsВ Vista or later	Impersonate	Pkt	Kerberos

Be aware that connecting to WMI on the local computer has a default authentication level of PktPrivacy.

Setting DCOM Security to Allow a User to Access a Computer Remotely

Security in WMI is related to connecting to a WMI namespace. WMI uses DCOM to handle remote calls. One reason for failure to connect to a remote computer is due to a DCOM failure (error «DCOM Access Denied» decimal -2147024891 or hex 0x80070005). For more information about DCOM security in WMI for C++ applications, see Setting Client Application Process Security.

You can configure DCOM settings for WMI using the DCOM Config utility (DCOMCnfg.exe) found in Administrative Tools in Control Panel. This utility exposes the settings that enable certain users to connect to the computer remotely through DCOM. Members of the Administrators group are allowed to remotely connect to the computer by default. With this utility you can set the security to start, access, and configure the WMI service.

The following procedure describes how to grant DCOM remote startup and activation permissions for certain users and groups. If Computer A is connecting remotely to Computer B, you can set these permissions on Computer B to allow a user or group that is not part of the Administrators group on Computer B to execute DCOM startup and activation calls on Computer B.

To grant DCOM remote launch and activation permissions for a user or group

Click Start, click Run, type DCOMCNFG, and then click OK.

In the Component Services dialog box, expand Component Services, expand Computers, and then right-click My Computer and click Properties.

In the My Computer Properties dialog box, click the COM Security tab.

Under Launch and Activation Permissions, click Edit Limits.

In the Launch Permission dialog box, follow these steps if your name or your group does not appear in the Groups or user names list:

1. In the Launch Permission dialog box, click Add.
2. In the Select Users, Computers, or Groups dialog box, add your name and the group in the Enter the object names to select box, and then click OK.

In the Launch Permission dialog box, select your user and group in the Group or user names box. In the Allow column under Permissions for User, select Remote Launch and select Remote Activation, and then click OK.

The following procedure describes how to grant DCOM remote access permissions for certain users and groups. If Computer A is connecting remotely to Computer B, you can set these permissions on Computer B to allow a user or group that is not part of the Administrators group on Computer B to connect to Computer B.

To grant DCOM remote access permissions

1. Click Start, click Run, type DCOMCNFG, and then click OK.
2. In the Component Services dialog box, expand Component Services, expand Computers, and then right-click My Computer and click Properties.
3. In the My Computer Properties dialog box, click the COM Security tab.
4. Under Access Permissions, click Edit Limits.
5. In the Access Permission dialog box, select ANONYMOUS LOGON name in the Group or user names box. In the Allow column under Permissions for User, select Remote Access, and then click OK.

Allowing Users Access to a Specific WMI Namespace

You can allow or disallow users access to a specific WMI namespace by setting the «Remote Enable» permission in the WMI Control for a namespace. If a user tries to connect to a namespace they are not allowed access to, they will receive error 0x80041003. By default, this permission is enabled only for administrators. An administrator can enable remote access to specific WMI namespaces for a nonadministrator user.

The following procedure sets remote enable permissions for a non-administrator user.

To set remote enable permissions

Connect to the remote computer using the WMI Control.

For more information about the WMI Control, see Setting Namespace Security with the WMI Control.

In the Security tab, select the namespace and click Security.

Locate the appropriate account and check Remote Enable in the Permissions list.

Setting Namespace Security to Require Data Encryption for Remote Connections

An administrator or a MOF file can configure a WMI namespace so that no data is returned unless you use packet privacy (RPC_C_AUTHN_LEVEL_PKT_PRIVACY or PktPrivacy as a moniker in a script) in a connection to that namespace. This ensures that data is encrypted as it crosses the network. If you try to set a lower authentication level, you will get an access denied message. For more information, see Requiring an Encrypted Connection to a Namespace.

The following VBScript code example shows how to connect to an encrypted namespace using «pktPrivacy».

Remote Desktop — Allow access to your PC

Applies to: Windows 10, Windows 8.1, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2

You can use Remote Desktop to connect to and control your PC from a remote device by using a Microsoft Remote Desktop client (available for Windows, iOS, macOS and Android). When you allow remote connections to your PC, you can use another device to connect to your PC and have access to all of your apps, files, and network resources as if you were sitting at your desk.

You can use Remote Desktop to connect to Windows 10 Pro and Enterprise, Windows 8.1 and 8 Enterprise and Pro, Windows 7 Professional, Enterprise, and Ultimate, and Windows Server versions newer than Windows Server 2008. You can’t connect to computers running a Home edition (like Windows 10 Home).

To connect to a remote PC, that computer must be turned on, it must have a network connection, Remote Desktop must be enabled, you must have network access to the remote computer (this could be through the Internet), and you must have permission to connect. For permission to connect, you must be on the list of users. Before you start a connection, it’s a good idea to look up the name of the computer you’re connecting to and to make sure Remote Desktop connections are allowed through its firewall.

How to enable Remote Desktop

The simplest way to allow access to your PC from a remote device is using the Remote Desktop options under Settings. Since this functionality was added in the Windows 10 Fall Creators update (1709), a separate downloadable app is also available that provides similar functionality for earlier versions of Windows. You can also use the legacy way of enabling Remote Desktop, however this method provides less functionality and validation.

Windows 10 Fall Creator Update (1709) or later

You can configure your PC for remote access with a few easy steps.

1. On the device you want to connect to, select Start and then click the Settings icon on the left.
2. Select the System group followed by the Remote Desktop item.
3. Use the slider to enable Remote Desktop.
4. It is also recommended to keep the PC awake and discoverable to facilitate connections. Click Show settings to enable.
5. As needed, add users who can connect remotely by clicking Select users that can remotely access this PC.
   1. Members of the Administrators group automatically have access.
6. Make note of the name of this PC under How to connect to this PC. You’ll need this to configure the clients.

Windows 7 and early version of Windows 10

To configure your PC for remote access, download and run the Microsoft Remote Desktop Assistant. This assistant updates your system settings to enable remote access, ensures your computer is awake for connections, and checks that your firewall allows Remote Desktop connections.

All versions of Windows (Legacy method)

To enable Remote Desktop using the legacy system properties, follow the instructions to Connect to another computer using Remote Desktop Connection.

Should I enable Remote Desktop?

If you only want to access your PC when you are physically using it, you don’t need to enable Remote Desktop. Enabling Remote Desktop opens a port on your PC that is visible to your local network. You should only enable Remote Desktop in trusted networks, such as your home. You also don’t want to enable Remote Desktop on any PC where access is tightly controlled.

Be aware that when you enable access to Remote Desktop, you are granting anyone in the Administrators group, as well as any additional users you select, the ability to remotely access their accounts on the computer.

You should ensure that every account that has access to your PC is configured with a strong password.

Why allow connections only with Network Level Authentication?

If you want to restrict who can access your PC, choose to allow access only with Network Level Authentication (NLA). When you enable this option, users have to authenticate themselves to the network before they can connect to your PC. Allowing connections only from computers running Remote Desktop with NLA is a more secure authentication method that can help protect your computer from malicious users and software. To learn more about NLA and Remote Desktop, check out Configure NLA for RDS Connections.

If you’re remotely connecting to a PC on your home network from outside of that network, don’t select this option.