Archives de catégorie : DirectAccess challenge

Breaking the myth of DirectAccess end-to-end scenario – Part 6

After enabling the IPsec logging on our internal server we will have new security events logged on this server. When VIP user logged on a DirectAccess client located on Internet try to access sensitive data, we will see that in the Windows Firewall with Advanced Security console.

clip_image001

It’s our new IPsec Tunnel initiated from our DirectAccess client. In the security event log we will found events like this one, proving computer authentication:

clip_image002

And also user authentication.

clip_image003

Bonus, what would happened if we change the security group with something like « NT AUTHORITY\Organization Certificate » as filtering security group as illustrated bellow:

clip_image004

My VIP will require to logon with his smartcard to initialize IPSEC tunnel with the internal server, not because required certificate is on the smartcard but because when we log with a smartcard, we are automatically member of this group.

clip_image005

When user see this message on DirectAccess client-side, we have the following event on our internal server

clip_image006

So my VIP need his smartcard.

clip_image007

That’s the end of this blog-post series. Hope you enjoyed. It’s time for me to go back to clouds.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 5

Connection Security Rules are now in place on both sides. We just need some additional magic trick. First, I recommand to excempt ICMP messages from IPsec tunnels that end on our internal server. It’s for debuging purpose. It’s configurable at the Windows Firewall with advanced security, in the IPsec Settings tags.

clip_image001

 

Remember, it’s just for debugging purpose and helped me a lot to understand what happened under the hood. Last configuration, we need to configure the authorization model. It’s not at the Connection Security Rule level but at the Windows Firewall with Advanced Security node, in the IPsec settings tab and my recommendation would be to do not configure this setting in a GPO but directly on each server. With this approach, our server-side GPO remain generic.

clip_image002

 

Now it’s time for the big magic trick. You can test now if you want, you are not able to access internal server with sensitive data. It took me a long time (and a lot of aspirin) to understand why until I noticed this fucking checkbox in the infrastructure IPsec tunnel configuration on DirectAccess gateway.

clip_image003

 

In our scenario, our new Connection Security Rule is never used even if destination match because another Connection Security Rule is already applicable. That’s our case. On the DirectAccess gateway, default configuration includes two Connection Security Rules:

  • DirectAccess Policy-ClientToInfra (Infrastructure IPsec tunnel)
  • DirectAccess Policy-ClientToCorp (User IPsec tunnel)

Problem is located in this tunnel. If we have a look at tunnel endpoints, it include the 2002:836b:a:1::/64 prefix.

clip_image004

 

And my internal IPv6 destination is 2002:836B:a:1:0:5efe:192.168.1.101. It means that for this destination, traffic will go through the IPsec infrastructure tunnel. We have the same problem on the DirectAccess client-side. To solve this problem, we need to reconfigure default configuration for the DirectAccess Policy-ClientToCorp specify that network traffic that matches another IPsec connection security rule does not go through the IPsec tunnel.

That’s a big problem. If we use GPMC to reconfigure the required parameters (in both GPO), we risk to things:

 

Because I spend now most of my time in clouds, I wrote a small PowerShell script that perform the following actions:

  1. Check for execution prerequisites (GPMC, RemoteAccess, …)
  2. Search a writable domain controller (PDCE in fact)
  3. Perform a Backup of Server-side and client-side GPO
  4. Create a GPOSession object to update required parameters in both GPO
  5. Update the required parameter in the GPOSession object
  6. Update GPO with the GPOSession

 

PowerShell script is available here.

Here an example of the script output with the STATE parameter. Script found DirectAccess GPOs and checked we have the default configuration.

clip_image005

And now the same script with the ENABLE parameter that enable our required parameter in both GPOs.

clip_image006

At this point, you are no longer supported by Microsoft as you just customized GPO configuration of DirectAccess. That’s why script alse have the DISABLE parameter to revert to initial configuration.

clip_image007

 

