Microsoft Experiences 2016 : Azure Stack de l’Azure dans votre Datacenter

Ca approche doucement, on peaufine nos derniers slides, affine nos démos, bref les Microsoft Experiences 2016, c’est bientôt.

Session

 

En ce qui me concerne, nous animerons avec Bruno Saille une session autour d’un produit qui nous tiens à cœur, à savoir Microsoft Azure Stack. Pour information, la session est planifiée pour la journée technique (donc le mercredi 5 octobre 2016). La session est planifiée pour le créneau horaire 18h15-19h00 en salle 252B. Nous serons donc disponible immédiatement après pour répondre à vos questions autour d’un verre.

Si Microsoft Azure Stack vous intéresse, l’évènement Microsoft Ignite devrait vous intéresser puisqu’il y a pas moins de onze sessions consacrées au sujet.

 

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

Découverte d’Azure VNet Peering

La période la plus difficile pour un addict du cloud, c’est les vacances, loin de ses régions Azure, … La qualité du réseau Corse n’incitant pas à la pratique assidue d’azure, il y a des sujets qui passent à la trappe. Le Vnet Peering est l’un d’entre eux. Le service est apparu pendant le mois de Juillet 2016 pour être visible dans le portail depuis le mois d’Aout 2016 : Public preview: VNet Peering for Azure Virtual Network

Avant, lorsqu’on voulait reproduire l’isolation réseau entre un environnement de production et les autres, le seul moyen à notre disposition était de segmenter avec plusieurs VNet et de connecter ceux-ci avec une Gateway comme illustré ci-dessous :

clip_image001

 

Cette approche répond parfaitement à notre problématique d’isolation. Par contre, elle présente plusieurs inconvénients :

  • Le coût : La mise en place de deux Gateway fonctionnant 744 heures par mois. Ce n’est pas négligeable.
  • La performance : Passer par deux Gateway, implique un tunnel IPSEC. Un fort trafic réseau entre les deux VNET impliquera de bien dimensionner les dites gateways car c’est le VCPU qui va travailler.
  • La logique : Pourquoi faudrait-il ressortir sur Internet pour connecter deux réseaux alors qu’ils sont dans la même région, donc dans le même datacenter

 

C’est pour répondre à ce type de problématique que Microsoft a introduit la notion de Peering. D’un point de vue conception, c’est tout de suite plus simple

clip_image002

 

Le Peering se configure dans le portail Azure depuis le 1er Aout 2016 comme illustré ci-dessous :

clip_image003

 

J’ai attendu que la fonctionnalité soit nativement disponible dans le portail, c’est plus simple. Un Peering est un objet dans Azure, il a donc un nom. Premier point intéressant, la fonctionnalité de Peering s’applique aussi bien aux VNets dits classiques (ASM) que ARM.

clip_image004

 

Un Peering peut être mis en place entre :

  • Deux VNets au sein de la même souscription
  • Deux VNets au sein de souscriptions différentes

 

La seule limite actuelle est que les deux VNets dépendent de la même région Azure. Ça tombe bien, c’est le cas de mes deux VNETs. L’option Virtual Network Access est intéressante. Elle permet de considérer l’autre VNet comme une extension du notre, donc inclus dans le Tag Virtual Network. Autant dire que pour un scénario de segmentation Production-Préproduction, on va éviter. Les trois dernières options permettent de maîtriser le routage :

  • Allow forwarded Traffic : Permet de maîtriser le flux réseau en provenance du partenaire (mais ne dépendant pas de son Vnet)
  • Allow Gateway transit : Permet à notre partenaire d’utiliser notre passerelle pour le routage du flux réseau externe
  • Use Remote gateways : Utilisé par notre partenaire pour qu’il puisse utiliser notre passerelle pour le routage de ses flux réseaux externes

 

Logiquement, pour que cela fonctionne, il faut créer un autre objet VNet Peering pour l’autre VNet, ce que j’ai fait.

clip_image005

 

Si on a pas l’overlapping d’adressage, alors le VNet Peering devrait apparaître ainsi dans les deux Vnets, avec la mention « Connected ».

clip_image006

 

Pour vérifier que cela fonctionne, on va tenter de communiquer depuis une machine virtuelle dont la carte réseau est connectée au réseau de pré-production pour joindre une machine virtuelle dont l’interface est liée au réseau de production. Voilà la configuration d’une machine virtuelle de pré-production. Elle dispose d’une Gateway sur son réseau, que du classique.

