Archives mensuelles : juillet 2014

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.


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)


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

Pack de mises à jour Orchestrator 2012

C’est la livraison de l’été. Microsoft a mis à disposition les updates rollup pour la gamme System Center. Pour Orchestrator, on est donc maintenant avec :


Subtilité, pour Orchestrator 2012 R2, cela comprend aussi Service Management Automation (SMA) qui est livré sur le même média.


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

DirectAccess OTP Mystery case solved

Each month, Microsoft provide a bunch of updates for it’s operating systems and this month, the rollup contain an interesting fix for DirectAccess infrastructure. If we have a closer look at updates included we will find this one :


As your DirectAccess infrastructure must include a strong authentication mechanism, you will be happy to discover that Microsoft solved the  “0x80040001 OTP mystery case”. At first logon OTP works like a charm but later it stopped working. If we have a look at KB2973071 details, we will discover that the One-Time Password Certificate Enrollment (OTPCE) continued to use the expired certificate for authentication instead of the new one. As I was able to reproduce this with Windows 8.1 and Windows 7, maybe Microsoft provide an Hotfix for the “Legacy Windows 7 operating system”? Bingo : KB2939489.


If you want to know more about OTPCE, have a look at the protocol specifications available on MSDN.


So don’t forget to add these KB to your DirectAccess KB List.


Simple and Secure by design but Business compliant.

Le POC SCSM en prod, pas glop comme idée

Faire un POC en prod, voila une fausse bonne idée. On se dit qu’avec la version d’évaluation et ses 180 jours, on a tout le temps. Si le POC se transforme en production, faudra juste saisir le numéro de licence. Mais que se passe t’il si on dépasse la période d’évaluation avec SCSM?

Coté console SCSM, c’est pas très parlant.



Même la vue avancée ne nous avance pas plus “Unknow exception”.



La il faut parcourir le log “Operation Manager” pour découvrir la raison :



Cela semble clair. Petite recherche rapide chez Microsoft et on trouve l’information ci-dessous :



Conclusion, le POC en prod pour SCSM, est une véritable fausse bonne idée. Paie ta licence.


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