In a standard DirectAccess infrastructure, all IPsec tunnels terminate at the DirectAccess Gateway witch have an IPsec DOS protection layer. As our additional IPsec tunnel won’t terminate on the DirectAccess Gateway, we won’t be able to use extra security layer. If I have a look at Server-side GPO, now the checkbox is enabled on our DirectAccess gateway.

clip_image008

 

And on the DirectAccess client-side GPO configuration, it’s the same.

clip_image009

 

Now our new IPsec tunnel is operational. We will see that in the next blog post.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 4

If we have a client-side configuration of the tunnel, we need a remote-side. This configuration will be applied by GPO on our internal server with sensitive data.

clip_image001

It’s logic, we choose the oposite choice on remote side of the IPSEC tunnel.

clip_image002

Our internal Server will be the remote endpoint of the IPSEC tunnel. We must enforce authentication for inbound and ountbound communications.

clip_image003

If we require authentication we must also enforce authorization on the local tunnel endpoint. But wait a minute where is the IPv6 address of our internal server? You can include it yes. But if you do so, you will generate as much as GPO as internal server to secure. With my approach, we generate a generic GPO, applicable to a large number of internal server. You AD admin team will appreciate.

clip_image004

Because we are requesting authentication for inbound and outbound communications, we must have the same configuration on both sides of the IPsec tunnel. Our authentication will be composed of primary and a secondary authentication method.

clip_image005

It’s exactly the same configuration as on DirectAccess client-side. That’s my choice, to be able to filter on a computer or user criteria.

clip_image006

But one important point here. This configuration will only work if you have a certificate delivered to your internal server and this certificate must be delivered by the same Public Key infrastructure as the one used for DirectAccess clients. This new Connection Security Rule will only apply on Domain Windows Firewall profile.

clip_image007

This Connection Security rule will be name « SECURED ZONE ».

clip_image008

Now it’s time for a magic trick. Our new Connection Security Rule apply to all domain traffic, including both internal and external access (IE DirectAccess). Problem, I do not want to enforce IPSEC for internal access (not yet). That’s why I need an exception to manage this case. We will introduce a new Connection Security Rule on GPO targeting our server with sensitive data. This will be an Authentication exception.

clip_image009

This exception will cover my complete IPv4 internal IP range. If you already have IPv6 capable systems on your internal network that need to communicate with our secured server, I would recommend you to add these IP to the list, unless you want to establish a secure communication with IPsec tunnels.

clip_image010

This exception will only apply to the Domain Windows Firewall profile.

clip_image011

This Connection Security Rule will be named « LAN EXCEPTIONS ».

clip_image012

OK, prerequisites are in place. It’s time for the big magic trick. Why? Because at this stage, it does not work. That’s the most interesting part, unless you want to send your time hitting your head against the walls to find the solution.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 3

Let the fun begin and create new IPsec tunnel. We will be starting with the client-side. We will introduce this GPO configuration on a dedicated GPO applicable to our DirectAccess clients. Remember, it’s not supported to customize DirectAccess configuration (We will break that rule later, …).

clip_image001

We are in a client-to-gateway configuration and we to need to ensure that if network traffic match this rule we use this tunnel.

clip_image002

During IPsec Initialization, DirectAccess client send authentication information. These information will be required for filtering purpose on the DirectAccess gateway side.

clip_image003

On client-side of the tunnel our new tunnel must only be used if we try to access our server with sensitive information. IPv6 address of this server will be configured as a remote endpoint.

clip_image004

IPsec authentication is a negotiation process (Show me who you are and show me who are you).

I wanted to provide the same security level as default DirectAccess IPsec tunnels, so I choose to use a primary and a secondary authentications methods.

clip_image005

My choice, using Computer certificate plus Computer Kerberos ticket as primary authentication methods and only user Kerberos ticket for secondary authentication methods. With this choice I will be able to filter access based on computer account group membership or user account membership.

clip_image006

At last, this new IPSEC tunnel must only apply on DirectAccess scenarios, so limited to private and public firewall profiles.