clip_image007

 

Et côté production :

clip_image008

 

Pour valider le bon fonctionnement, on va pinger depuis la machine virtuelle de pré-production vers la production.

clip_image009

 

Effectivement, cela fonctionne. On voit que c’est du VNet Peering car le TTL ne décroit pas. C’est logique car on ne passe pas par un routeur, c’est ce que nous confirme le Tracert.

Alors Vnet ou Gateway?

Pour certains scénarios (segmentation d’environnements), le VNet Peering est intéressant. Maintenant, reste à voir comment le service sera facturé lors de son passage en GA. Du point de vue Azure, on consommera nécessairement des ressources. On n’a plus les adresses IP publiques associées à nos Gateway ni le coût de compute de celles-ci mais il y aura forcément un coût. Sur le papier, le VNet Peering à tout pour plaire et supporte déjà beaucoup de fonctionnalités que nous utilisons souvent :

  • Network Security group
  • Network Virtual Appliances
  • User-Defined Routes
  • Internal Load-Balancers

 

Personnellement, je suis fan.

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

Découverte Azure AD B2C

Ça faisait quelques temps que qu’Azure B2C trainait en Preview, le service est maintenant officiellement disponible, donc officiellement utilisable en production, avec un cadeau, la facturation ne commencera qu’en 2017 :). Le pricing est basé sur deux critères :

  • Le nombre d’utilisateurs
  • Le nombre d’authentification

C’est une facturation par palier. Dès lors qu’on est en dessous des 50000 utilisateurs et 50000 authentifications, autant dire que le service est gratuit. Attention quand je dis gratuit car les services dépendants tel qu’Azure Multi-Factor Authentication eux ne le seront pas. L’aspect le plus ennuyeux étant clos, passons maintenant aux réjouissances. Pour rappel, Microsoft avait mis en Preview deux services :

  • Azure B2C (l’objet de ce billet)
  • Azure B2B (qui lui est encore en Preview)

 

Présentation du service

Pour faire simple Azure B2C va nous proposer un système de gestion des utilisateurs externes / consommateurs, pour une application Web (mais pas que) avec toute les fonctionnalités que cela implique (inscription, gestion de profil, réinitialisation de mot de passe, …), bref tout un ensemble de services qui vont faciliter la vie de nos développeurs. A l’opposé Azure B2B est destiné aux mêmes applications mais pour le contexte Business to Business. Voilà pour le positionnement d’Azure B2C. Intégrer l’authentification à une Web App, ce n’est pas nouveau (Expanding App Service Authentication/Authorization), on sait déjà le faire. Par contre, cela nous impose de développer tout ce qui va autour :

  • Le formulaire d’inscription
  • Le formulaire d’authentification
  • Le formulaire pour permettre aux utilisateurs de mettre à jour leur profil
  • Le formulaire pour réinitialiser le mot de passe
  • L’intégration avec nos applications

Bref, être responsable de tout cela et surtout coupable (le leaking de mots de passe est à la mode en ce moment et il n’épargne personne), c’est pas forcément ce qu’on recherche. Au final, ce serait bien si on avait un service capable de prendre en compte tous ces points en proposant en plus de prendre en charge des fournisseurs d’authentifications tiers (Facebook, Linkedin, Google+ Live ID, …), des trucs modernes donc. Tout ce que je viens d’énumérer sont des fonctionnalités D’Azure AD B2C.

Prérequis

Pour les besoins de la démonstration, j’ai retenu la Web Application. J’ai mis en place une Web App et le App Service qui lui est associé, le tout dans un groupe de ressources comme illustré ci-dessous :

clip_image001

Note : La feature Application Insight s’est glissé dans la configuration. Le problème, c’est qu’actuellement en Preview, elle n’est pas encore disponible dans la région West Europe.

Ma Web Application est tout ce qu’il y a de plus classique. La commande PowerShell : Get-AzureWebsite -Name b2Cwebapplication | select name, sku,state, enabled, EnabledHostNames, HostNameSslStates va nous fournir l’information essentielle :

clip_image002

L’information essentielle, c’est l’url de cette WebApp : https://b2cwebapplication.azurewebsites.net/. C’est à cette URL que le service Azure AD BC2 va rediriger les requêtes après inscription, authentification ou mise à jour de profil.

Mise en place

