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


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:

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”.


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


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


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


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


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


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


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


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


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


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:  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:, which is all ISATAP host.  If you are using load balancers, you will need to include that address (or range or addresses) as well.


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


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


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.


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


Kevin Saye, Security Technical Specialist – Microsoft

Eddie Huibers, Infrastructure Consultant - Microsoft


Pat Telford, Principal Consultant – Microsoft

Comments (10)

  1. 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.


  2. Anonymous says:

    I Type My Corp Isatap With Subnet For Example /96 Or /120 For Endpoint But Remote Can't Be Sucess When Change To Any Ip address  RDP Work So I Know that mY Wrong Calc Isatap subnet But  i Do Exactly as You did Above  

    Also I Can't Ping From Intranet To DA cLient (Teredo ) While Enable ICMP You Mention Above Only i Can Access Share


  3. 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.


  4. 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.


  5. stephen says:

    let say my helpdesk people are still using XP 32 bit machines.  Can these xp machines initiate remote assistant traffic to the DA client via the UAG (ISATAP router)?

  6. Dan_IT says:

    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

  7. Ryan Steele says:

    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?

  8. Orlando says:


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

  9. Anonymous says:

    Here are the top Microsoft Support solutions for the most common issues experienced when using Forefront

  10. Peter says:

    In my environment we have 3 Direct Access (DA) servers load balanced so ISATAP will not work, the only way to remote a client is from the DA server the client is connecting via. To do this you would have to RDP to the relevant DA server, and this causes another problem i.e. only two RDP session per server. Then I had a MAD idea. We also have a Citrix 7 environment, what happens if I also make the DA servers Citrix servers, this would allow me to publish a remote desktop tool from each of the DA servers and we wouldn’t be restricted by the number of connections. I have now tested this using Citrix XenApp 7.9 and it works like a dream. Currently you need to know which DA server you client is using and then run the relevant published app for the server, future developments will be a tool that can do that for you. This means anyone with the right permissions can remote desktop a DA client even if they are using DA themselves, or even from a non corporate home computer. I used Citrix because we have it already, but there is no reason why you couldn’t use Microsoft Terminal Services, which is available on the DA server.

Skip to main content