DirectAccess now supported in Azure virtual machines

I was expecting this news for a while. Until a few days, DirectAccess was considered as unsupported scenario in Azure according to KB2721672. On the 14th of July this year, this KB was updated. The Remote Access feature is not longer listed as unsupported and appear in the supported features list.

clip_image001

 

Hosting a DirectAccess infrastructure in Azure introduce a new way to build IT. Everyday that pass, the need to a local IT infrastructure is reducing. Soon, we could consider building a complete IT infrastructure hosted in Azure and connect computers to it using DirectAccess.

Dear, I have other wishes about DirectAccess :

  • ARM template to build a DirectAccess infrastructure in Azure (using a certificate located in Azure Keyvault of course)
  • Having DirectAccess as a VPN gateway scenario choice

 

Thank you for the news Richard.

­

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

C’est l’heure de la chasse au SHA1

La prochaine mise à jour de Windows 10 arrive à grand pas. C’est prévu à partir du 2 Aout 2016, tout le monde est au courant. C’est un process d’upgrade bien maîtrisé (on est tous passé par le programme Windows Insiders, …). Le problème, c’est qu’avec cette nouvelle Build, Microsoft a changé les règles pour les certificats. En même temps, ça devenait urgent. D’autres éditeurs comme Google ont déjà franchi le pas. SHA1 n’est plus considéré comme un algorithme de signature fiable. Le problème, c’est que cela ne concerne pas que Windows 10. Microsoft a mis le temps pour communiquer sur le sujet mais maintenant, c’est clair : An update to our SHA-1 deprecation roadmap. Le paragraphe ci-dessous est on ne peut plus clair :

This update will be delivered to Microsoft Edge on Windows 10 and Internet Explorer 11 on Windows 7, Windows 8.1 and Windows 10, and will only impact certificates that chain to a CA in the Microsoft Trusted Root Certificate program. Both Microsoft Edge and Internet Explorer 11 will provide additional details in the F12 Developer Tools console to assist site administrators and developers.

 

Une lecture de l’article Windows Enforcement of Authenticode Code Signing and Timestamping à la section Enforcement in general sera tout aussi claire :

clip_image001

 

Le véritable problème, ce seront Edge et Internet Explorer (pour toutes les versions de Windows supportées ) qui n’accepteront plus de reconnaître de certificats utilisant SHA1 comme sécurisés. Conclusion, je recommande vivement de partir à la chasse au SHA1. Le problème, c’est de les localiser le plus efficacement possible.

Pour vérifier si on a ce type de certificats, on va passer par PowerShell, c’est très simple. On commence par créer un objet contenant la liste des certificats contenus dans le magasin personnel de notre poste de travail de la manière suivante :

$Certs = Get-ChildItem cert:\LocalMachine\My

clip_image002

 

OK, on a quatre certificats dans le magasin personnel. Le problème, c’est que brut de fonderie, cela ne nous parle pas beaucoup.

clip_image003

 

Pour que cela nous parle, on a besoin de plus d’informations. Commençons par voir de quoi est composé un objet certificat dans PowerShell :

clip_image004

 

La liste contient des méthodes mais aussi des propriétés et il y en a deux qui nous intéressent.

clip_image005

 

La propriété « Subject » est ce qu’il y a de plus parlant pour désigner un certificat. Par contre brut de fonderie, le « SignatureAlgorithm » ne nous parlera pas beaucoup, à moins de savoir lire entre les lignes. Avec son « FriendlyName », c’est tout de suite plus compréhensible. Maintenant, on sait qu’on a un mauvais SHA à chasser.

clip_image006

 

Ne reste plus qu’à voir à quel certificat cela correspond.

clip_image007

 

C’est un auto-signé. Maintenant, avec un peu plus de détails on retrouvera peut être l’application concernée :

clip_image008

 

Le plus moche dans mon cas, c’est que ce certificat a été généré sur mon poste pour installer Visual Studio 2015. Donc même avec les dernières versions des outils Microsoft, on n’est pas à l’abris de ce type de surprise.

Si on est capable de réaliser l’opération localement, on doit pouvoir faire de même en PowerShell Remoting si on a pensé à activer et sécuriser correctement le protocole.

OK, donc avant de procéder à la mise à niveau vers Windows 10 update anniversary 2016, faudra commencer par traiter les applications qui utilisent toujours des certificats SHA1. Pour une approche plus industrielle de la recherche, je vous recommande ce script publié sur le Script Center : SHA1 Certificate Signature Check (Updated)

Si le certificat incriminé a été délivré par votre autorité de certification interne, c’est qu’il faudra envisager une migration vers SHA2. Je conseille alors la lecture d’un ancien billet : ADCS, quick and dirty et conséquences.

