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

  • Article

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

Comments

  • Anonymous
    January 01, 2003
    Stephen:  XP does have a IPv6 Protocol, but it is not configured by default -- that started with Vista. While I have never tried it with XP, from a networking perspective, there is no reason it should not work for your helpdesk who originate the RDP.  The only major downfall I could see is if the RDP client for XP does not support IPv6. Kevin

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Dan:  Troubleshooting is always interesting.  :)  I suggest enabling PING via the firewall and verify that you can ping through the connection.  Next, I would set the firwall on the target Win7 (the host that is connected via Direct Access) to enable RDP from any host on all profiles.  Then you can start restricting it down to get to the settings you are looking for. Kevin

  • Anonymous
    January 01, 2003
    Dan:  Troubleshooting is always interesting.  :)  I suggest enabling PING via the firewall and verify that you can ping through the connection.  Next, I would set the firwall on the target Win7 (the host that is connected via Direct Access) to enable RDP from any host on all profiles.  Then you can start restricting it down to get to the settings you are looking for. Kevin

  • Anonymous
    September 15, 2010
    The comment has been removed

  • Anonymous
    September 30, 2010
    How do we go about troubleshooting this if it doesn't work?  I have a client machine that's working fine for inbound access to the LAN over Direct Access, but I can't get the remote management working.  I can see the IPv6 over IPv4 traffic hitting the UAG server, but can't connect to the client and I don't know how to work out what's wrong.  I've got what I think is the right firewall config on the client machine, and the firewall logs on the client aren't showing any dropped traffic (but if I try to connect to the machine locally from the LAN that they client is on then I see drops, so I know firewall logging is working okay).  thanks

  • Anonymous
    June 12, 2013
    I'm confused. In step 6, you say "We do not require security, as DirectAccess is already a secure tunnel." But there's nothing in this rule saying that it only applies to the secure tunnel. As far as I can tell, it will allow connections from any network. While it does specify that the connection must be initiated from an IP in a particular subnet, would it not be possible for an attacker to spoof that IP address?

  • Anonymous
    February 21, 2014
    Hi,

    What about IP-HTTPS interfaces? Is that the same configuration steps?
    We never succeeded in having isatap work, it always defaults to IP-HTTPS

  • Anonymous
    February 24, 2014
    Here are the top Microsoft Support solutions for the most common issues experienced when using Forefront

  • Anonymous
    August 24, 2016
    The comment has been removed