With disruptive flag enabled

Archives mensuelles : mars 2014

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

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.

No, DirectAccess is not a failure at all. But back to the UAG times, customers were expecting real-time monitoring of users access and resources previously accessed. Since Windows Server 2012 we have this feature (reporting) with enough detail to fill up databases :

By default, DirectAccess is only eligible to Enterprise edition of Windows. This licensing limitation did not help us during pre-sales of DirectAccess projects. It seems that Microsoft heard customers feedback and introduce some changes in it’s licensing agreements.

Since the first of march 2014, customers will be able to buy Windows 8 Enterprise edition without Software Assurance (as licensing details of each contracts are complex, please review your software licenses conditions for the small lines). Now there is on reason to do not deploy DirectAccess.

It’s been a long time I did not publish something in the DirectAccess Challenge series. Let’s do a deep dive in DirectAccess remote Management scenario. Be a Jedi Knight and use The DirectAccess force.

But wait. As master Yoda used to say “Long is the path to become a Jedi master of the DirectAccess ». Let’s start your learning.

Become my Padawan

Remote Management is one of the top feature of 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 requires an IPv6 connectivity from end to end. Since UAG 2010, NAT64/DNS64 feature was acting as a gateway between the IPv6 world and the IPv4 internal network, but this work only in that direction, its not bi-directional. When we think of remote management with DirectAccess, we always think of the DirectAccess for remote management only.

Interesting scenario but it’s quite limited as we loose some cool features. In this blog post we’ll see how to configure remote management with the default DirectAccess deployment scenario including security features. Time to improve you skills my Young apprentice.

Become a DirectAccess Apprentice

When a user using a DirectAccess client connected on Internet is requesting remote assistance (Windows remote Assistance or SCCM remote) to the helpdesk, it require an IPv6 network connectivity from the helpdesk computer to the DirectAccess client.

Even today, IPv6 is not so common (Force is not strong enough). The DirectAccess gateway act as a router for multiple IPv6 transition technologies, ISATAP is one of those. Microsoft does not recommend ISATAP global deployment. We only need it on a limited set of computers (helpdesk computers). I recommend the excellent Limiting ISATAP Services to DirectAccess Manage Out Clients from Jason Jones (a valuable former Forefront MVP) and DirectAccess Jedi master. In that strategy, we consider that only computers located on internal network (having an ISATAP address) can initiate remote management to DirectAccess clients connected on Internet. We trust them because of their location.

If an ISATAP configuration is operational on our DirectAccess gateway we should be able to retrieve it’s IPv6 address using a simple PowerShell command line.

In a single command we have all required information :

ISATAP link-local address

ISATAP unicast address

ISATAP prefix

For our scenario we’ll need the last two. From an ISATAP client point of view, ISATAP router is an IPv4 reachable host that provide an ISATAP prefix to be used to generate an ISATAP address. ISATAP is enabled by default on all Microsoft operating systems since Windows Vista. By default operating systems try to resolve the ISATAP.<Your domain> hostname. With a simple PowerShell command we can reconfigure both state and router parameters and confirm we have an operational ISATAP interface.

Of course, it can be configured using group policy parameters. It’s much more simple as we do not have a single helpdesk computer. You start learning well my apprentice.

And we can confirm, IPv6 network connectivity with a DirectAccess client connected on Internet work.

Let’s see that from the DirectAccess client side with a Message Analyzer trace. Don’t fear network traces my young apprentice. Use the force of Message Analyzer.

But a small reminder my young apprentice. If we see the ICMP message, it’s because it’s excluded of IPSEC tunnel because of default configuration provided to the DirectAccess client at firewall level:

Remember that ICMP messages are used by Teredo for signaling purpose my young apprentice. Easy, you think? Show me how you use the force and enable Remote Desktop.

And don’t forget to enable the corresponding incoming firewall rule.

Feel the force my young apprentice. Wait a minute, we have now a TCP and UDP rule for RDP since Windows 8 & Windows Server 2012? It’s a new capability included in RDP 8 to reduce networking overhead. RDP can display bandwidth-intensive content, such as video over high-latency networks (RDP Protocol).

In fact, it’s much more complicated, if we extend the profile column, we discover that Domain & private firewall provides share the same firewall incoming rule. So they must be enabled too.

At this stage, RDP remote management from a IPv6 capable host to a DirectAccess client is operational. Do you think you can pass the tests and become a DirectAccess Jedi knight.

Are you ready to become a DirectAccess Jedi knight?

Becoming a DirectAccess Jedi knight is much more than mastering the Jedi light saber or IPv6. In standard DirectAccess deployment, we have two tunnels Infrastructure and user. If user is not connected RDP won’t work. That’s because our ISATAP client is not allowed to go through the infrastructure tunnel. Let’s go back to the DirectAccess configuration side at the Infrastructure server setup.

We would add the hostname of our ISATAP enabled client in this interface. Watch-out young Jedi knight, your host must have a static IPv4 address or a DHCP reservation, otherwise it may not work for a long time.

At this stage, RDP would work once DirectAccess client can initiate a connection to the DirectAccess infrastructure, whatever a user is connected or not.

We are now sure that RDP network traffic always pass through IPSEC infrastructure tunnel. Time to fight the Sith Jedi knight

Fight the sith Jedi Knight

Never underestimate the power of the dark-side of the force Jedi knight. Are you sure it’s secure? Let’s have a look at the Windows Firewall profile of my DirectAccess client with the « Get-NetConnectionProfile » PowerShell command :

It’s the same rule for Domain and Private network profile. So if a user select « private » when he connect his computer first time he connect his laptop at home, RDP is available. But the rule apply both to IPv4 and IPv6! So a user connected on the same network can initiate RDP to the DirectAccess client. We have multiple solution to address this issue your Jedi knight :

Rewrite default incoming firewall rule

Force tunneling

Enforce public network profile

IPv6 Filtering

Try a Jedi mind trick

Resist to temptation of rewriting default incoming firewall rule. It’s the dark side of the force. Force tunneling is an option, but not realistic at all. It’s a non-choice from my point of view. Blocking the « private network profile » is a better option and it enhance DirectAccess user experience. The following group policy option allow to enforce public network location for any unidentified networks.

IPv6 filtering will be the easiest option. It rely on Windows Firewall, more precisely on the incoming firewall rule filtering capability. We have the ISATAP prefix we discussed earlier, we can use it for filtering purpose and configure the incoming rules composing the « Remote Desktop » group as illustrated bellow.

Just remember to configure each protocol to enforce IPv6 filtering using the ISATAP prefix. That’s a better option because we enforce IPv6 usage for RDP usage. Could we do better and deserve the rank of Jedi Master of the DirectAccess?

We cant deserve you the rank of master!

There are some Jedi mind tricks that could be used to provide a better approach that IPv6 filtering. But it will be for another blog post. Trust in network traces, IPv6, IPSEC and the DirectAccess force will be with you. Master Yoda will be coming soon to lean you that special Jedi mind trick.