­

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

A quoi ça sert de locker ses ressources dans Azure?

La notion de Lock existe depuis un certain temps, pourtant, c’est en voyant sa disponibilité dans le portail Azure que je me suis dit que ce serait intéressant d’écrire un billet sur le sujet. Globalement, l’idée est de pouvoir verrouiller des ressources, un ensemble de ressources (groupe de ressources) ou même carrément une souscription de manière à ce qu’aucune opération de modification ne puisse être réalisée tant que le lock est présent. Pendant un déploiement, cela a du sens (éviter les conflits entre plusieurs opérations menées en parallèle). Pour moi, cela permet aussi d’éviter les erreurs fatales ou le scénario « Dédé fait du Cloud Computing ».

Imaginons un scénario dans lequel notre système d’information a basculé dans le cloud, que nous sommes capables de travailler en déploiement continu, un monde presque parfait. Avec les templates ARM, on est sur une approche d’intégration continue, on modifie son template, on teste son déploiement pour valider qu’il fonctionne puis on recommence. Pour cela, on a pris l’habitude de supprimer le groupe de ressources contenant nos ressources. C’est bien mais le problème, c’est qu’avec le temps se créé des dépendances invisibles. Dans l’organisation de notre souscription, il y a des ressources qui seront liées à la sécurité ou au réseau. Ce sont des ressources communes qui seront consommées dans d’autres groupes de ressources (quelle machine virtuelle n’a pas besoin de connectivité réseau ?). Supprimer et redéployer une machine virtuelle n’est pas risqué. Par contre si on supprime le groupe de ressources dédié aux ressources réseau, c’est beaucoup moins marrant. Imaginez qu’on réponde oui à la question suivante, juste par habitude de ne plus lire le message d’avertissement ?

clip_image001

C’est pour éviter ce type de scénario qu’on a inventé la fonctionnalité de verrouillage de ressources dans Azure. Si on a utilisé la fonctionnalité Lock, on aura la réponse suivante :

clip_image002

Si on clique sur le message, on sera amené à l’interface de gestion des locks. On découvre que même si j’ai tous les privilèges sur mon groupe de ressources (genre je suis le propriétaire), ben j’ai quand même un garde-fou qui va me rappeler que je vais peut-être faire une connerie.

clip_image003

Là, normalement « Dédé » (nous l’appelons Dédé pour ne pas dévoiler son identité) devrait se dire qu’il vient d’éviter de faire une superbe connerie. Des machines virtuelles sans connectivité réseau, ça perd quand même beaucoup de son intérêt. Si Dédé décide de s’acharner, et de passer en PowerShell, il y passera un peu de temps avant de comprendre la nature de son problème.

clip_image004

La fonctionnalité a quand même une limite. Si Dédé a les permissions suffisantes sur la ressource, le groupe de ressources ou la souscription, il peut supprimer le lock. Par contre, dans les logs, on aura la trace qu’il a délibérément décidé de se tirer une balle dans le pied. Le scénario « Dédé fait de l’Azure » est pour moi le meilleur cas d’usage du verrouillage de ressources.

Maintenant, voyons comment cela fonctionne et ce que propose le module PowerShell AzureRMresources :

Get-command -Module AzureRM.Resources -Name « *azurermresourcelock »

clip_image005

C’est donc assez simple. Vu que je viens de tenter de supprimer un groupe de ressources RGNetwork, on devrait trouver la trace de notre Lock avec Get-AzureRMResourceLock

clip_image006

Globalement, il est indiqué qu’il est interdit de supprimer le groupe de ressources. Le seul moyen de le supprimer, c’est de supprimer le verrouillage avant. Maintenant, voyons comment on a pu en arriver là en créant le lock avec la commande New-AzureRmResourceLock.

New-AzureRMResourceLock -ResourceGroupName « RGNetwork » -LockName « NetworkTeam » -LockNotes « Pense y deux fois avant de continuer, … » -Locklevel CanNotDelete -Force

clip_image007

Remarque : Aujourd’hui, on ne dispose que de deux types de Lock : Read-Only, CanNotDelete.

Après, on peut être plus fin et de verrouiller qu’une ressource particulière. D’un point de vue sécurité, la disparition de mon coffre-fort numérique contenant toutes mes clés et secrets serait plus que préjudiciable à notre ami Dédé.

 

Conclusion

Le Resource Locking est un bon moyen pour éviter les erreurs. Pour moi, une équipe qui ne verrouille aucune de ses ressources peut signifier plusieurs choses :

  • Elle n’a peur de rien, tout du moins jusqu’à ce que le pire survienne
  • Elle a évalué les risques et ce type de scénario ne surviendra jamais (jusqu’à ce que le facteur Dédé survienne)

