Remote Management is one of the top feature provided by DirectAccess. By default a DirectAccess client is able to reach internal resources such as SCCM server but the contrary is much more difficult as it require an IPv6 connectivity from end to end. Initiating a remote assistance (MSRA) from a helpdesk station located on LAN is much more complicated. Microsoft recommendation about ISATAP is to do not deploy it at enterprise scale level but limit it to only required hosts. I strongly recommend the Limiting ISATAP Services to DirectAccess Manage Out Clients from Jason Jones to understand initial configuration. If someday you wish to become a DirectAccess Jedi master have a look at my series of blog post to establish secure communication for Windows Remote Assistance :
Core of the problem
It’s cool to have Windows Remote Assistance for DirectAccess clients but it works because we have a built-in ISATAP router included with our DirectAccess Gateway. In some scenarios, feature will no longer be available. Have a look at the result of an HLB deployment scenario.
According to this excellent article we have two choices :
-
Place an external load balancer that supports ISATAP on the internal network and enable ISATAP on either DirectAccess servers
-
Disable ISATAP completely which then disables the “manage-out” functionality of DirectAccess.
Note that ISATAP routing capability is also unavailable in multi-site scenario.
Let’s analyze these options :
-
Option 1 : Having a load balancer that support ISATAP is not unrealistic at all but enabling ISATAP router on only one node is not. If that DirectAccess gateway happened to fail, ISATAP routing would stop too (SPOF Hunter)
-
Option 2 : If you are here, you’re looking for a solution to this problem, so abandon is not an option
We need a third option. I tried multiple options. Even a complete season of Doctor who did not provide me inspiration. If even the Doctor does not have the solution who will?
Two seasons of Doctor who were required to see the beginning of the solution.
What my blog say?
I used so sign my blog post by "Simple and Secure by Design but Business compliant". Too complicated does not means impossible. Let’s see the problem from another point of view. Until now we considered remote management as a IPv6 flow from an internal IPv6 capable client connecting to a DirectAccess client connected on Internet. That solution provide end to end IPv6 connectivity. That’s right but that’s not the only case. Just consider two DirectAccess clients connected on Internet. They both have IPv6 addresses. Would it be impossible to have two DirectAccess clients communicating together? Doctor, an advice? A screw-driver?
Are DirectAccess clients able to communicate each other?
If we just test with Resolve-DNSName PowerShell commandlet, a DirectAccess client is able to resolve DirectAccess names of other DirectAccess clients.
So if required network flow are correctly configured (never forget your NAT-Transversal configuration for incoming network flow), it should be OK. But each time we try to establish communication between DirectAccess clients it seems to fail. Why would two IPv6 hosts that seems to be located on the same network would be unable to communicate? Can we get the IPv6 prefix used to generate IPHTTPS addresses to check?
Correct, they depend on the same subnet (logic). So why two IPv6 hosts located on the same IPv6 network would be unable to communicate using global unicast addresses?
Two hosts located on the same IPv6 Subnet should be using Link local addresses to communicate? Because we have a DNS response with a Global Unicast Address, DirectAccess tunnels try to route our traffic to the internal network. What would happen if we try to communicate with the Link-local address. Here is the Link-local address of the interface of W82.DirectAccessLab.Lan :
And here is the result from W81.DirectAccesslab.Lan
You’re skeptical, need more evidence? OK, let’s go deep dive into the IPv6 routing
TRACERT.EXE reveal a direct communication without usage of the gateway, and the Get-NetRoute Powershell command validate that any FE80 prefix have the same destination (same subnet). We got it.
Wait a minute, What append to Security?
Good question. Have a look in the connection security rules node in your Windows Firewall console of a DirectAccess client :
Now you understand. Communication between DirectAccess clients are not protected by IPSEC rules. But you’re a Jedi master now, you were well trained with the DirectAccess remote management, from Padawan to Jedi Knight blog post series.
Show me your skill Jedi
If we can secure communication from internal IPv6 host to DirectAccess clients connected on Internet, it would not be difficult do to the same with two DirectAccess clients. All start with an isolation rule to create an IPSEC transport.
That will request authentication for any inbound/outbound communication (same rule for all DirectAccess clients whatever which one will initiate communication)
This rule will require some advanced authentication (just like DirectAccess IPSEC tunnels rules).
To make it simple, we will request dual authentication based on Kerberos protocol.
And this rule will only apply to public and private firewall profiles, we don’t need this extra-level of security on internal network.
At last we finally put a name on it.
Because you’re a Jedi master seating at the Jedi council, you filter the remote scope to only link local scope. We have here an extra-layer of isolation.
We have an IPSEC transport. Next point is to selected protocols to be configured for secure communication. Let’s have a look at protocol definition of the Remote Assistance feature. So inbound rules, outbound rules, but some of them are more interesting as they only apply to DirectAccess (public profile). If you remember an old blog post we can enhance user experience of DirectAccess by forcing the public profile for the Windows firewall for any newly identified network. This is helpful to be sure that users cannot consider a new network as private.
So we only need to secure communication for incoming protocol related to the public firewall profile. So two inbound rules to reconfigure. Don’t forget to enable Remote assistance and enable the required incoming firewall rules, especially the public rules.
Secure communication will mean authenticated and encrypted. Because connection must be secure, it will use our tunnel so only limit IPv6 for Windows Remote Assistance.
And we will be limiting our public incoming firewall rules to only a limited population represented by an Active Directory Security group. Only support team will be able to respond to a Windows Remote Assistance initiated by a DirectAccess client.
Now Windows Remote assistance between DirectAccess clients should be operational. Just try to send invitation. Network traffic between DirectAccess clients will be protected by an IPSEC transport. A simple Get-NetIPSECMainModeSA Powershell command will reveal an IPSEC transport between the two DirectAccess clients.
Need more proof? OK, let’s have a look at established communication, one is interesting. Let’s see witch process use it.
Now some additional tricks to make it works :
- KB2665206 : Slow performance when you enable IPsec encryption on a specific TCP port number in Windows 7 or in Windows Server 2008 R2
- KB2912883 : Remote Assistance connection to a Windows Direct Access client computer fails (Windows 7 & Windows 8)
- Why Update 1 of Windows 8.1/Windows 2012 R2 is important for DirectAccess?
- Some good reading to understand the Windows Remote Assistance protocols : [MS-RAI]: Remote Assistance Initiation Protocol
Like a other Doctor use to say. Use it :
Now you can call the psychiatrist. I deserve my straitjacket.
BenoîtS – Simple and Secure by Design but Business compliant