clip_image007

This Connection Security rule will be name « SECURED ZONE ».

clip_image008

That’s all on DirectAccess client-side. On DirectAccess gateway-side we will follow the same logic. So until now it’s not so complicated. Not yet. Don’t worry headache is on the way.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 2

To make it clear. Every time we deployed DirectAccess, we always skip the optional configuration part. I’m talking about this screen.

clip_image001

 

First reason, application server must be IPv6 ready. IPv6 ready can be ISATAP or native IPv6. That’s the first challenge. Because it’s only a demonstration, environment built for this blog post will, I will be using ISATAP, not native IPv6 for internal network. I wanted to make the content more digest. In real production environment ISATAP would not be supported for multiple reasons but the same approach can be used.

So my first step will be to configure my internal server with sensitive datas as ISATAP client of my ISATAP router. By Default ISATAP DNS record is blocked for name resolution because it’s on the DNS Query Block List. Not a problem we will be configuring ISATAP client locally with a single Powershell command : Set-NetIsatapConfiguration -Router srv.directaccesslab.lan -PolicyStore PersistentStore :

clip_image002

 

Now in DNS I have two records for this server.

clip_image003

 

But on my DirectAccess client, name resolution does not provide the expected result. It’s not because of ISATAP, we would have the same problem with native IPv6. Where does this address come from?

clip_image004

 

If you are a DirectAccess expert, you immediatly recognize a NAT64 prefix and you know why if you are familiar to this old blog post of mine : DNS64 behavior change in Windows Server 2012. By default, the DirectAccess configuration no longer resolve IPv6 host names since Windows Server 2012. If we take a closer look at the DNS64 configuration, we will discover that in default configuration, only A records are resolved.

clip_image005

 

To enforce IPv6 DNS name resolution, we will reconfigure DNS64 configuration with the following command: Set-NetDNSTransitionConfiguration -OnlySendAQuery $false

clip_image006

 

After DNS64 reconfiguration, name resolution is better on DirectAccess client-side.

clip_image007

 

Even if DNS64 provide IPv6 addressing, it’s not IPv6 traffic than reach the internal Server. NAT64 act as a translation device between IPv6 on the ourtide and IPv4 on the internal network. Would be difficult to establish an IPsec tunnel in such situation.

Now we have IPv6 addressing from end to end, we can discuss about establishing new IPSEC tunnels. By default DirectAccess configuration generate two types of tunnels :

  • Infrastructure tunnel (IPSEC Tunnel mode)
  • User tunnel (IPSEC Tunnel mode)

If we use the approach proposed by Tom Shinder, this lead to a new IPSEC Transport. Too complicated to secure and not challenging enought. I already covered such scenario in this blog post series

So we will introduce a new IPsec Tunnel, starting in next post.

 

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Breaking the myth of DirectAccess end-to-end scenario – Part 1

It’s been a while since i published content on DirectAccess, that’s also why this post is in English. As I spend more and more of my time with Cloud Business (for Blue team), I do not spend much more time on DirectAccess. These days I had time to explore my OneNote on DirectAccess and rediscovered a subject we are not so much to deal with: The end-to end-mode of DirectAccess, the Myth of end to end security. That will be the subject of this blob post-series. Do you remember if the early days of DirectAccess, we used to present such diagram?

clip_image001

In such scenario a DirectAccess infrastructure could be configured to offer an extra security layer for VIP trying to access sensitive data. VIP would be invited to use his smartcard to authenticate to initialize the application tunnel. For many people, it was a myth. In fact not really some smart people published some content about this : A Short Introduction to UAG DirectAccess End to End Security. It was very helpful to be to start thinking. It was UAG based but we are able to do it with Windows 2012 R2, nothing changed.

clip_image002