Bref, pensez à Locker vos ressources, ça peut vous sauver la vie et le job de Dédé

­

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

Découverte d’Azure Rights Management Services

Right Management Services. Voilà un sujet que j’avais touché du doigt voilà longtemps. C’est au travers d’un besoin interne que je reviens à lui. Entre temps le Cloud est passé par là, on va donc travailler non pas avec une infrastructure Right Management Services hébergée On-Premises mais le service Cloud Azure RMS. Ça change pas mal de choses :

  • Plus d’infrastructure : Un point d’économie majeur et de la complexité en moins
  • Authentification Cloud : On va s’appuyer sur Azure Active Directory et non plus sur le couple Active Directory & ADFS, plus de trust de Federation à maintenir
  • Support des terminaux mobiles : On ne se limite pas à l’environnement Microsoft mais aussi IOS, Android, MacOS
  • Suivi d’accès, révocation d’accès aux documents

 

 

Il a bien changé le RMS. Là où cela se complique, c’est que RMS est disponible dans plusieurs packages et en plusieurs éditions :

  • RMS for Office 365 (à partir du plan E3)
  • Azure RMS Premium
  • Enterprise Mobility Suite (incluant Azure RMS)
  • RMS for invidual users

 

Là, ça s’est un peu compliqué. Heureusement, j’ai une licence Office 365 E3, donc moi j’ai une licence. A noter que la licence est nécessaire uniquement pour les producteurs de contenus protégés, pas pour ceux qui le consomment. Pour les consommateurs, c’est là que cela se complique avec trois cas :

  • Partenaires disposant d’une souscription de type Office 365 (tel que E3 ou supérieur)
  • Partenaires ne disposant pas d’une souscription de type Office 365
  • Particuliers

Le premier scénario est effectivement le plus simple. Mon partenaire dispose déjà d’une identité Windows Azure Active Directory. Par contre pour les deux autres, cela se complique. Il faut déjà prouver son identité, lié à une instance Windows Azure Active Directory. C’est pour cela que Microsoft propose l’offre RMS for individual users. Cela créé l’instance Windows Azure Active Directory nécessaire. Deux limites identifiées à ce jour pour cette offre :

  • Pas encore de support de GMAIL
  • Pas encore de support des comptes Hotmail/Live

 

Un point à se souvenir : Un utilisateur associé à une licence Office 365 Plan E3 ou supérieur ne peut utiliser la fonctionnalité Azure RMS que si l’administrateur de la souscription a autorisé l’utilisation du service.

 

Mon besoin

Mon besoin est de pouvoir partager du contenu avec des personnes externes à mon entreprise en étant assuré que :

  • Je puisse m’assurer que seuls les destinataires autorisés pourront le consulter
  • Que le contenu mis à disposition ne soit pas récupérable, modifiable, ni imprimable par quelque moyen

 

Dans mon scénario, mon partenaire dispose d’une souscription Office 365 ou est en mesure de souscrire à l’offre RMS for individual users, c’est le même mode de fonctionnement. On va dérouler par étapes, dans l’ordre :

  • Première étape : Activer le service dans notre souscription Office 365
  • Seconde étape : Obtenir une licence RMS
  • Troisième étape : Installer l’application de partage
  • Quatrième étape : Partager du contenu
  • Expérience du destinataire externe
  • Conclusion

 

Première étape Activer le service dans notre souscription Office 365

Notre souscription Office 365 est liée à un Tenant Windows Azure Active Directory. C’est à ce niveau qu’il faut activer la prise en charge de Rights Management Services dans le portail d’administration Office 365 :

clip_image001

 

Cela nous amène au portail de gestion du tenant Windows Azure Active Directory associé à notre souscription Office 365. La question est simple et la réponse est évidente.

clip_image002

 

Seconde étape : Obtenir une licence RMS

Individuellement, chaque utilisateur devant produire du contenu à protéger doit obtenir une licence Azure RMS depuis le site https://portal.aadrm.com. Le processus est assez simple. Il nous demande notre adresse de messagerie pour vérifier que nous sommes bien en mesure de souscrire au service et de nous authentifier.

clip_image003

 

Ne tentez pas d’utiliser une adresse de type GMAIL, Hotmail ou Live, cela ne fonctionne pas (encore).

clip_image004

 

Si le domaine est effectivement bien reconnu comme éligible, on doit encore prouver notre identité :

clip_image005

 

Si notre administrateur a bien autorisé l’utilisation d’Azure RMS au sein du Tenant Office 365, on aura notre licence.

clip_image006

 

Ainsi qu’un mail dans notre boîte aux lettres nous expliquant la suite des opérations.

clip_image007

 

Troisième étape : Installer l’application de partage