Pour l’instant, la création et la gestion des instances du service Windows Azure Active Directory dépendent encore de l’ancien portail. C’est donc dans celui-ci que nous allons créer une nouvelle instance du service Azure AD. Ce qui a changé par rapport à la Preview, c’est qu’on est plus obligé de créer un nouveau tenant Windows Azure Active Directory. On peut aussi conserver son tenant existant. Tout de suite, on y voit un intérêt immédiat de réutiliser des comptes existants.

clip_image003

Pour cette démonstration, j’ai retenu la création d’une nouvelle instance Azure Active Directory dont je suis moi-même devenu administrateur. J’ai aussi créé un premier utilisateur tout ce qu’il y a de plus classique.

clip_image004

Dans l’onglet Configure, on va découvrir un lien nommé « Manage B2C Settings ».

clip_image005

Maintenant on découvre que cela ne se passe plus dans l’ancien portail mais bien dans le nouveau portail, ce qui est une excellente nouvelle. Déclarer une application dans Azure AD, c’est quelque chose que nous avons déjà vu dans le billet Découverte d’Azure Disk Encryption (Preview). Par contre, c’est maintenant dans le nouveau portail que cela se passe. Mon application étant de type Web, il est logique que la case soit cochée. J’ai aussi référencer l’URL de mon application.

clip_image006

De cette interface, nous conservons deux choses :

  • L’Application ID
  • La clé de l’application

Ces informations seront essentielles pour configurer notre application. Azure B2C est un service d’authentification configurable à plusieurs niveaux :

  • La politique d’enregistrement (Sign-up policy)
  • La politique d’authentification (Sign-In policy)
  • La politique de gestion du profil (Profile Policy)
  • La politique de réinitialisation de mot de passe (Password Reset Policy)
Sign-up policy

C’est la politique d’enregistrement. On y référence les éléments suivants. Le ou les fournisseurs d’authentification que nous allons proposer à l’enregistrement (uniquement le mail pour commencer). Les deux autres sont visibles car au moment de la rédaction de ce billet, j’avais commencé la configuration d’autres fournisseurs.

clip_image007

Notre choix, c’est un enregistrement par mail pour commencer. Prochaine étape, la sélection des attributs que nous allons exiger de l’utilisateur pendant son enregistrement. On notera que ce sont des attributs Built-In. Cela signifie que l’on peut aussi demander d’autres informations.

clip_image008

Au terme de l’enregistrement, un jeton d’accès sera généré à destination de l’application. Il contiendra les informations suivantes :

clip_image009

La subtilité, c’est l’attribut « User Is new » qui permettra de traiter différemment la création d’un profil de la mise à jour d’un profil pour notre application. On pourrait exiger l’utilisation de Multi-Factor Authentication ou personnaliser la page d’enregistrement mais pas besoin de compliquer les choses pour une découverte.

Sign-In Policy

La politique d’authentification va reprendre les mêmes éléments que pour la politique d’enregistrement. On peut choisir :

  • Le ou les fournisseurs d’authentification à prendre en compte pour le formulaire d’authentification
  • Les attributs à intégrer au Claims qui sera généré et mis à disposition de notre application
  • La durée de vie de notre token et la configuration du SSO entre plusieurs applications
  • Le fait d’exiger l’authentification Multi-Factor pour notre application
  • La personnalisation de l’interface graphique mise à disposition des utilisateurs

 

Profile Policy

C’est le même principe que pour les politiques précédentes mais pour gérer l’interface de configuration du profil qui sera mise à disposition des utilisateurs. Au terme de la mise à jour, un jeton d’accès sera mis à disposition de l’application.

Password Reset Policy

L’interface de réinitialisation de mot de passe est valable uniquement pour le fournisseur d’identité Local Account. Pour les autres, c’est sous la responsabilité des fournisseurs respectifs (LinkedIn, Facebook, Google, …).

clip_image010

Attention, la politique de mot de passe applicable ainsi que la capacité de réinitialiser eux même leur mot de passe est lié au tenant Windows Azure AD B2C.

clip_image011

Après, encore faut-il que les utilisateurs aient renseigné une adresse de messagerie alternative :

clip_image012

 

C’est fini pour la partie mise en place. On va s’attaquer maintenant à Visual Studio.

Intégration Web Application

