DirectAccess remote management from Jedi knight to master seating at the Jedi council
Let’s continue our learning. Master Yoda did not deserve you the rank of master. You still have much more to learn about the power of DirectAccess. Let’s see what aspects of the force you have to improve your skills. Have a seat young Jedi. Time for master Yoda to reveal you last secrets of the DirectAccess force. Show me how you master IPSEC.
IPv6 Filtering at protocol level on DirectAccess client-side is not a choice for a DirectAccess Jedi Master. We are sure that communication is secure because it pass through the tunnel. But what would happen if an attacker understand your solution? With a simple network trace any attacker could easily recognize an ISATAP address structure (5EFE block). It would be easy to build an ISATAP router providing the same ISATAP prefix and bypass your IPV6 filtering based security. OK that’s the paranoid-mode point of view of an IT security guy. But as a Master of DirectAccess you must be able to face to the dark-side (from paranoid security guy point of view, only old legacy technologies respond to the new security challenge of tomorrow. For them NAT and port filtering represent the only answer).
To deserve the rank of DirectAccess Master you must prove your knowledge of the IPSEC force. It’s not the dark-side of the DirectAccess force. Let’s review some IPSEC basic:
- IPSEC tunnel
- IPSEC transport
IPSEC tunnels are used to secure communications between two networks through network equipment establishing a secure communication tunnel. Authentication header and payload are protected (AH+ESP). IPSEC tunnels are used by DirectAccess clients to connect to the DirectAccess gateway.
IPSEC transports are used to secure communications between two computers by establishing a secure communication transport (ESP only). It sound to be the same as IPSEC tunnels, except only payload it protected. Most of Jedi apprentices ignore the fourth step of a DirectAccess configuration:
It’s not the dark-side of the DirectAccess force. Dark-side is when you start customizing DirectAccess tunnels. Don’t even think about that! In DirectAccess, IPSEC transports can be used to extend authentication to a selected set of resources located on internal network.
Selected application servers mean IPv6 address are used as a criteria for the IPSEC transport. Providing end-to-end authentication and encryption between a DirectAccess client connected on Internet and a host located on internal network require good knowledge of the ISATAP. Fell the force around you Jedi knight and master the end-to-end authentication and encryption to secure your remote management.
At the source of the remote management
To become a DirectAccess master Jedi, you must overcome IPSEC transports and show you know what is behind the wizard. Objective is to isolate RDP protocol in an authenticated transport IPSEC. If we have an IPSEC transport, we must configure both side with matching parameters. Let’s start with the source of the traffic with the tunnel-definition on helpdesk computers.
We are talking of IPSEC, so unsheathe your light saber (Windows Firewall with Advanced security), select the “Connection Security Rules” node and select Isolation rule type. It seems to match to our need.
IPSEC transport means authentication. On this side of the transport, we’ll chose to request authentication for both inbound and outbound traffic but not enforce. Why master? Maybe your helpdesk is IPv6 capable and configured for ISATAP but I’m not sure the rest of your internal network support IPv6 and for sure we don’t have IPSEC generalized on LAN.
But what authentication? The default choice would lead to use IPSEC tunnels configuration provided for DirectAccess. If you think you deserve the rank of master, no other choice than “advanced”. Show you skills Jedi knight.
And what skills. We’ll be using a combination of computer certificate delivered to the helpdesk computers and user Kerberos as credentials.
With this choice, remote management will only be possible if initiated from clearly identified computer having a certificate and helpdesk user security context. Because helpdesk computer is located on LAN, there is no need to apply this connection security rule on private or public locations. If this computer is also a DirectAccess client, remote management will be impossible if connected on Internet (think of the paranoid IT security guy. What a shock it would be for him to discover that we can establish secure communication between DirectAccess clients located on Internet).
A connection security rule need a name. ISOLATION perfectly fit to our case.
Isolation yes but for what protocol? By default any protocol for witch the rule match the required conditions. To keep the case simple we’ll keep the default configuration (remember previous blog post, we discovered TCP/UDP port for RDP). Talking of condition we are. So what condition could we applied on the source-side? A good criteria would be DirectAccess clients connected on Internet. But how can we express it in IPv6? Because my DirectAccess infrastructure is not directly connected to Internet, IPHTTPS is the only IPV6 transition protocol (otherwise Teredo and 6to4 must be added). Let’s have a look at the ClientIpv6Prefix on the DirectAccess gateway with a simple Jedi trick: (Get-DaServer).ClientIpv6Prefix
With this we cover all DirectAccess clients connected on Internet. We just have to configure this IPv6 prefix as remote endpoint (from the helpdesk computer point of view) in the connection security rule. Question master. Why a /56 prefix and not /64. Good question Jedi Knight but even a master must keep some of his Jedi master tricks for another lesson. Just remember your UAG times, …
Now it’s time to move to the DirectAccess client-side of the IPSEC transport and setup a connection security rule that match the criteria.
To the DirectAccess client
If we have a transport IPSEC on one-side we must have a corresponding one on DirectAccess client-side. Its configuration is not identical point to point, but enough to allow transport authentication negotiation.
On the DirectAccess client-side, we should also have chosen the isolation mode (IPSEC transport).
This time authentication is no longer a wish but an order for incoming network flow and just a request for outgoing network flow. We don’t need extra security to access internal resources (the inception concept: IPSEC transport encapsulated in IPSEC tunnels included in IPHTTPS tunnel. A special one for paranoid-mode It security guy).
Here again me must configure authentication option. If they match on both sides, IPSEC transport will establish a secure communication. So it’s again an advanced configuration.
Because we have a certificate on the DirectAccess client why would not use it to prove we are a DirectAccess client (Kerberos Proxy mode is for padawan).
Because the connection security rule should only applied when connected on Internet, there is no need to keep the domain location (the opposite configuration of the helpdesk computer).
At last we need a name too. To make it simple, I keep the same.
IPSEC transport is almost operational, we just need to adapt the rule with a criteria that identify helpdesk computers connected on LAN. ISATAP prefix was designed for that. No need to apply this extra security to access internal resources.
But wait master, why do not apply the “fdca:abab:4a12:1::/64” prefix as provided by the ISATAP router? That’s a Jedi master trick. If you do so, you will have a connection security rule that enforce an IPSEC tunnel for that destination and an exception for the same IPV6 prefix. It’s an authentication exception rule configured with DirectAccess that say “no extra security needed to access resources depending on internal ISATAP prefix”.
This rule will override our rule. So my master Jedi trick is to add extra bit to the prefix. “Fdca:abab:4a12:1:0:5EFE:0:0:0:0/72” will be precise enough to have our isolation rule applied.
Master Yoda am’I deserved the rank of master?
There is a final test for that Jedi. Prove me your solution is now secure. Show me the IPSEC transport securing your DirectAccess Remote Management scenario. Easy it is master. Just have a look at the main mode security association, we can see an additional one coming from an ISATAP address when we launch the RDP connection. With a simple Jedi PowerShell trick, we can see the IPSEC transport main mode negotiated with our ISATAP client.
And this old Jedi master MS-DOS trick prove that RDP connection is established with IPv6, so RDP pass through the IPSEC transport rule.
We deserve you the rank of master but you won’t seat at the Jedi council.
Hurry you are Jedi. So hurry that you ignore one Jedi master trick you can use. IPSEC transport force is inside all protocols in your Windows Firewall with Advanced Security console.
Is that unfair? Securing IPv6 network flow is excellent but what would happen if we try to reach your DirectAccess client with IPv4. Isolation rule will not match but the RDP layer will respond to the request. You just missed a simple checkbox to enforce secured connection to be used for that protocol.
Now your remote management DirectAccess scenario is secure. Even a master still have to learn. If you trust in DirectAccess force, never forget to secure your remote management and never fall to the dark-side of DirectAccess.
BenoîtS – Simple and Secure by Design but Business compliant