A ce stade, nous avons une licence nous permettant de consommer mais aussi de produire du contenu protégé. A ce jour, cette application est disponible sur les plateformes suivantes :

  • Windows 7 (x86, x64)
  • Windows 8 (x86, x64)
  • Windows 8.1 (x86, x64)
  • Windows 10 (x86, x64)
  • Mac OS X: Minimum version of Mac OS X 10.8 (Mountain Lion)
    Windows Phone: Windows Phone 8.1
  • Android phones and tablets: Minimum version of Android 4.0.3
  • iPhone and iPad: Minimum version of iOS 7.0
  • Windows tablets: Windows 10 Mobile and Windows 8.1 RT

 

C’est un service Cloud, donc censé être le plus agnostique possible. Pour le end-user, ça devrait aller. Pour la suite de ce billet, j’ai retenu le Windows classique sur socle Windows 7 X86 et Office 2016. Le Setup nous informe que cela va se dérouler en plusieurs étapes :

clip_image008

 

Avec le téléchargement de quelques binaires.

clip_image009

 

Globalement, ça va vite.

clip_image010

 

On est maintenant prêt à partager du contenu.

 

Quatrième étape : Partager du contenu

La première application à laquelle on pense lorsqu’on partage du contenu, c’est Outlook. Lorsque je compose un message, je note la présence d’une nouvelle icône. Le mécanisme est aussi disponible depuis l’explorateur Windows.

clip_image011

 

C’est d’une simplicité déconcertante. On va simplement affecter des permissions à nos destinataires. Ici ce sont des templates Built-in mais on peut aussi créer les nôtres.

clip_image012

 

Quelques points intéressants :

  • La possibilité de révoquer l’accès aux documents passé une date butoir
  • Savoir si nos destinataires tentent d’accéder au document (un soumissionnaire qui ne répond pas à un appel d’offre, …)
  • Révoquer les permissions pour les documents déjà partagés (un soumissionnaire ne respectant pas les règles des appels d’offre publics)

 

Y a plus qu’à envoyer.

 

Expérience du destinataire externe

Première chose, c’est la réception d’un mail tel qu’illustré ci-dessous

clip_image013

 

Un document partagé mais deux reçus. C’est normal, c’est pour pouvoir partager ce contenu avec des destinataires qui n’ont pas la suite bureautique Microsoft. Avant de pouvoir consommer, il nous faut une licence Azure RMS. On va donc suivre les instructions.

clip_image014

 

Le processus de configuration va être identique pour nos partenaires externes. S’ils disposent déjà d’Office 365 (Plan E3 minimum), ils devront avoir préalablement activé la prise en charge de Rights Management Services comme nous. Ils ne sont pas éligibles à la licence « RMS for individuals Users ».

clip_image015

 

Azure RMS a identifié un utilisateur dépendant d’une souscription Office 365, il va donc lui demander de s’authentifier pour vérifier s’il dispose bien d’une licence, voire de lui en assigner une si ce n’est pas déjà fait.

clip_image016

 

Si l’utilisation d’Azure RMS était bien autorisé au niveau de la souscription Office 365, y a plus qu’à consommer.

clip_image006[1]

 

La pièce jointe est un document Word. Y a qu’a double cliquer dessus. On va vite constater que notre Word est limité, quelques exemples :

  • Copier/Coller : Impossible
  • Sauvegarde du document : Grisé, impossible
  • Sauvegarde du document sous un autre nom : Grisé, impossible
  • Export (conversion dans Powerpoint) : Grisé, impossible
  • Impression : Grisé, impossible

 

OK, on tente le mode Geek avec la capture d’écran. Non, ce n’est pas une erreur :

clip_image017

 

Dans Word, on peut demander quelles sont mes autorisations, c’est visiblement le niveau le plus stricte

clip_image018

 

Si par hasard, je n’avais pas la suite bureautique (ou si l’application à utiliser ne supporte pas RMS), je peux quand même consulter le contenu. C’est la seconde pièce jointe du mail. Notre document a été encapsulé dans un autre qui lui supporte RMS. Pour cela, je dois installer l’application de partage correspondant à ma plateforme. Une fois installé, on peut consulter le contenu. Après, les mêmes restrictions s’appliquent :

clip_image019

 

De mon côté, je viens de recevoir un mail m’informant que mon destinataire a accédé à mon contenu protégé. On me propose de suivre l’accès à notre document mais pour l’utiliser, il faut une licence Premium !

clip_image020

 

Conclusion

Presque six ans entre ma première expérience de Rights Management Service et Azure RMS. Son successeur dans le cloud présente beaucoup d’avantages. Il reste quelques contraintes mais elles sont bien moindres que celles que nous avons connues avec son ancêtre.

 

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

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)