C’est maintenant que commence la phase développement. Là j’ai eu un peu d’aide ici : Azure AD B2C: Sign-Up & Sign-In in a ASP.NET Web App. Au début, j’ai commencé avec cet exemple disponible sur GitHub . Problème, n’étant plus dans la branche développement depuis bien longtemps (environ 15 ans), ça a été compliqué, je suis un peu rouillé en C#. J’ai donc pris un raccourci avec un package complètement opérationnel, lui aussi disponible sur GitHub. La toute la configuration tiens en quelques ligne du fichier « Web.Config » de notre Web Application. La cela me parle beaucoup plus. Nous devons référencer les points suivants :

  • Tenant : le nom de la souscription Windows Azure active Directory
  • ClientID : l’identifiant unique de notre application
  • RedirectUri : L’URL de redirection de notre application.
  • SignUpPolicyId : Le nom de la politique de Sign-up à utiliser avec notre application
  • SignInPolicyId : Le nom de la politique de Sign-in à utiliser avec notre application
  • UserProfilePolicyId : Le nom de la politique de profil à utiliser avec notre application

 

clip_image013

Y a plus qu’à sauver et builder. C’est maintenant qu’on va savoir si cela fonctionne. Mon instance App Service est déjà opérationnelle dans Azure, prête à accueillir mon package Web Deploy.

clip_image014

Mon instance se nomme b2Cwebapplication, c’est celle que j’avais créé en prérequis.

clip_image015

Visual Studio s’occupe de tout. Avec mes credentials il organise la publication de mon package Web Deploy.

clip_image016

On va direct en prod, pas de staging slot.

clip_image017

 

Expérience de l’enregistrement d’un nouvel utilisateur

Une fois l’application publiée, on peut aller faire un tour à l’URL https://b2cwebapplication.azurewebsites.net/. La première chose qui saute aux yeux, c’est que d’un point de vue design, ça ne casse pas trois pattes à un canard. En même temps, ce n’est pas le but et vous n’êtes pas arrivé jusqu’à ce paragraphe pour cela. Ce qui nous intéresse, c’est la barre en haut.

clip_image018

Si on clique sur « Sign up », alors la politique d’inscription que nous avons configurée devrait apparaître. Il nous faut prouver notre identité. Après avoir renseigné notre adresse email, on clique sur le bouton « Send verification code ». Le code nous est communiqué par mail. Nous n’avons qu’à le renseigner et cliquer sur le bouton « Verify ».

clip_image019

Tant que j’ai pas cliqué sur le bouton « Verify », pas possible d’aller plus loin. Ce n’est qu’une fois mon identité vérifiée qu’on va pouvoir finaliser la création du nouvel utilisateur dans le tenant Windows Azure Active Directory :

SignupPolicyExperience1

Dans l’application, il est maintenant bien référencé que je suis authentifié et reconnu :

clip_image021

 

Si on regarde sous la moquette (dans le tenant Azure AD B2C), on constate bien un nouvel utilisateur.

Get-MsolUser | Where {$_.DisplayName -eq « Simple by design but Business compliant »} | Format-List -Property Displayname, Userprincipalname, PostalCode, UserType, WhenCreated

clip_image022

On peut tester le formulaire d’authentification (Sign-in policy). Avec un seul fournisseur (Azure Active Directory), l’interface est des plus austères.

clip_image023

L’utilisateur peut mettre à jour les attributs dans son profil. Dans ma politique, j’avais indiqué que l’utilisateur pouvait modifier :

  • Son Code postal
  • Son Display Name
  • Son Pays

clip_image024

Si on va regarder ce qu’on a en PowerShell avec le module Azure AD.

$Cred = Get-Credential

Connect-msolservice -credential $cred

get-msoluser | where {$_.UserPrincipalname -eq « b2ccustomer@b2csimplebydesign.onmicrosoft.com »} | format-

list -Property Userprincipalname, Displayname, PostalCode, country

clip_image025

Ça correspond à ce que l’utilisateur a renseigné dans son profil. Pour finir, le lien Claims permet de consulter le Claims constitué et mis à disposition de notre application.

clip_image026

 

C’est une découverte rapide. Il y a encore beaucoup à dire sur le sujet Azure B2C. Quand je vais avoir un peu de temps, on s’attardera sur des sujets tel que :

  • L’utilisation d’autres fournisseurs d’authentification (Google, Facebook, LinkedIn)
  • L’utilisation d’attributs personnalisés dans le profil des utilisateurs

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

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)