But one point is missing in Tom Shinder article (Sorry). How do we filter connections and add our extra security layer (enforce smartcard authentication to access servers with sensitive data? That the pain point. In fact, it’s possible with Tom Shinder approach but complex. Why? Because it relies on IPsec transports, not IPsec tunnels. This means that we must secure each incoming protocol at the Windows Firewall level of our servers to enforce a specific option

clip_image003

It’s possible from a technical point of view but complex to setup and maintain. Would it be possible to secure all communications? Yes, but it would rely on IPsec tunnels, not IPsec Transports. This is a hudge change that require to customize default DirectAccess configuration, what is not supported by Microsoft.

It will be a long path to achieve this objective, so multiple blogs posts will be needed:

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Monitoring DirectAccess with Kemp

Introduction

DirectAccess is a wonderful remote access solution highly appreciated by end-users, happy they are to do not have to understand how it works, it just work. On the other side, we have the network team that is not really happy when they discover that monitoring DirectAccess can become complicated, especially for HLB deployments.

From an HLB point of view, DirectAccess gateways are only HTTPS endpoints. If they respond with an HTTP 200 response code, it means that it’s up and running. In reality it’s much more complicated. DirectAccess rely on multiple components. If a single one come to be unhealthy, DirectAccess is no longer able to operate properly. In many deployments, customers of mine chosen to deploy DirectAccess in HLB scenario such as F5 or Kemp. Those appliances are able to check DirectAccess gateways availability by checking IPHTTPS endpoint. Not easy to monitor.

How to monitor DirectAccess health?

It’s a good question. Microsoft provide the Remote Access Management console, some Powershell Commandlets and a Management Pack. From HLB solution vendor hey only have HTTP response. It appear to be complicated because many network teams consider that they have to discover information by their own way.

It’s time to consider another approach. If HLB solution cannot evaluate the health status of a DirectAccess gateway maybe DirectAccess gateway can provide this information to the HLB solution. Have a look at Exchange 2013 Managed Availability. Exchange 2013 generate probe pages to be used by load-balancer solution. If they can reach the probe page, status is OK. It’s a very interesting approach.

Let’s start see how we can develop the same approach with DirectAccess. If we have a look at the Get-RemoteAccessHealth Powershell commandlet, we got almost all we need. In example bellow, I just filtered relevant components to be monitored :

Get-RemoteAccessHealth -Verbose | Where {$_.HealthState -ne « Disabled »} | Format-Table -Property Component, HealthState – AutoSize

clip_image001

 

That was only the beginning. While writing this article, a valuable MVP colleague pointed out that we don’t need to consider Network Location Server availability because if it’s not available, it does not disrupt service offered to end-users located outside company building (it’s another problem for users located on corporate network). So we will exclude this component from the tests. Here is the test we will be using to monitor DirectAccess :

Get-RemoteAccessHealth -Verbose | Where {($_.HealthState -ne « Disabled ») -And ($_.Component -Ne « Network Location Server ») -And ($_.Component -Ne « Server »)}

clip_image002

 

Note : Server was excluded from the list because it does not provide a relevant information for monitoring / troubleshooting.

Once we have relevant monitoring information, next challenge is to provide this information in a comprehensive form for a HLB solution. It’s too complicated to write rule to parse this content, that’s why I was considering the Managed Availability feature of Exchange 2013. As I’m not a dev-guy, I know I could not develop a solution like this. My approach was a little bit more basic :

  • Status is OK : Create a probe page to be monitored by the HLB solution
  • Status is not OK : Delete the probe page to be used by the HLB solution

This approach worked, but it was not as elegant as the Managed Availability feature of Exchange 2013. After some discussions with a colleague of mine, he pointed out the availability of a Powershell commandlet for Kemp load balancers. While reading the Kemp documentation, I discovered how easy it was to query and change configuration in Kemp LoadMaster appliance with just some PowerShell commands. If Kemp cannot consume monitoring information my DirectAccess gateway produce, maybe just more simple to change Kemp load balancer configuration.

 

The Kemp Approach

Kemp provide a pretty good Deployment guide for DirectAccess. I would like to thanks Richard Hicks, valuable MVP working like me on DirectAccess for this excellent contribution. So it was very easy to build an HLB lab in less than two hours. Diagram bellow only focus on high availability for DirectAccess deployment, you can also use Kemp solution to provide high availability for the Network Location Server.

clip_image003

 

When we setup DirectAccess in HLB scenario, up to height DirectAccess gateway will share a common configuration and some network information :

  • A virtual Address for the external interface managed by the External load balancer
  • A virtual Address for the internal interface managed by the Internal Load balancer

In Kemp, load balancing is managed with virtual services. That’s the object I will be looking for in my configuration. But first I need to configure the Web Administrative Access in Kemp as illustrated bellow to enable Kemp API access from the Internal network interface.

clip_image004

 

Now we can start using PowerShell to authenticate against the Kemp appliance with the Initialize-LoadBalancer Powershell command. We just need to build a secure string for the password. Once authenticated, we can test if communication is established with a Test-ServerConnection command.

$KempAPI = 192.168.2.115″

$KempPort = 443

$KempAdmin = « bal »

$KempPassword = « Password123 »

$SecureString = ConvertTo-SecureString -String $KempPassword -AsPlainText -Force

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $KempAdmin, $SecureString

Initialize-LoadBalancer -Address $KempAPI, LBPort $KempPort -Credential $credential

Test-ServerConnection -ComputerName $KempApi -Port $KempPort

clip_image005

 

Note : Watch-out, account is case sensitive!!

It’s time to explore virtual services with the Get-VirtualService Powershell Command :

$VirtualServiceName = « DirectAccess-IPHTTPS »

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

clip_image006

 

We have here some valuable piece of information. First, we know that external VIP is running and directing HTTPS network traffic to some Real Servers. In my environment, I have two DirectAccess gateway configured in a single HLB configuration. So it’s logic to have two real servers behind the external VIP. Let’s have more details about real servers by exploring the Virtual Service Object :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

clip_image007

 

We just need to be more precise, what is the status of the Real server linked to a specific DirectAccess gateway. We just need to know the external IPv4 address of our DirectAccess gateway. Too easy :

$InternetInterfaceName = (Get-DaServer).InternetInterface

$InternetIPAddress = ((Get-NetIPConfiguration -InterfaceAlias $InternetInterfaceName).IPv4Address).IpAddress

$InternetIPAddress

clip_image008

 
Now the magic trick

We know the status of our DirectAccess gateway, we know how to query the status of the external VIP and related real servers. Now we just need to be able to change the status of the real server linked to our DirectAccess gateway. In case bellow, I will be considering that my second gateway is no longer able to service end-users. I will be using the Disable-RealServer Powershell Command to disable the linked real server :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

Disable-RealServer -IpAddress $InternetIpAddress

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

clip_image009

 

Related real service is now disabled on Kemp external load balancer.

 

Envision the big picture

Before starting developing the big thing, here are the guideline I used to develop my script :

  • Each DirectAccess gateway will be responsible to evaluate its own status (So script will be running on all DirectAccess gateway composing my HLB deployment)

  • Each DirectAccess gateway will be updating only linked real server (We’ve just seen how to get it)

  • Each gateway must manage a « maintenance flag » in order to close service (for patch management for example)

  • All activity must be logged in event logs in order to keep trace of information in monitoring solution such as SCOM

  • Keep the script as simple as possible

  • Script will be relying on Powershell wrapper provided by Kemp

Script is available at this location. It was designed to run as scheduled task on each DirectAccess node involved in an HLB configuration. Script accept the following parameters :

  • KempAPI : Mandatory parameter that must contain name or IP address of the Kemp LoadMaster with Web Administrative Access enabled

  • KempPort : Not mandatory parameter, default value is 443

  • KempAdmin : Mandatory parameter that must contain account with administrative access to Kemp LoadMaster. Watch-out, Kemp is case sensitive for account!!

  • KempPassword : Mandatory parameter that must contain the password to be used with the KempAdmin parameter

  • VirtualServiceName : Mandatory parameter that must contain name of the virtual service for the External VIP of DirectAccess

Let’s see some situations. Script detect that DirectAccess node is not healthy and reconfigure real server status to do not forward network traffic to that failing node.

clip_image010

 

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now disabled.

clip_image011

 

When problem was fixed, script detected that DirectAccess node is now healthy, Real server status for 192.168.2.211 is updated to forward network traffic to restored node.

clip_image012

 

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now Enabled.

clip_image013

 

So it’s not so complicated to monitor DirectAccess after all.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Windows Remote Assistance between DirectAccess clients made easy and simple

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.

clip_image001

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?

clip_image002

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.

clip_image003

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?

clip_image004

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?

clip_image005

 

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 :

clip_image006

And here is the result from W81.DirectAccesslab.Lan

clip_image007

 

You’re skeptical, need more evidence? OK, let’s go deep dive into the IPv6 routing

clip_image008

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 :

clip_image009

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.

clip_image010

 

That will request authentication for any inbound/outbound communication (same rule for all DirectAccess clients whatever which one will initiate communication)

clip_image011

 

This rule will require some advanced authentication (just like DirectAccess IPSEC tunnels rules).

clip_image012

 

To make it simple, we will request dual authentication based on Kerberos protocol.

clip_image013

 

And this rule will only apply to public and private firewall profiles, we don’t need this extra-level of security on internal network.

clip_image014

 

At last we finally put a name on it.

clip_image015

 

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.

clip_image016

 

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.

clip_image017

 

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.

clip_image018

 

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.

clip_image019

 

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.

clip_image020

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.

clip_image021

 

Need more proof? OK, let’s have a look at established communication, one is interesting. Let’s see witch process use it.

clip_image022

 

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)

 

