How to enable Remote Desktop Sharing (RDS/RDP) from corporate machines to DirectAccess connected machines

Summary:

I had a customer ask how the helpdesk / support staff can connect to DirectAccess (Windows7) connected machines.  He asked because if they enabled “Remote Desktop Sharing” in the Firewall in the Public or Private Profile, it enabled it for all hosts – not just the corporate host via DirectAccess.  Another way of looking at this is: “Where is the DirectAccess Firewall Profile?”

Windows Firewall and DirectAccess:

DirectAccess requires the Microsoft Windows Firewall to work.  This is because the IPsec Polices are defined in the Windows Firewall.  If you turn off the firewall, neither IPsec nor DirectAccess will work.  Technically, you only need the Firewall Profile for the location you are connecting from.  This means you do not need the Domain Profile to be enabled, as this is only active when you are connected to the domain and then you do not need DirectAccess.  For some of my deployments, corporate customers do not want the Firewall on when inside the corporate network (Domain Profile) but they do want it on when outside, either in public locations (Public Profile) or at home office locations (usually Private Profile).

Because DirectAccess does not show up as a physical or virtual network card, there is no Profile associated with DirectAccess.  This means you can’t associate a specific rule with a “DirectAccess Profile” – it does not exist.  To work around this, we can use the use Public and Private Profiles and set the scope of the rule to match incoming DirectAccess communications, which will be IPv6.  Because we use IPv6 in Direct Access, any corporate client that wants to communicate to the DirectAccess clients must have an IPv6 address.  We can set up either a real IPv6 addressing scheme or set up ISATAP, which does not require IPv6 aware routers, switches or hubs.  For more information about ISATAP, see: https://www.microsoft.com/downloads/details.aspx?FamilyId=B8F50E07-17BF-4B5C-A1F9-5A09E2AF698B&displaylang=en.

From a security perspective the process below shows how to enable only RDP connections from the ISATAP Network.  With the IPsec policy that is already in place on a client computer when you configure DirectAccess, all traffic arriving from a computer on your intranet will travel inside of an IPsec-protected tunnel. The IPsec rule is configured to “require inbound and outbound” authentication, and this requires an SSL certificate.  With this configuration there is no need to create further IPsec rules to enforce protection of this traffic.

Security Recommendation:

From a security perspective, it is my strong recommendation that you always enable the firewall on both servers and clients.   This functionality gives you an added layer of protection and can help mitigate risk of network based security concerns.  This one factor alone can make the difference on a “high impact” patch / update.

The Setup:

For this particular setup, we need to set a client firewall setting.  To really scale, we will use Group Policy Objects (GPO).  Note we do not want to use the existing DirectAccess Client GPO, as this GPO is changed and could be deleted when we make changes to the Unified Access Gateway Server or the DirectAccess Server.

Step 1. From any machine with the Group Policy Management console, create a GPO, in my case it was named “DirectAccess Clients – RDS Override”.

1

Step 2. Edit this GPO so we can set the Firewall Settings.

clip_image002

Step 3. In the Windows Firewall with Advanced Settings create a new rule.

clip_image003

Step 4. Set the rule type to Port.  Note we do not want to override the existing “Remote Desktop” predefined rule.

clip_image004

Step 5. Set the Port value to TCP and port 3389.

clip_image005

Step 6. Set the action to allow.  We do not require security, as DirectAccess is already a secure tunnel.

clip_image006

Step 7. Set the Profile to Public and Private.  Domain is not required for this.

clip_image007

Step 8. Name the Rule, in my case I named it “Remote Desktop Services via DirectAccess”

clip_image008

Step 9. Next, we need to set the scope, so we will edit the properties of the rule.

clip_image009

Step 10. Go to the scope tab.  Here we will determine and add a value.

2

Step 11. Next we need to determine our ISATAP scheme.  On any corporate connected ISATAP enabled host, type IPCONFIG.EXE.  The screen below shows my ISATAP address as: 2002:c800:2:8000:0:5efe:10.214.1.38.  The ISATAP Router creates this network, in my case the router is my Unified Access Gateway (UAG) server.  Because I want more than one host to communicate to DirectAccess machines, I will take my entire ISATAP network and enable it.  Note: If you want just a subnet of machines, then you can adjust the mask from /96 to a finer scope, like /120 (which is a 94 bit mask + a 24 bit mask).  To enable the entire network, I calculate the network, so in my case I use: 2002:c800:2:8000:0:5efe:0.0.0.0/96, which is all ISATAP host.  If you are using load balancers, you will need to include that address (or range or addresses) as well.

clip_image011

Step 12. Take the network calculated in the step above and add it to the “Remote IP Address” list.

3

Step 13. Next click “apply” to apply the settings.

4

Step 14. Next based on Teredo needs, we need to select “Advanced” and set the “Edge traversal” to “Allow Edge Traversal”.  Then click OK to complete the settings.

5

Step 15. Close the GPO to save it and set the permissions on the GPO to only apply to the DirectAccess machines.  In my case, I used the same domain group that was used in the first setup of the DirectAccess wizard.

Step 16. Last, force the GPO to the client computers, either by rebooting the machine or running “GPUPDATE.EXE /FORCE” from an administrator’s command prompt.

Testing it out:

Once everything is set up, you can test it out.  From any corporate connected computer, first ping the name of the DirectAccess connected computer.  You should see it respond with an IPv6 address.  If this does not work, verify DNS setup, ISATAP setup or that the DirectAccess connected computer is on and functioning.

Next attempt a “Remote Desktop Connection” from the corporate connected computer to the name of the DirectAccess connected computer.  Assuming that Remote Desktop Services is enabled on the DirectAccess connected computer, it should work and perhaps prompt you for your credentials.

Additional Items:

What about pinging a Direct Access connected machine from a corporate machine?  Follow the same rules above, but at Step 4, select “Custom” and use the Protocols “ICMPv6”.  The following settings will be required:

Enabled:                             allow

All programs

Protocol:                              ICMPv6 ; ICMP type: Echo request

Remote IP Addresses:   <ISATAP subnet>

Profiles:                               Private, Public

Allow Edge traversal

What about “Remote Assistance” and not “Remote Desktop Services”?  Include the following settings:

First Entry:

Name:                                  Remote Assistance (DCOM-In) – DirectAccess

Enabled:                              allow

Program:                             %SystemRoot%\system32\svchost.exe

TCP local port:                   135

Remote IP Addresses:   <ISATAP subnet>

Profiles:                               Private, Public

Allow Edge Traversal

Second Entry:

Name:                                  Remote Assistance (RA Server TCP-In) – DirectAccess

Enabled:                              allow

Program:                             %SystemRoot%\system32\raserver.exe

TCP all ports

Remote IP Addresses:   <ISATAP subnet>

Profiles:                               Private, Public

Allow Edge Traversal

Author(s):

Kevin Saye, Security Technical Specialist – Microsoft

Eddie Huibers, Infrastructure Consultant - Microsoft

Contributor:

Pat Telford, Principal Consultant – Microsoft