Like a other Doctor use to say. Use it :

useit

 

Now you can call the psychiatrist. I deserve my straitjacket.

 

BenoîtS – Simple and Secure by Design but Business compliant

DirectAccess remote management from Jedi knight to master seating at the Jedi council

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.

clip_image002[7]

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:

clip_image004

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.

clip_image005

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

clip_image007

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.

clip_image009

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.

clip_image010

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.

clip_image011

And what skills. We’ll be using a combination of computer certificate delivered to the helpdesk computers and user Kerberos as credentials.

clip_image012

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

clip_image013

A connection security rule need a name. ISOLATION perfectly fit to our case.

clip_image014

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

clip_image016

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, …

clip_image018

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

clip_image020

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

clip_image021

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

clip_image022

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.

clip_image023

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

clip_image024

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

clip_image025

At last we need a name too. To make it simple, I keep the same.

clip_image026

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.

clip_image028

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

clip_image030

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.

clip_image032

And this old Jedi master MS-DOS trick prove that RDP connection is established with IPv6, so RDP pass through the IPSEC transport rule.

clip_image034

We deserve you the rank of master but you won’t seat at the Jedi council.

clip_image036

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.

clip_image038

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

DirectAccess remote management, from Padawan to Jedi Knight

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.

jedi32

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.

clip_image002

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.

By default, our DirectAccess gateway act as an ISATAP router. A simple « Get-NetIsatapConfiguration » PowerShell command reveal the hostname of the ISATAP router. As it’s not registered in our DNS, IPv6 capable systems cannot locate it and cannot generate their ISATAP address (DNS Global Query Block List).

clip_image003

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.

clip_image004

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.

clip_image005

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.

clip_image006

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

clip_image007

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.

clip_image008

 

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:

clip_image009

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.

clip_image010

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

clip_image011

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.

clip_image012

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.

clip_image013

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.

clip_image014

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

clip_image015

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 :

clip_image016

In my case, it respond « Private ». Do you understand? No? Remember the incoming firewall rules :

clip_image017

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.

clip_image018

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.

clip_image019

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.

arme_sabre_yoda_02

BenoîtS – Simple and Secure by Design but Business compliant