Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]

Simple, yes, Secure Maybe, by design for sure, Business compliant always

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

Windows Azure Pack - Les updates de System Center

Même si Windows Azure Pack est un produit disruptif, il s'appuie quand même sur un certain nombre de composants de la gamme System Center pour la partie IAAS:

  • System Center Service Provider Foundation
  • System Center Virtual Machine Manager 2012 R2
  • System Center Operation Manager 2012 R2

 

Microsoft a mis à disposition le Rollup 4 pour System Center 2012 R2. Cela comprend donc les Rollup suivants :

  • System Center Data Protection Manager 2012 R2 (KB3009516)
  • System Center Operation Manager 2012 R2 (KB2992020)
  • System Center Service Manager 2012 R2 (KB2989601)
  • System Center Service Provider Foundation (KB2992021)
  • System Center Service Reporting (KB2992025)
  • System Center Virtual Machine Manager 2012 R2 (KB2992024)

 

Bref, que des produits qui ont ou peuvent entrer en relation avec Windows Azure Pack. Mais il y en a aussi spécifiquement pour Windows Azure Pack :

  • Rollup 4 for System Center 2012 R2 and Azure Pack (KB2992027)
  • Update Rollup 4 for Windows Azure Pack Web Sites Version 2 (KB2992029)

Le Rollup 4 de Windows Azure Pack intègre une correction pour un problème qui a eu le don de l'irriter. Il corrige un problème avec la KB 2990942, une mise à jour du mois d’Octobre 2014.

    clip_image001

Bref, il tombe à pic ce Rollup 4 pour Windows Azure Pack. Au passage bien lire la note.

 

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

Rollup 1 for Forefront Unified Access Gateway 2010 Service Pack 4

It’s UAG Patching day today. Microsoft just released update 1 for Service Pack 4 of Forefront UAG 2010 (KB2922171). many fixes but also some improvements for Exchange 2013 and SharePoint 2013. Here is the list of included fixes :

  • KB2997481 : FIX: You are not authorized to access applications published through Forefront Unified Access Gateway
  • KB2997483 : FIX: Source IP and user name missing from Event ID 14 in the Web Monitor log file
  • KB2997485 : FIX: "An unknown error occurred while processing the certificate" error when you access an application that is hosted on an Apache web server
  • KB2997486 : FIX: The Forefront Unified Access Gateway portal may be unavailable
  • KB2997487 : FIX: "You have attempted to access a restricted URL" error when you try to access OWA and are close to the idle session time-out period
  • KB2998352 : FIX: "Your client does not support opening this list with Windows Explorer" error when you try to open a SharePoint document library
  • KB2998733 : FIX: You cannot start a RemoteApp application when its name contains accented characters
  • KB2998739 : FIX: The VPN connection disconnects immediately when a Unified Access Gateway 2010 client uses SSTP
  • KB2998752 : FIX: "Authentication failed" error when you try to log on to Unified Access Gateway by using the UPN format
  • KB2998769 : FIX: Exception occurs when you use the Export2Tspub application to export the configuration to a .tspub file
  • KB3003977 : FIX: "Sign-in Error" errors for Internet Explorer 11 clients when they access a Unified Access Gateway portal trunk that has ADFS 2.0 authentication
  • KB3004023 : FIX: Client connections for Form-based SSO fail authentication in Forefront Unified Access Gateway 2010 SP4
  • KB3006827 : FIX: Forefront Unified Access Gateway 2010 template improvements for SharePoint Server 2013
  • KB3006828 : FIX: Forefront Unified Access Gateway 2010 template improvements for Exchange Server 2013
  • KB3006892 : FIX: Windows Firewall is detected as running after a third-party firewall is installed on a computer that is running Forefront Unified Access Gateway 2010
  • KB3006938 : FIX: Soft lockout does not apply if Outlook Anywhere uses KCD for SSO to Exchange Server
  • KB3006940 : FIX: Portal toolbar is not displayed in Forefront Unified Access Gateway 2010
  • KB3007519 : FIX: "Bind the source IP address to the session" option does not work correctly in Forefront Unified Access Gateway 2010
  • KB2997456 : FIX: French client access to Unified Access Gateway trunk by using two-factor authentication fails when user password nears expiration
  • KB2997493 : FIX: "Invalid URL path" error when an external user tries to connect to a shared calendar
  • KB3007842 : FIX: "The website cannot display the page" or "HTTP 500" error if the first user logon is unsuccessful
  • KB3009885 : FIX: Applications that use the Socket Forwarder component may stop responding in Forefront Unified Access Gateway 2010
  • KB3009904 : FIX: "You cannot access this site due to an internal error" error when you log on to Outlook Web App again

 

At last, if not already done, don’t forget to fix the SSLV3 flaw. My valuable MVP colleague Richard HICKS published an excellent article on this subject.

 

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (3/7)

Depuis le début, je parle de token JSON. Le problème, c'est que jusqu'à maintenant, on en a pas encore vu la trace. Et pour cause, c'est pas activé par défaut et c'est pas configurable via l'interface graphique. Voyons un peu les commandes Powershell disponible pour le module ADFS.

clip_image001

Explorons la liste de nos partenaires de confiance.

clip_image002

Vu que nous sommes sur un serveur Windows Server 2012 R2, il est logique de trouver le Device Registration Service, module bien connu pour ceux qui ont joué avec Workplace Join. On retrouve aussi le partenaire que nous venons de configurer. Allons explorer sa configuration en détail.

clip_image003

On découvre deux choses. Premièrement, lors de l'importation du fichier de Metadata, il a bien importé le STS du module 'Portal Admin Site' identifiable par "http://azureservices/AdminSite". Deuxièmement, les tokens JSON ne sont pas activé. Or nous en avons besoins, c'est le formalisme utilisé par Windows Azure Pack et son grand frère Microsoft Azure. Ces tokens présentent l'avantage d'être assez simple pour tenir dans un entête HTTP. D'un point de vue structure, ils sont plus léger que le SAML traditionnel. On as assez d'information pour changer cela. Si on a un "Get", alors on doit avoir un "Set", faut juste être capable de bien désigner notre objet à actualiser.

clip_image004

Nous en avons fini avec la partie ADFS. c'était pas si difficile. Et si on s'attaquait au gros du morceau? Reconfigurer le portail "Admin portal site" pour utiliser notre ADFS tout prêt à générer des tokens JSON.

 

Jusqu’a maintenant, j’étais gentil.

 

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (2/7)

Dans le premier cercle de l'enfer, nous avons mis en œuvre une infrastructure ADFS pour notre plateforme Windows Azure Pack. A ce stade, Windows Azure Pack ne sait pas encore qu'il peut lui déléguer l'authentification. Pour cela, il faut établir une cadre de confiance entre les deux partenaires. Dans le second cercle de l'enfer, nous allons nous attarder sur la mise en place de ce cadre de confiance du point de vue d'ADFS. Lorsque ADFS aura authentifié notre utilisateur, il devra générer un token avec des claims correctement formatées, de manière à ce que Windows Azure Pack puisse les comprendre. Du point de vue ADFS, Windows Azure Pack sera un Security Token Service (STS). Par défaut, il y a déjà un partenariat de confiance établit entre le module "Admin portal" et le module "Admin Authentication Site". Nous allons juste le remplacer.

Du point de vue ADFS, le module "Admin portal" sera considéré comme un partenaire de confiance, donc référencé comme un "Relying Party trust".

clip_image001

Le truc, c'est de savoir à qui s'adresser coté Windows Azure Pack. Si le portail d'administration de Windows Azure Pack doit faire confiance à ADFS, il est logique qu'ADFS renvoie le claims à l'envoyeur. On a donc l'URL de base : https://wapadmin.windowsazurepack.lan à laquelle on va ajouter "FederationMetadata/2007-06/FederationMetadata.xml". Ne cherchez pas ce répertoire virtuel dans IIS, toute trace de dépendance avec IIS a été retirée. On commence donc par désigner l'emplacement du fichier XML de notre partenaire de confiance : le portail d'administration Windows Azure Pack.

clip_image002

Si votre module "Admin portal site" est bien joignable, alors notre ADFS va être capable de récupérer les informations nécessaires. Ne restent qu'à traiter que quelques points de configuration. Nous allons commencer par nommer ce partenariat.

clip_image003

Nous sommes sur une plateforme Windows Server 2012 R2, donc ADFS 3.0, prenant en charge la fonctionnalité "Multi-Factor Authentication", c'est sexy. Pour l'instant on va s'en passer. On reviendra sur ce point lors d'un prochain billet. Mais ça n'empêche pas qu'on va préparer le terrain.

clip_image004

Notre infrastructure ADFS peut être en mesure d'authentifier un utilisateur mais doit-elle délivrer un jeton d'accès? La réponse est bien entendu oui. Par contre, comme indiqué, cela ne veut pas dire que l'utilisateur sera autorisé à accéder au portail d'administration de Windows Azure Pack. Tout dépendra des claims présentées et des autorisations accordées dans Windows Azure Pack.

clip_image005

Avant de finaliser, voyons un peu les informations que l'assistant a été capable de récupérer de notre partenaire de confiance. ADFS va se charger de maintenir la confiance avec le STS (module Admin portal site). Pour cela il va périodiquement récupérer la configuration dans le fichier de metadata.xml. C'est aussi lors de cette opération qu'il va découvrir le nouveau certificat à reconnaitre pour la signature des tokens.

clip_image006

Le module "Admin portal site" n'a qu'une seule exigence, c'est que le claims généré par ADFS intègre un UPN. Il peut contenir plus mais le minimum, c'est l'UPN de l'utilisateur. Dans notre cas, nous allons inclure plus d'informations dans notre claims. On verra cela un peu plus tard.

clip_image007

On en a fini avec la configuration du nouveau partenaire de confiance d'ADFS, reste à se mettre d'accord sur le détail des données échangées dans les claims générés par ADFS. Comme on vient de le voir, le module "Admin portal site" attend un claims contenant l'UPN de son utilisateur. C'est son exigence. Charge à ADFS de construire le jeton avec les bonnes informations. Pour cela, il faut des règles très strictes. Pour construire ces claims on peut :

  • Utiliser le contenu d'un attribut du fournisseur d'identité (ADDS/ADLDS) et l'utiliser tel que
  • Transformer le contenu d'un attribut du fournisseur d'identité (ADDS/ADLDS) pour l'enrichir
  • Peupler le claims avec un flag si l'utilisateur est membre d'un groupe particulier
  • Utiliser une source extérieur pour enrichir le claims

Le troisième cas est intéressant car il permet de renforcer l'authentification des utilisateurs. On peut par exemple rechercher si l'utilisateur est membre du groupe spécial "NT AUTHORITY\Certificate from this organization" prouvant une authentification avec double facteur de type Smartcard / Virtual smartcard. C'est intéressant à conserver pour authentifier les exploitants de notre plateforme Windows Azure Pack.

Dans notre contexte, on fera au plus simple. Nos exploitants sont des utilisateurs déclarés de l'annuaire Active Directory utilisée par l'infrastructure windowsazurepack.lan. On pourra donc se contenter de règles se contentant d'exploiter le contenu brut des attributs contenus dans l'annuaire Active Directory.

clip_image008

A ce stade, il y a aucune règle, donc le claims sera vide. Il faut donc un peu de travail.

clip_image009

La première règle du Claims Club, c'est de donner ton UPN. C'est une information qu'ADFS va extraire de l'annuaire Active Directory.

clip_image010

Et plus précisément de l'attribut "User-Principal-Name" de l'annuaire Active Directory que l'on va présenter tel que dans le claims. C'est le minimum requis pour Windows Azure Pack.

clip_image011

Du point de vue de Windows Azure Pack, on pourrait se contenter de cette unique règle. Cependant, cela impliquera que l'autorisation de nos utilisateurs se fera uniquement sur son UPN. Chaque utilisateur devrait être autorisé individuellement. On va donc introduire une seconde règle pour que le claims contienne la liste des groupes dont l'utilisateur est membre. C'est presque la même règle que la précédente, sauf que cette fois ce n'est pas l'UPN que nous allons passer mais le "Token-groups - Qualidied by Domain Name" que nous allons positionner dans le claims "Group". C'est la seconde règle du Claims club.

clip_image012

On en a fini avec les règles du Claims Club.

clip_image013

Si on creuse un peu, on peut exprimer beaucoup de choses dans ces claims :

  • Le device utilisé est-il enregistré (Workplace Join)?
  • La version du système d'exploitation?
  • L'utilisateur est-il connecté depuis un réseau interne?

A gauche la liste des attributs dont je dispose dans mon fournisseur d'identité (mon annuaire Active Directory) et à droite la liste des attributs que l'on peut peupler dans le token qui sera généré. On a de quoi faire pour exprimer nos règles.

LISTE0 LISTE1

 

Ce côté du partenariat c’est presque prêt. C'est la fin du second cercle de l'enfer. La prochaine étape, ce sera de descendre dans les entrailles d'ADFS, en PowerShell s’il vous plait.

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

Windows Azure Pack–Authentificaction ADFS Admin-Side : Les cercles de l’enfer (1/7)

Parler d'authentification basée sur ADFS c'est bien, le mettre en œuvre, c'est mieux. Rentrons dans le vif du sujet. Bienvenu dans le premier des sept cercles de l'enfer Windows Azure Pack / ADFS. Pourquoi sept et pas neuf? Juste pour ne pas faire fuir le lecteur.

J’ai bien des idées pour arriver à neuf mais ce serait pas raisonnable. Avec l’intégration de Multi-Factor Authentication et Microsoft Azure Access Control, on pourrait y arriver mais j’hésite. Cette série de billets sera déjà assez disruptive pour ne pas en plus mêler le grand frère Microsoft Azure à l’histoire.Diable Mais ce seront des sujets qu’on ne pourra pas négliger pour nos locataires.

 

Un peu d’architecture

L'annuaire Active Directory de l'infrastructure utilisé par ma plateforme Windows Azure Pack est situé dans une zone réseau isolée. C'est un service partagé par un certain nombre de composants de ma plateforme et qui n'a pas besoin d'être accessible par mes locataires. La bonne pratique est de placer le rôle ADFS sur un serveur dédié de tel manière qu'il soit aisé d'ajouter d'autres serveurs à la ferme (impliquera donc une base SQL dédiée, un certificat Web SSL avec clé privée exportable, …). Voila pour l’architecture.

 

Vous reprendrez bien des certificats?

Encore, ben oui. Qui dit ADFS dit web service exposé à sécuriser donc certificat SSL à prévoir. Première question : l'autorité émettrice, est-elle publique ou peut-elle être privée? Vu que nos utilisateurs seront les administrateurs de notre plateforme Windows Azure Pack. On pourrait se contenter d'un certificat émis par une autorité de certification privée. Cependant que se passera t'il lorsque nous voudrons offrir un service d'authentification par fédération à nos locataires? Pour cette raison, je recommande une autorité de certification publique, nativement reconnue de tous.

Dans mon contexte, j'ai fait au plus simple : un certificat serveur SSL (gabarit "Web Server" délivré par mon autorité de certification interne). J'ai juste personnalité le gabarit du certificat pour autoriser l'export du certificat avec sa clé privée. C'est essentiel si on veut pouvoir installer le serveur sur d'autre futurs serveurs de la ferme ADFS.

 

Mise en place ADFS

L'installation du rôle ADFS n'est qu'une succession de click-next, rien de bien passionnant. La seule chose importante est qu'ADFS doit impérativement être mis en œuvre sur une plateforme Windows Server 2012 ou supérieure. C'est nécessaire pour le support de JWT (JSON Web Token). Ca y est, ca pique déjà.

clip_image001

Une fois le processus d'installation terminé, reste plus que la configuration de la ferme de fédération ADFS. Avant de commencer, assurez-vous que le certificat d'authentification serveur SSL nécessaire est bien présent dans le magasin personnel de votre serveur.

clip_image002

Vu que c'est le premier serveur de la ferme, il faut configurer celle-ci dans son intégralité.

clip_image003

Tout est dit dans l'illustration ci-dessous, elle se passe de commentaire.

clip_image004

Mon certificat est bien présent dans le magasin personnel de mon serveur ADFS01.Windowsazurepack.lan. Ma fédération va avoir un nom FQDN. Normalement, c'est le nom inscrit dans le certificat (ADFS.windowsazurepack.lan). Si ce certificat est un wildcard, il faut alors compléter l'information. Le "Display Name", c'est ce que nous allons présenter à nos locataires lors de leur connexion au portail d'administration de Windows Azure Pack.

clip_image005

Un détail, si nous utilisons un certificat délivré par notre autorité de certification, le gabarit "Web Server" par défaut n'autorise pas l'export de la clé privée. Cela implique donc qu'on ne pourra pas (avec ce certificat) ajouter un nouveau serveur à la ferme. N'oubliez pas ce point lorsque vous remplissez votre demande de certificat auprès de votre fournisseur habituel.

Mon infrastructure ADFS va opérer dans le contexte d'un compte de service. On va exploiter la fonctionnalité Managed Service Account pour se simplifier la vie, pas de mot de passe à maintenir pour ce compte de service.

clip_image006

La configuration d'ADFS est stockée dans une base SQL. J'aurai pu choisir d'utiliser une instance de Windows Internal Database mais cela veut dire aussi que si je perds ce serveur, je perds aussi mon ADFS. J'ai donc choisi d'héberger la base sur un serveur SQL déjà existant. Les puristes me reprocheront de ne pas avoir mis en œuvre une instance SQL dédiée sur un SQL 2012 en High Availability mais, je manque de place sur ma maquette. Y a déjà près de 168go hébergés et j'ai encore besoin de place.

clip_image007

On en a fini avec la configuration initiale d'ADFS. Les puristes du PowerShell peuvent se divertir pendant l'installation en parcourant les commandes Powershell qui vont être exécutées. Dans mon cas, ce sera la commande Install-AdfsFarm.

clip_image008

Aucun problème au niveau des prérequis (ma Root Key pour GMSA est bien répliquée vers tous les contrôleurs de domaine depuis plus de 10 heures). Go!

clip_image009

C'est fini pour l'installation d'ADFS.

clip_image010

Vu que j'ai beaucoup galéré avec ADFS (4 ans sans pratiquer, il a bien changé le machin), j'avais besoin d'avoir des logs un peu plus verbeux que par défaut. Un rapide petit tout dans le module PowerShell et on a une première idée de ce qui sera journalisé out of the box.

clip_image011

Pas de trace des éventuels succès ou échecs d’authentification. On va donc y remédier, toujours en PowerShell.

clip_image012

Pour les amateurs de l'interface graphique, voilà de quoi on parle.

clip_image013

Voilà pour la mise en œuvre d'ADFS sur ma plateforme Windows Azure Pack. Prêt pour le prochain cercle de l'enfer? La prochaine fois, on va parler de partenaire de confiance. En attendant, quelques lectures qui m'ont bien aidé :

 

On notera que j’ai été sympa, j’aurai pu scripter toute la configuration en PowerShell. Ne vous réjouissiez pas trop vite, dès qu’on va revenir dans Windows Azure Pack, on replongera dans Powershell. On n’aura pas le choix.

 

Mais pourquoi est-il si méchant?

 

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

Windows Azure Pack - Les fondations de l'authentification Admin-side

Vous avez aimé "Windows Azure Pack–Les APIs publiques des locataires"? Parfait. Ce n'était que la surface des choses. Maintenant on va rentrer dans le dur. Les premiers services que notre plateforme Windows Azure Pack doit fournir ce sont l'authentification (qui accède à la plateforme) et l'autorisation (quel privilèges/rôles). Le premier périmètre qui nous intéresse c'est les exploitants. Pour cette population, faut faire mieux que la configuration par défaut. On verra plus tard que pour les locataires, ca partira sur les mêmes bases.

 

Quelques rappels pour commencer

Notre maquette évolue. Ci-dessous les composants installés et les URL et ports tel que configurés à ce stade suite au billet Windows Azure Pack–Les APIs publiques des locataires :

Module

URL

Port

Admin portal https://wapadmin.windowsazurepack.lan 443
Admin API https://wapadmin.windowsazurepack.lan 30004
Admin Authentication site https://wapadmin.windowsazurepack.lan 444
Tenant portal https://wapcloud.Windowsazurepack.lan 443
Tenant public API https://wapcloud.Windowsazurepack.lan 30006
Tenant Authentication Site https://wapcloud.Windowsazurepack.lan 444

 

Donc, pour nos exploitants, ce qui va nous intéresser c'est :

  • L'Admin portal
  • L'Admin Authentication Site

A partir de maintenant, on passe en mode disruptif. Scoop, on ne va pas parler d’authentification Windows IIS intégrée comme nous l'avons toujours connue avec les produits Microsoft, tout du moins pas comme on en avait l’habitude. Pour illustrer mon propos, voilà ci-dessous une vue simplifiée du processus d'authentification pour les exploitants d'une plateforme Windows Azure Pack.

clip_image001

Lorsqu'un utilisateur se connecte au portail, ce dernier ne trouve pas de token (On me parle d'ADFS? Pas encore, ça viendra bien assez tôt). Le portail redirige donc vers le Security Token Server (STS) dédié à l'authentification des exploitants (Admin Authentication Site). C'est ce module qui est chargé de délivrer un JSON Web Token. Une fois l'authentification réalisée, l'utilisateur est redirigé vers le portail pour lui présenter son jeton d'accès. Le portail va alors solliciter le module "Admin API" et lui soumettre le jeton qui sera resoumis au Security Token Server (STS) pour déterminer les autorisations effectives de l'utilisateur. Dans ce processus standard, le STS va exploiter l'annuaire Active Directory pour obtenir les services d'authentification et d'autorisation. Normalement, ce stade, j'ai perdu personne. C'est assez disruptif comme démarche non? Pas assez? OK, alors on va mettre les doigts dans la prise électrique et voir ce que cela donne, …

 

Mettre les doigts dans la prise

D'un point de vue sécurité, le processus par défaut est pas mal, mais peut mieux faire :

  • Où est l'authentification forte?
  • Peut-on minimiser l'exposition de l'annuaire Active Directory?
  • Est-on obligé d'avoir un annuaire Active Directory?

Pour améliorer la chose, on va introduire ADFS dans l'histoire. C'est là que ça va se compliquer dans la cinématique d'authentification.

clip_image002

Jusqu'à maintenant, du point de vue de Windows Azure Pack, le partenaire de confiance pour l'authentification des administrateurs était directement Active Directory via le module "Admin Authentication Site". Cela implique que nos utilisateurs avaient nécessairement un compte utilisateur dans un annuaire Active Directory.

Ce que nous allons faire, c'est court-circuiter ce module pour que le module "Admin portal" sollicite directement le partenaire de confiance que sera ADFS (Security Token Provider). C'est ce dernier qui va se charger de construire le token JSON et non plus le module "Admin Authentication Site". C’est aussi simple que cela.

ADFS va devenir un partenaire de confiance de Windows Azure Pack au point de lui déléguer ses fonctions d'authentification et d'autorisation. C'est lui qui va nous fournir les capacités suivantes :

  • Prise en charge de l'authentification forte (Multi-Factor Authentication)
  • Prise en charge de plusieurs annuaires Active Directory (sans besoin de relation d'approbation)
  • Authentification auprès d'autres source qu'Active Directory (ADLDS, base SQL, …)

 

Pour patienter avec le prochaine, billet, une petite lecture piquante qui m’a beaucoup inspirée pour démarrer cette série de billets :

Claims-Based Identity in Windows Azure Pack

 

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

L’initiative Cloud Platform System

Windows Azure Pack c’est bien, même très bien surtout pour une première version. Pourtant, il a de quoi faire peur lorsqu’on l’observe pour la première fois (J’ai encore pas mal de billets en stocks sur le sujet).

Windows Azure Pack, c’est un peu comme le Tardis, c’est plus grand à l’intérieur qu’il n’y parait, et c’est vrai! En plus, en terme d’approche, le produit est pas mal disruptif, il ne ressemble pas aux autres produits Microsoft que nous connaissions jusqu’à maintenant. Il faut dire qu’il a de qui tenir puisque son objectif n’est ni plus ni moins de d’apporter les technologies de Microsoft Azure dans votre Datacenter.

C’est pour simplifier la mise en œuvre de Windows Azure Pack que Microsoft a lancé l’initiative Cloud Plateform System en partenariat avec Dell (c’est le premier partenaire, il y en aura d’autres). L’objectif est de fournir une plateforme clef en main. Dell et Microsoft ont collaboré pour livrer un “Stamp” comprenant à la fois compute, storage et network. C’est le bloc de base qu’on va assembler.

Image Offre Dell Azure Pack Microsoft CLoud Plateform

Du point de vue matériel, notre bloc de base, c’est quand même :

  • 512 cœurs (dual socket Intel Ivy Bridge, E5-2650v2 CPU) répartis entre 32 serveurs
  • 8 To de mémoire vive avec 256Gb par serveur
  • 282 To de stockage utilisable (Storage pool, SMBv3, …)
  • 1360 GB/s de connectivité dans le rack
  • 560 GB/s de connectivité entre les racks (on peut assembler jusqu’à 4 racks)
  • Jusqu’à 60GB/s de connectivité vers le monde extérieur

Bref, vous m’en mettrez deux Tire la langue.

Ce “Stamp” est livré préconfiguré avec Windows Azure Pack. De mon point de vue l’offre est intéressante car :

  • On se décharge du design du Stamp, c’est du standard
  • Le support Microsoft sera l’interlocuteur unique, y compris pour le matériel Dell
  • On se concentre sur l’offre que l’on veut concevoir et non sur la technique sous-jacente

C’est une excellente nouvelle pour faciliter l’adoption de Windows Azure Pack.

 

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

Microsoft n'oublie pas la sécurité de ses OS "Legacy"

Avec le cycle "Rapid release" de Microsoft ces derniers temps pour les produits "On premise", on pourrait penser que Microsoft oublie un peu ses systèmes "Legacy". On parle ici de Windows 7 et Windows Server 2008 R2, des OS pas si vieux que cela. Pourtant entre temps, on a déjà eu droit à :

  • Windows 8 / Windows 2012
  • Windows 8.1 / Windows Server 2012 R2
  • Et bientôt Windows 10 preview / Windows Server 10 preview

Donc oui, Windows 7, c'est super véritablement un OS "Legacy" pourtant, il a encore une belle vie devant lui.

    clip_image001

Même si Microsoft pousse en avant ses nouveaux systèmes d'exploitation et les nouvelles fonctionnalités de sécurité, il n'en oublie pas moins les systèmes "legacy". Ce mois-ci, dans le cadre du processus de livraison mensuel des correctifs, Microsoft a mis à disposition :

Initialement, ce sont des fonctionnalités de sécurité qui sont disponibles que depuis Windows 8. C'est un mouvement intéressant de la part de Microsoft, l'éditeur n'oublie pas le système d'exploitation les systèmes d'exploitation les plus déployés.

 

Note : En date du 17/10/2014, Microsoft a retiré le correctif KB2949927. Il semblerait qu'il soit source de problèmes rencontrés par certains utilisateurs suite à son installation. On attendra donc un peu avant de pouvoir le déployer.

 

BenoîtS - Simple and secure by design but business compliant

Windows Azure Pack–Les APIs publiques des locataires

Attention, âmes sensibles, arrêtez vous ici. j’y ai laissé une boite d’aspirine et des nuits sans sommeil. Si vous n’êtes qu’un locataire d’une plateforme Windows Azure Pack, passez votre chemin. Par contre, les exploitants sont invités à rester enfermé dans la salle des tortures de mon donjon avec moi.

Maintenant qu'on a quelque chose de présentable du point de vue end-user, intéressons-nous à ce que nous présentons sous la moquette. Le portail, c'est bien mais pour nos clients, des services cloud, c'est bien plus qu'un portail, c'est aussi un jeu d'API exposé pour consommer les services. C'est un sujet que j'avais volontairement exclus du billet précédent car je voulais y consacrer un billet pour explorer à la fois la partie serveur mais aussi cliente. On verra qu'il y a beaucoup de parallèles avec son grand frère.

 

Partons de l'expérience de notre locataire

Lorsque nos locataires se connectent sur le portail, voilà l'interface qui leur est présentée. S'il dispose déjà d'un compte sur la plateforme, il peut s'authentifier. Les mécanismes d'authentifications feront l'objet de plusieurs billets (c'est presque un monde à part).

clip_image001

Pour ceux qui se posent la question et ne peuvent pas attendre les prochains billets, ce compte a été créé par WAP dans sa base SQL. Ce ne sont pas des comptes AD. Coté utilisateur, on peut aussi lui proposer de créer son propre compte. Celui-ci ne sera actif qu'après validation.

clip_image002

C'est un choix du fournisseur de la plateforme de Windows Azure Pack. Plus généralement, Windows Azure Pack propose des fonctionnalités pour gérer le cycle de vie des comptes de ses locataires (réinitialisation de mot de passe, vérification de compte, …).

clip_image003

A mon sens, ce n'est pas une bonne idée de laisser les utilisateurs se créer leurs propres comptes ainsi. Les informations fournies par l'utilisateur sont très minimalistes. En tant que fournisseurs de service, on ne dispose pas assez d'informations pour savoir à qui adresser la facture. Des mécanismes de notification peuvent être activés (envoi de mail de confirmation, …). Bref, c'est pas si mal que cela pour une V1. J'ai hâte de voir la V.Next.

clip_image004

Dans le cas présent, j'ai déjà un locataire (oui il a fuit lâchement mais on le torturera plus tard, …) sur ma plateforme, et il a souscrit à un plan.

clip_image005

Nous avons donc un client provisionné, il peut utiliser son portail ou accéder directement à l'API publique lui permettant de manipuler son tenant.

 

Un peu de travail coté client avant de commencer

Si Windows Azure Pack est le petit frère de Microsoft Azure, c'est pas pour rien. Il réutilise déjà la même plateforme pour installer ses prérequis : Le web Plateform Installer. S'il est pas déjà installé, c'est disponible à cette adresse dans Microsoft Azure. Dans la section "Command-Line Tools", il y a une sous-section Windows PowerShell. Y a plus qu'à cliquer sur Install.

clip_image006

Avec un peu de patience (surtout vi vous avez un débit en download proche du néant), ça fini par arriver.

clip_image007

On passe par cet installer pour installer l'API PowerShell de Microsoft. Elle inclus celle de Windows Azure Pack, on verra plus loin que c'est un sous-ensemble.

clip_image008

Dans ma liste de course, un seul élément : Microsoft Azure PowerShell. La taille du download peut varier en fonction de l'évolution de l'API mise à disposition par Microsoft (oui elle évolue vite) et des autres prérequis qui peuvent être nécessaires (Framework Dot.Net 4.0).

clip_image009

Même si c'est pas indiqué dans l'interface, il y a du monde dans les prérequis, donc il faut prendre son mal en patience.

clip_image010

Le processus d'installation est direct, pas de questions superficielles. Jusqu'à maintenant, c'est de l'Azure-like.

clip_image011

Au terme de l'installation, on peut nous demander de redémarrer notre poste de travail. En même temps, vu le nombre de composants installées, c'est normal. Attention, si un redémarrage est nécessaire, c'est que peut être des composants vont continuer à s'installer après.

clip_image012

Après redémarrage, on constatera que le module demandé est bien installé.

clip_image013

Au final, voilà la liste des composants installé sur le poste de travail de mon locataire.

clip_image014

Un rapide tour du propriétaire nous confirme que Windows Azure Pack a bien Microsoft Azure comme parent. Cela veut dire qu'ils auront beaucoup de choses en commun.

clip_image015

A ce stade, pas possible d'aller plus loin et pour cause, l'accès au TenantAPI nous sera refusé. What? Ouvrez la boite d’aspirine et avalez la tout de suite. Bienvenu dans la salle de torture de mon donjon.

 

Les APIs du tenant

C'est maintenant que ça se complique car elles sont deux et il n'y en a qu'une qui nous intéresse tout de suite, c'est la TenantPublicAPI. C'est un composant de Windows Azure Pack. A ce titre, il dispose donc d'un namespace que nous pouvons explorer avec le module PowerShell que nous connaissons déjà.

clip_image016

La différence entre TenantAPI et TenantPublicAPI tiens au fait que l'une est censé être exposée sur Internet, l'autre non. Donc c'est TenantPublicAPI qui nous intéresse. Comme pour les autres modules, il est configuré pour utiliser un certificat auto-signé et un port exotique. La commande PowerShell Get-MgmtSvcFQDN nous le confirmera. Coté IIS, on a bien un site web MgmtSvc-TenantAPI.

clip_image017

Vu l'expérience précédente avec les deux portails, on se doute bien de ce qu'on va trouver dans IIS (c'est toujours aussi moche).

clip_image018

Pas la peine de faire un dessin. Le certificat auto-signé du Web Service devra être remplacé avec un certificat délivré par une autorité reconnue par nos futurs locataires. Comme pour le portail des locataires et le TenantAuthSite, c'est un composant que nous devrons exposer sur Internet. Dans ma maquette, tous les composants de Windows Azure Pack sont installés sur la même plateforme. La bonne pratique serait de localiser les modules TenantAuthSite, TenantPortal et TenantPublicAPI en DMZ, sur un même serveur. D'un point de vue sécurité, l'erreur est de localiser le TenantAPI et le TenantPublicAPI sur la même machine exposée sur Internet. Pour faire simple, on va conserver la même adresse IP ainsi que le port exotique. Dans mon DNS interne, j'ai donc créé l'entrée suivante : TenantPublicAPI.WindowsAzurePack.Lan et demandé le certificat ci-dessous :

clip_image019

Ce certificat sera utilisé pour remplacer le certificat existant sur le binding tout en conservant le port par défaut (30006).

clip_image020

Note : Redémarrer le site web est encore essentiel. On va écraser le binding actuel, le TenantPublicAPI ne répondra plus.

Les puristes de IIS me reprocheront de ne pas utiliser la fonctionnalité Server Name Indication (SNI) disponible depuis IIS 8.0. Certes, cela permet de binder plusieurs certificats sur une même adresse IP en conservant le port 443 plus "user-friendly" mais dès lorsqu'on va faire du scale-out avec Windows Azure Pack, on va finir par dédier un serveur et donc une adresse IP. En plus, cela implique que les navigateurs Internet de vos clients le supporte (impose l'usage de TLS). Enfin, avec la haute disponibilité, est-ce que votre matériel supporte le SNI? Au final, même si cela fonctionne, c'est imposer une forte contrainte d'accès à notre service Cloud. Voulez-vous vous priver d'une partie de vos futurs locataires? Au passage, offrez une boite d’aspirine à votre équipe réseau. Elle en aura besoin lorsqu’on commencera à parler haute disponibilité Sourire.

Nous revoyons la commande Set-MgmtSvcFqdn que nous avions déjà utilisée. C'est pas plus compliqué que cela. Vu qu'on a déjà reconfiguré le TenantAuthSite,

clip_image021

Note : Ne pas oublier de redémarrer le Web Service.

Voilà pour l'API exposée à nos futurs locataires. Passons maintenant à la TenantAPI. Microsoft a séparé l'API dédiée au tenants en deux parties pour isoler certaines fonctions, pour que celles-ci ne soient pas accessibles depuis Internet.

clip_image022

Allons l'explorer un peu la configuration de ce namespace avec la commande Get-MgmtSvcFQDN :

clip_image023

Il opère donc sur le port 30005 et utilise un certificat auto-signé. On va donc avoir une nouvel enregistrement DNS tenantapi.windowsazurepack.lan, donc un nouveau certificat issu de mon autorité de certification interne.

clip_image024

Dans la console IIS, on va remplacer le certificat auto-signé tout en conservant le port 30005.

clip_image025

Note : On n'oublie pas de redémarrer le site web pour que la configuration soit active.

Encore une fois, il faut aussi actualiser l'information dans la base de données de Windows Azure Pack avec la commande Set-MgmtSvcFqdn que nous avions déjà utilisée.

clip_image026

 

Y a des détails qui changent tout

On est prêt coté serveur. Pourtant, il reste un truc qui me chiffonne. Comment Windows Azure Pack pouvait-il accepter de fonctionner avec des certificats auto-signés. Y avait forcément un truc sous la moquette. Dans le billet sur le Best-Practice Analyzer de Windows Azure Pack, on avait mis le doigt sur un sujet important :

clip_image027

Y a des résidus. OK, on pourrait directement attaquer les fichiers de configuration IIS ou utiliser le module Powershell WebAdministration pour corriger le problème. C'est faisable mais pas élégant. En plus Windows Azure Pack à mieux à proposer. Revoyons un peu la liste des commandes mises à disposition par le module de configuration de Windows Azure Pack.

clip_image028

Explorons un peu la configuration de nos deux namespaces du moment (TenantAPI et PublicTenantAPI), on a des choses à voir.

clip_image029

On va commencer par reconfigurer le namespace TenantAPI pour bien vérifier les certificats SSL qui lui sont présentés.

clip_image030

Idem pour le TenantPublicAPI.

clip_image031

Là où cela devient intéressant, c'est que ce paramétrage des namespaces a été poussé sur tous les serveurs raccordés à notre infrastructure Windows Azure Pack. C'est donc un moyen très efficace de propager des paramétrages quel que soit la taille de notre infrastructure.

 

Back to client-side

Coté Windows Azure Pack, c'est bon. Revenons à notre locataire qui veut utiliser le module PowerShell de Microsoft Azure pour piloter les actions dans son tenant. Pour simplifier les choses, mon utilisateur de test est déjà enregistré et a souscrit à un plan. Dans son portail, il n'y a pas grand-chose. On retrouve des rubriques que nous connaissons déjà dans le portail de son grand frère.

clip_image032

Note : Je suis sur un client qui reconnait l'autorité de certification émettrice du certificat Wapcloud.Windowsazurepack.lan et en mesure de récupérer sa CRL. Sinon, c’est tout de suite moins fun Sourire.

Comme pour Microsoft Azure, ce qui nous intéresse c'est le fichier XML PublishSettings.XML. Dans Microsoft Azure, c'est disponible à cette adresse https://windows.azure.com/download/publishprofile.aspx. Dans Windows Azure Pack, c'est le même principe, y a juste l'adresse qui change. Dans ma maquette, il est disponible à l'adresse suivante https://wapcloud.windowsazurepack.lan/publishsettings.

clip_image033

Si on regarde le contenu, on retrouve beaucoup d'éléments que nous connaissons déjà. On constate aussi qu'il était temps de modifier l'URL de Service Management (TenantPublicAPI).

clip_image034

Passons maintenant au plat de résistance, le module PowerShell. Comme indiqué, les commandes relatives à Windows Azure Pack sont un sous-ensemble de celles de Microsoft Azure.

clip_image035

Avec Microsoft Azure, on utiliserait la commande Import-AzurePublishSettingsFile pour se connecter à notre tenant. Avec Windows Azure Pack, c'est presque cela : Import-WAPackPublishSettingsFile.

clip_image036

Ce fichier contenait un peu plus d'informations que prévu. Il contenait un certificat installé dans notre magasin personnel (avec sa clé privée). Cherchez pas, c'est encore un auto-signé.

clip_image037

C'est ce même certificat que nous retrouvons dans le portail du locataire dans la section "Management certificates". Nous conservons la clé privée. Coté Windows Azure Pack, il n'y a que la clé publique de référencée.

clip_image038

Note : Vu ce que contient mon fichier publishsettings, la recommandation est de le supprimer dès que l'importation a été réalisée.

 

Ca y est, on a fini. Bienvenu dans ton cloud locataire (oui j’ai osé la faire Tire la langue).

 

Même si j’ai clos ce sujet, je suis pas à l’abris d’en découvrir encore sur les API dédiées aux locataires. Le billet sera donc actualisé en fonction des découvertes. Faites les stocks de boite d’aspirine.

Félicitations à ceux qui sont arrivés au terme de ce billet. Ils méritent le badge “Windows Azure Pack survivor”. cependant, vous êtes encore loin de devenir le maitre du donjon. Il reste beaucoup de choses à voir dans la salle des tortures, … Sournois

 

BenoîtS - Simple and Secure by design but business compliant

Windows Azure Pack Best Practice Analyzer

Une petite pause dans ma quête de Windows Azure Pack. Avant que ça pique trop les yeux et que cela devienne réellement une prise de tête,je cherche toujours à savoir si "out-of the box", il n'y avait pas un peu d'aide intégrée (le Update-Help c'est magique mais y a pas que Powershell dans la vie). Avec mon installation par défaut de Windows Azure Pack, cela devait être le cas puisqu'on avait un module "Microsoft Best Practice Analyzer" installé par défaut.

clip_image001

Il ne me manque donc que de quoi tirer profit de cette aide en installant le Microsoft Baseline Configuration Analyzer.

clip_image002

Bien évidemment, il n'est pas installé par défaut. Une fois installé, il détecte automatiquement le module d'analyse de configuration de Windows Azure Pack. A noter que si nous avions une installation distribuée de la bête, il faudra donc installer le MBCA sur tous les hôtes concernés.

clip_image003

Une fois l'analyse terminée, les précieux conseils sont prodigués.

clip_image004

Dans la liste des conseils, il y a des évidences :

  • Remplacer les certificats auto-signés et reconfigurer WAP c'est bien, c'est mieux si on supprimait aussi les certificats auto-signés
  • Installer tous les modules sur le même serveur, c'est le mal incarné

Mais il y a aussi de précieux conseils :

  • Remplacer les certificats auto-signés c'est bien mais si en plus on supprimait le paramètre DisableSSLCertValidation de la configuration IIS ce serait mieux
  • Conserver SSL V2, c'est un crime (sic)

Le produit facilite aussi grandement la recherche des configurations "exotiques". Dans l'illustration ci-dessous, on retrouve bien l'utilisation de la désactivation de de la vérification de certificats SSL activée.

clip_image005

Au passage, si descendre dans les entrailles de la bête ne vous effraie pas, le WAPTrace mis à disposition par Microsoft est très pratique. Attention, ça va piquer les yeux. C'est des Web Services qui causent entre eux.

 

Bref, y a de quoi encore occuper des longues soirées d’hivers avant d’arriver au bout de la bête.

 

BenoîtS - Simple and secure by design but business compliant

Some new DirectAccess unsupported scenarios

I was involved in some DirectAccess pre-sale & projects with One-Time Password feature. For a while we have a dedicated Technet web page for special cases / requests or scenarios DirectAccess Unsupported Configurations. I used to have a look at it some time to time to check if I missed something. Today, I was surprised to  discover new section related to OTP scenarios :

UNSUPPORTED

I understand for the second one. We must establish a SSL session excluded from the IPSEC tunnel, that is not possible with force tunneling. IMO, force tunneling feature need to be reviewed (a wish for Windows V.Next). From a technical point of view we can replace it with the Web Filtering for DirectAccess users approach.

For the first one, it’s a surprise. I was about to consider the SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP proposed by Richard Hicks for a project of mine including OTP. I will have to forget SSL Offload. In some way it’s logic, we cannot have different way to manage SSL authentication for the same endpoint (ISAPI filter used by OTP and IPHTTPS endpoint).

 

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

MVP Enterprise Security MVP renewed, six year now

You will have to support me and my obscure blog post one more year. I was renewed as Enterprise Security MVP one more year. Like last year, I reviewed posts I published this year to look if I reached my objectives.

So expect to see some Windows Azure Pack posts in the next weeks.

 

Benoits – Simple and Secure by design but business compliant

Personnalisation des URL de Windows Azure Pack
    shocking isn't it?

    La première chose qui choque, ce sont les URL en localhost, ports exotiques ainsi que la collection de certificats auto-signés. Ci-dessous ce qu'on peut constater à la première connexion au portail d'administration de Windows Azure Pack.

    clip_image001

    Pour le portail des tenants, c'est pareil, pas vraiment user-firendly pour offrir du service. En même temps, le processus d'installation de Windows Azure Pack est on ne peut plus direct. A part la configuration de la base SQL Server (en mode mixte obligatoirement) et la pass-phrase nécessaire pour accéder à la configuration de Windows Azure Pack, il n'y a aucune question sur les certificats ou URL à utiliser. Le sujet n'étant pas si simple, je me suis inspiré de l'excellent billet Windows Azure Pack - Reconfigure portal names, ports and use trusted certificates. Le seul défaut, c'est que ça va direct à l'essentiel, sans expliquer pourquoi on doit en passer par là, pourquoi c'est si compliqué.

    Si on relit mon billet Quelques notes sur Windows Azure Pack, Windows Azure Pack n'est qu'un assemblages de Web Services au-dessus desquels on trouve deux portails. Dans le contexte de ce billet, on va se focaliser sur les sites web & Web services suivants:

  • WAP Tenant Portal Service (MgmtSvc-TenantSite): Hosts the WAP Tenant Portal
  • WAP Tenant Authentication Service (MgmtSvc-AuthSite): Hosts the authentication for tenants
  • WAP Admin Portal Service (MgmtSvc-WindowsAdminSite): Hosts the Admin Portal
  • WAP Admin Authentication Service (MgmtSvc-WindowsAuthSite): Hosts the Admin Authentication
  • Donc on devine qu'à un moment ou un autre, il faudra traiter le cas de certificats auto-signés restant.

    Situation de départ

    Dans une installation par défaut, on utilise des certificats auto-signés et pas qu'un peu.

    clip_image002

    Bref, pas glop. On va revoir tout ça et commencer par utiliser les URL un peu plus parlantes. Dans le contexte de ce billet, on va mettre en place de véritables certificats et utiliser des ports moins exotiques que ceux utilisés à la fin de l'installation comme on peut le constater ci-dessous :

    clip_image003

    Mais pourquoi Microsoft a-t-il fait si compliqué?

    C'est simple pourtant. Windows Azure Pack est entièrement modulaire. On peut donc déployer :

  • Tous ses modules sur un même serveur (le cas de ce billet)
  • Les répartir sur plusieurs pour la haute disponibilité (ça chatouille)
  • Séparer les rôles pour assurer l'isolation (là ça commence à piquer)
  • Séparer les rôles pour assurer l'isolation et assurer la haute disponibilité (mode hardcore gamer)
  • Le processus d'installation par défaut configure tous les modules pour utiliser localhost et des certificats auto-signé (un par usage). D’où le nombre élevé de certificats sur la plateforme. Personnellement, je trouve l'approche excellente, reste à améliorer le processus d'installation pour configurer les différents modules pendant l'installation. Vu qu'on va personnaliser des modules, pas possible de faire cela depuis le site web d'administration (on va rapidement scier la branche sur laquelle on est assise), il faut donc tout faire en PowerShell.

    Plusieurs processus d'authentification

    On a deux populations (Admin & tenant) qui accèdent à des portails bien distincts. On part du principe que :

  • Les locataires doivent pouvoir accéder à leur portail depuis l'extérieur (internet)
  • Les administrateurs de la plateforme qui doivent pouvoir administrer depuis le réseau interne
  • Dans les deux cas, Microsoft a utilisé une approche modulaire et distingué :

  • Le portail en lui-même qui va exploiter une module d'authentification
  • Le module d'authentification lui-même qui peut utiliser plusieurs fournisseurs d'authentification
  • Un Web Service offrant les API propre à chaque usage
  • On ne peut pas segmenter plus. Quelque part, on peut comparer Windows Azure Pack avec Mindcraft. On va tous avoir les mêmes briques et pourtant en faire des univers totalement différents PAAS, IAAS, …

    Notre cible

    La cible, c'est d'avoir des URL plus user-friendly pour les portails d'administration et celui destiné aux locataires. C'est le minimum. Dans le tableau ci-dessous la configuration que nous allons mettre en place.

    Module WAP Nouvelle URL Port

    WAP Admin Portal

    wapadmin.WindowsAzurePack.Lan 443

    WAP Tenant Portal

    wapcloud.WindowsAzurePack.Lan 443

    WAP Tenant Auth

    wapcloud.WindowsAzurePack.Lan 444

    Là où cela se complique, c'est que chaque portail utilise son propre module d'authentification qui va lui-même rediriger vers le portail initial suite à une authentification validée. Ça peut sembler compliqué comme cela mais c'est la modularité de Windows Azure Pack qui veut ça et ça fait sa force car :

  • Les deux portails sont distincts, ce qui est une bonne chose du point de vue de la sécurité
  • Chaque portail peut avoir sa propre politique d'authentification (ADFS pour les locataires et ADFS +MFA pour les administrateurs)

 

    On a besoin de certificats y a un docteur dans la salle?

    Docteur PKI? Nous utiliserons une autorité de certification reconnue à la fois de l'infrastructure Windows Azure Pack et des locataires. Dans la vrai vie, le besoin de certificats publics (reconnus de tous) se limite aux modules exposés sur Internet. Cela concernerait donc les modules suivants:

  • Le WAP Tenant Portal
  • Le WAP Tenant Auth
  • Dans notre contexte, c'est simple, on a besoin de trois certificats pour les FQDN suivants :

  • WAPADMIN.WINDOWSAZUREPACK.LAN
  • WAPCLOUD.WINDOWSAZUREPACK.LAN
  • WAP01.WINDOWSAZUREPACK.LAN
  • La seule subtilité à prendre en compte à ce niveau, c'est la haute disponibilité (future?) de ces composants. Si vous prévoyez de faire évoluer votre plateforme vers la haute disponibilité, il faudra donc être capable d'exporter le certificat avec la clé privée. Une configuration à ne pas oublier dans le paramétrage du gabarit de certificat car c'est pas par défaut.

    Pour le certificat WAPADMIN.WINDOWSAZUREPACK.LAN, le docteur PKI utilise simplement la console IIS pour générer son ordonnance. C'est un certificat à usage interne, il peut donc être délivré par mon autorité de certification interne.

    clip_image004

    Le certificat WAP01.WINDOWSAZUREPACK.LAN correspond au nom de mon serveur WAP. C'est vers lui que seront redirigées les demandes d'authentification en provenance du portail des administrateurs de Windows Azure Pack. Il n'est pas nécessaire qu'il soit délivré par une autorité de certification reconnue par tous les navigateurs car nous partons du principe que ce portail n'a pas à être exposé sur Internet.

    clip_image005

    Enfin, le certificat WAPCLOUD.WINDOWSAZUREPACK.LAN sera utilisé à la fois par le portail d'authentification des locataires mais aussi par le web service chargé de leur authentification. Comme le portail des locataires et le web service d'authentification sont hébergés sur le même serveur, ils partageront le même certificat, restons simple.

    clip_image006

    Au final, voilà à quoi ressemble le magasin personnel de certificats de mon serveur WAP. Un vrai bordel. Va y avoir beaucoup de travail pour remettre cela au propre.

    clip_image007

    A ce stade, autant vous avertir, les deux portails vont vite devenir inutilisables, ce qui est logique vu qu'on modifie les noms et les ports pour lesquels ils répondent. Pour cette raison, toute cette configuration ne peut être réalisée qu'en PowerShell.

     

    Commençons par le portail des administrateurs de Windows Azure Pack

    C'est un site web dans IIS, donc simplement en changeant le binding, on devrait y arriver. Dans la console IIS, c'est le site web MgmtSvc-AdminSite. A ce stade, il répond en HTTPS avec un certificat auto-signé et en plus sur le port 30091. Plus moche c'est pas possible. On va donc s'assurer que ce portail réponde en utilisant une URL plus user-friendly : wapadmin.windowsazurepack.lan et utiliser le certificat que nous avons demandé.

    clip_image008

    Note : Ne pas oublier de redémarrer le site web. Immédiatement, on constatera que le portail n'est plus utilisable, on verra pourquoi un peu plus loin.

     

    Continuons avec le Web service d'authentification associé

    WAP? Ben oui, Windows Azure Pack est totalement modulaire, au point de séparer le portail des fonctions d'authentifications. On le approfondira ce point plus tard mais le portail sollicite le Web Service MgmtSvc-WindowsAuthSite dédié pour l'authentification des utilisateurs du portail d'administration de Windows Azure Pack. Etant donné que cela donne accès aux privilèges les plus élevés de la plateforme, c'est pas le portail accessible par monsieur tout le monde qui consomme du cloud. La recommandation serait même de ne pas l'exposer sur Internet. Pour cette raison, je n'ai pas personnalisé l'URL (cela aurait été nécessaire dans un scénario de HA), ni changé le port par défaut. De toute façon vu que c'est pas visible des utilisateurs consommateurs du service, ce n'est pas essentiel à mes yeux.

    clip_image009

    Note : Ici encore, il faut redémarrer le Web Service pour qu'il prenne en compte la nouvelle configuration.

     

    Fracassons maintenant le portail des locataires

    Maintenant qu'on a fracassé le portail des administrateurs de la plateforme, autant continuer avec le portail des locataires et foutre le bordel jusqu'au bout. C'est donc le site MgmtSvc-TenantSite dans la console IIS. Par défaut, il utilisait aussi un certificat auto-signé et un 30081 comme port exotique.

    clip_image010

    Note : On n'oublie pas de redémarrer le site web pour être sûr que le portail ne fonctionne plus.

     

    Achevons le dernier Web Service

    Pour le portail des locataires, la fonction est elle-aussi externalisée dans le Web Service MgmtSvc-AuthSite. D'un point de vue technique, c'est intéressant car on peut proposer deux politiques d'authentification distincts utilisant des technologies différentes. Ici, c'est le Web service vers lequel les locataires sont redirigés pour s'authentifier. Il sera donc exposé sur Internet (mais pas directement, on a le Web Application Proxy pour cela, un autre WAP). Initialement, le Web Service utilise un certificat auto-signé au nom du serveur sur lequel le module est installé et utilise le port 30071. Du point du vue des futurs consommateurs du service, c'est tout sauf user-friendly. On va donc utiliser la même URL (et donc le même certificat) que pour le portail et utiliser le port 444.

    clip_image011

    Note : On n'oublie pas de redémarrer le site web pour être sûr que le portail ne fonctionne plus. A ce stade, le commandant sylvestre a atteint son objectif.

    Now fun begins, Time to dive into Windows Azure Pack Admin API

    Bizarrement, à ce stade, plus rien ne fonctionne. Et pour cause, même si on a changé les bindings dans IIS, les différents composants n'en savent rien. La configuration stockées dans la base de données de Windows Azure pack doit aussi être actualisée. Passons donc du côté obscur de Windows Azure Pack avec le module PowerShell MgmtSvcConfig.

    clip_image012

    Rien qu'en parcourant la liste des commandes associées à ce module, on repère tout de suite que certaines vont occasionner de sérieux maux de tête, voire des "nervous breakdown" comme ils disaient dans les tontons flingueurs. C'est bien d'avoir la liste des commandes mais on veut reconfigurer des modules de Windows Azure Pack, plus précisément des Namespaces. Voyons la liste des namespaces que nous pouvons gérer avec la commande Get-MgmtsvcNamespace :

    clip_image013

    Ça commence à causer. Dans la liste des namespaces, on retrouve certaines notions que nous avons déjà vu et d'autres que nous ne connaissons pas encore. C'est normal, Windows Azure Pack est totalement modulaire. Lorsqu'on ajoute un nouveau module, on a donc un nouveau namespace. Ça commence à devenir intéressant car Microsoft propose une API unifiée pour gérer tous les namespaces même si ça concerne MySQL (What?).

    Avant de se lancer dans la reconfiguration à tout va, essayons de comprendre comment fonctionne le processus d'authentification du portail d'administration de Windows Azure Pack. Par défaut, le processus d'authentification utilisé par le Web Service dédié au portail d'administration utilisera l'authentification Windows intégrée. Certes nous avons uniquement changé les bindings dans IIS mais vu que tous les modules doivent communiquer entre eux, il faut bien que l'information soit stockée à un emplacement (La base SQL de Windows Azure Pack).

    La commande Powershell Get-MgmtSvcFQDN permet de connaitre les informations de configuration pour le namespace AdminSite. Si on compare avec ce que nous avons maintenant dans IIS, effectivement nous avons un problème.

    clip_image014

    L'AdminSite va devoir solliciter le web service d'authentification et ce dernier devra renvoyer l'utilisateur au portail une fois authentifié. Le problème, c'est que le Web Service va utiliser l'information dans la base SQL pour déterminer où renvoyer l'information. Une actualisation du namespace s'impose pour référencer la nouvelle URL ainsi que le port à utiliser. La commande PowerShell Set-MgmtSvcFqdn est faite pour cela.

    clip_image015

    Le portail, c'est ce qu'il y a de plus visible du point de vue des administrateurs de Windows Azure Pack. Pourtant, il y a aussi le Web service dédié à l'authentification. Lorsqu'ils vont tenter d'accéder au portail, la première chose que celui-ci va faire sera de les rediriger vers le Web Service. C'est un RelyingParty, on va causer gestion d'identité (sic). La commande Get-MgmtSvcRelyingPartySettings permet d'explorer le paramétrage du namespace Admin. Le web service est configuré pour utiliser un certificat auto-signé (correspondant au nom du serveur Windows Azure Pack sur lequel il est installé) et un port exotique : 30071.

    clip_image016

    Bref, ici encore c'est un peu bancal. On va donc l'aider un peu en reconfigurant le RelyingParty pour utiliser un nouveau port 30072 et au passage utiliser le nouveau certificat, le tout avec un petit Set-MgmtSvcRelyingPartySettings.

    clip_image017

    j'ai perdu personne? Donc l'administrateur s'est connecté au site d'administration, lequel l'a redirigé vers le web service d'authentification. Après authentification, il faut le renvoyer à l'envoyeur vers le portail d'administration de Windows Azure pack. Et vous croyez qu'il va renvoyer vers qui? Cette fois c'est au fournisseur d'identité que nous devons nous adresser avec la commande Get-MgmtSvcIdentityProviderSettings.

    clip_image018

    Il renvoie bien vers notre serveur mais notre portail d'administration ne répond plus à cette adresse. Maintenant c'est WAPADMIN.WINDOWSAZUREPACK.LAN. Bref, il faut lui aussi l'aider un peu pour lui indiquer la bonne URL et le bon port. A ce stade, il est essentiel de disposer d'un accès à la base de données de Windows Azure Pack et de la commande Set-MgmtSvcIdentityProviderSettings.

    clip_image019

    Pour une raison que j'ignore, la commande de fonctionne que si on lui adjoint le paramètre DisableCertificateValidation. Sans lui, la commande ne passe pas. Après une recherche rapide, le paramètre est nécessaire uniquement si on utilise des certificats auto-signés

    clip_image020

    A mon niveau, je ne suis pas encore capable de déterminer si c'est un problème de ma configuration ou un effet de bord des certificats auto-signés qui pullulent sur l'environnement. Mais, je prends quand même les paris pour un effet de bord du à la présence des certificats auto-signés.

    C'est clos pour le portail d'administration de Windows Azure Pack. Intéressons-nous maintenant au portail de locataires. Cela va suivre la même logique ou presque. La subtilité, c'est l'utilisateur. Pour les administrateurs, ce sont des comptes de l'annuaire Active Directory. Pour les locataires, c'est pas si évident que cela. Le portail des locataires va consommer des claims en provenance d'un fournisseur d'authentification qui peut être ADFS ou .Net. Ça ouvre des perspectives. C'est ce dernier qui est configuré par défaut. Plus précisément, c'est le ASP.NET Membership provider. On s'attaquera à celui-là en dernier. Commençons par la gestion des URL du namespace TenantSite. Voyons un peu la configuration par défaut avec la commande Get-MgmtSvcFQDN :

    clip_image021

    On va devoir personnaliser l'URL (WAPCLOUD.WINDOWSAZUREPACK.LAN) et reconfigurer le port par défaut car 30081, c'est tout sauf user-friendly. La commande Set-MgmtSvcFQDN va nous y aider.

    clip_image022

    Le portail, c'est bien mais on sait très bien qu'il y a un web service en charge de l'authentification qui doit être corrigé. C'est ne namespace AuthSite. La commande Get-MgmtSvcFQDN nous révèle la configuration de ce namespace :

    clip_image023

    L'URL et le port par défaut doivent être reconfigurés. Vu que dans ma configuration je n'ai pas séparé le portail et le Web Service d'administration, je peux réutiliser le même FQDN, on va juste utiliser un port différent 444. Un petit coup de Set-MgmtSvcFQDN va régler le problème.

    clip_image024

    Les URL sont normalisées, reste maintenant à traiter la redirection vers le site d'authentification et le retour. Voyons comment le portail gère la redirection vers son RelyingParty avec la commande Get-MgmtSvcrelyingPartySettings.

    clip_image025

    Nous allons donc rediriger vers wapcloud.WindowsAzurepack.lan (pourquoi 444? Tout simplement par ce qu'on a déjà le portail admin sur 443 et que tout est installé sur le même serveur IIS) avec la commande Set-MgmtSvcrelyingPartySettings.

    clip_image026

    Il ne nous reste plus que le fournisseur d'identité, c'est la petite surprise. Un peu plus tôt, j'avais indiqué que par défaut, le module d'authentification du portail des locataires utilisait le fournisseur ASP.NET Membership. C'est juste un nouveau namespace à manipuler : Membership. Voyons à quoi il ressemble avec la commande Get-MGMTSVCIdentityProviderSettings.

    clip_image027

    Reste plus qu'à rediriger vers la source, à savoir wapcloud.windowsazurepack.lan.

    clip_image028

    Ca y est, c’est fini.

     

    Sinon ça marche à la fin?

    Ben oui, on ne se donne pas autant d'effort pour que cela ne fonctionne pas. Ci-dessous le portail de locataires avec une URL nettement plus user-friendly :

    clip_image029

    Et le portail des administrateur de Windows Azure Pack :

    clip_image030

    Windows Azure Pack peut sembler un peu "brut de décoffrage” mais si vous regardez son grand frère Windows Microsoft, c'est exactement la même chose. Lorsque de nouvelles fonctionnalités sont annoncées, elles sont utilisables en premier lieu en PowerShell avant d'être disponible dans l'interface graphique et c’est lui aussi un produit hautement modulaire.

     

    Prochaine étape cortex?

    C'est de dominer le monde minus, offrir des services cloud et dominer le monde minus. Plus sérieusement, on va passer un peu de temps pour exposer le portail des locataires sur Internet et travailler un peu les mécaniques d'authentification.

     

    Que les API du Windows Azure Pack soient avec vous

     

    BenoîtS - Simple and secure by design but Business compliant

Petite KB pour les upgrade de domaine W2K3 vers W2K12 R2

Back to basics. C’est la saison des projets d’upgrade des infrastructures basées sur Windows 2003. l’OS a presque dix ans. Dans le cadre d’un projet de mise à niveau des infrastructure d’annuaire, nous aurons donc des contrôleurs de domaine Windows 2003 qui devront coexister avec des contrôleurs de domaine Windows Server 2012 R2. Selon le technet, cela ne devrait pas poser de problème.

Pourtant, l’équipe en charge du support Active Directory avait publié ce billet en Juillet 2014 : It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers. La coexistence entre les deux générations de contrôleurs de domaine posait problème au niveau de Kerberos. D’un coté Windows Server 2012 R2 ne supporte plus DES (par défaut) et Windows Server 2003 ignore les nouveaux algorithmes proposés par Windows Server 2012 R2. Bref, on avait une certaine cacophonie au niveau de Kerberos qui pouvait conduire à l’impossibilité de changer le mot de passe des systèmes raccordés au domaine. Pour adresser cette problématique, Microsoft proposait une méthode de contournement (en attendant de finaliser le démantèlement des contrôleurs de domaines Windows 2003).

Depuis fin Aout, la méthode de contournement proposé par Microsoft n’est plus d’actualité puisqu’un correctifs est enfin disponible : KB2989971 - Can't log on after changing machine account password in mixed Windows Server 2012 R2 and Windows Server 2003 environment. A installer sur tous vos contrôleurs de domaine Windows Server 2012 R2.

 

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

Quelques notes sur Windows Azure Pack

Depuis fin 2013, je suis tombé dans le monde de Windows Azure Pack. C'est un peu comme DirectAccess, un grand jeu de lego, sauf qu'il y a bien plus de briques, donc c'est plus amusant. Bref, c'était fait pour moi. Windows Azure Pack est un composant de la vision Cloud OS de Microsoft. J'y ai passé beaucoup de temps mais pas encore eu réellement le temps de tout synthétiser. Le but de ce premier billet est de synthétiser le contenu éparpillé dans mes nombreux OneNote sur su sujet.

The Cloud OS

clip_image001

L'idée est d'avoir une plateforme commune pour l'hébergement et le développement de services Cloud à base de Windows Microsoft Azure. Avec l'approche Private Cloud Fast track program, on utilisait les composants de la gamme System Center pour transformer le Datacenter en Cloud privé que l'on pouvait étendre par la suite à Windows Microsoft Azure. Cette approche du Cloud Hybride montrait à quel point Windows Microsoft Azure est différent des produits de la gamme System Center. Avec Windows Azure Pack, ce sont des composants Windows Microsoft Azure qui font le chemin inverse vers les entreprises et des hébergeurs pour mettre à disposition un certain nombre de fonctionnalités de Windows Microsoft Azure.

Cette approche permet aux clients de disposer d'une socle commun "Windows Microsoft Azure" que celui-ci soit :

  • Hébergé “on premise”
  • Hébergé chez un hébergeur
  • Hébergé dans Windows Microsoft Azure

 

Windows Azure Pack est une plateforme Cloud évolutive proposant plusieurs services directement inspirés de Windows Microsoft Azure :

  • Pour l'utilisateur final, Windows Azure Pack offre une interface utilisateur unifiée très proche du portail Windows Microsoft Azure, qui peut être étendu par ajout d'extensions. La localisation des ressources gérées importe peu.
  • Pour un DBA, il a la possibilité d'héberger ses bases de données SQL/MYSQL "on premise", chez un hébergeur ou même dans Windows Microsoft Azure avec la capacité de les déplacer librement. Ces ressources peuvent être mises à disposition d'utilisateur par simple souscription à un contrat. C'est un service dont l'usage est mesurable et donc facturable.
  • Pour un développeur web, c'est une plateforme PAAS hautement disponible pour de l'hébergement de sites web / Web Services.
  • C'est aussi une offre IAAS d'infrastructure proposant l'hébergement de machines virtuelles Windows ou Linux inspiré de ce que propose Windows Microsoft Azure.

 

Modularité extrême

Lors de l'installation, on comprend que Windows Azure Pack n'est pas un nouveau composant de la gamme System Center. Il vient bien d'un monde différent ou on assemble des Web Services. Cela ne l'empêche pas de coexister avec les composants de la gamme System Center.

clip_image002

 

Web Services & Json tu causeras

Windows Azure Pack est totalement modulaire et repose sur des Web Services qui communiquent entre eux. Certes tous ces Web services peuvent cohabiter sur une même machine mais dans le cadre d'un environnement de production on s'efforcera de les répartir dans différentes zones et d'assurer leur haute disponibilité avec du HLB.

clip_image003

 

Je vois des certificats partout

Qui dit Cloud & Web Services dit certificat et donc souffrance (ou fun, c'est selon). Plus on s'amusera (oui c'est fun) à isoler différents rôles et assurer la disponibilité, plus on aura de certificats à gérer. Dans l'illustration ci-dessous, la version simpliste avec tous les composants mutualisés sur un seul et unique serveur. Oui on dénombre bien quatorze certificats auto signés.

clip_image004

Cela veut dire qu'à un moment on va devoir les remplacer, et reconfigurer les web services et Windows Azure Pack pour les utiliser. C'est la partie la plus fun du setup de la plateforme.

 

On causera de bases de données

La modularité de Windows Azure Pack implique un certain nombre de bases de données. Certes beaucoup moins que le nombre de certificats ou de Web services mais cela impliquera une petite réflexion quant à la disponibilité et la localisation de ce service.

clip_image005

 

Un peu de découpage réseau

Même si tous les composants de Windows Azure Pack peuvent coexister sur un même serveur, ce n'est pas la configuration recommandée pour des raisons sécurité mais aussi haute performance. Tout comme Windows Microsoft Azure, tous les composants ne nous sont pas visibles de l'extérieur. L'infrastructure Windows Azure Pack doit être découpée en zones réseau. On peut déjà identifier les principales zones :

  • Public facing
  • Privilegied Services
  • Identity
  • Database

La zone réseau "public facing" est dédiée aux services en relation directe avec nos locataires (tenants). Windows Azure Pack offre :

  • Un portail utilisateur très proche du portail Windows Microsoft Azure
  • Un Web Service en charge de l'authentification des locataires (dont ADFS peut faire partie)
  • Un Web service fournissant toutes les API "publiques" nécessaires au bon fonctionnement de ces services

La zone réseau "Privilegied services" n'est pas censé être visible des utilisateurs du service mais de ses exploitants. On retrouvera donc :

  • Un portail Administrateurs lui aussi très proche du portail Windows Microsoft Azure
  • Un Web Services en charge de l'authentification de nos administrateurs
  • Un Web Service fournissant toutes les API nécessaires au bon fonctionnement de ces services (il fournira le support de PowerShell pour permettre à nos locataire de gérer leurs ressources)
  • Un Web service fournissant toutes les API "privé" nécessaires au bon fonctionnement de ces services

 

La zone réseau "Identity" va contenir deux services critiques : Active Directory et ADFSv3. Ce dernier sera utilisé depuis la zone "Public facing" pour chalenger l'authentification des locataires. Enfin, reste une dernière zone pour héberger nos bases de données. Tous nos composants du Windows Azure Pack, ADFS et d'autres ont besoin d'un service de base de données hautement disponible. Autant avoir une zone réseau dédié à cet usage pour consolider nos bases de données sur un cluster. En plus cela permettra de préparer l'introduction des composants de la gamme System Center 2012 R2.

 

Ton lab tu étendras

Si tous les composants de Windows Azure Pack peuvent être hébergés sur une même machine, ce n'est pas la configuration recommandé pour les environnements de Production. Pour commencer, voilà ci-dessous ce que serait un déploiement minimaliste avec la haute disponibilité (sic) :

clip_image006

On pourrait penser qu'il est simple de séparer tous ces composants mais ce n'est pas le cas, pour plusieurs raisons :

  • Le processus d'installation utilise "localhost" dans l'URL de tous les Web Services. Il faudra donc reconfigurer des URL : Windows Azure Pack changing the default URLs.
  • Si tous les composants sont installé sur un même hôte les certificats auto-signés ne sont pas un problème. Dès lors qu'on va séparer les rôles, il faudra reconfigurer les Web Services et Windows Azure Pack pour utiliser des certificats délivrés par une autorité de certification.
  • Enfin, c'est plus présentable pour l'utilisateur de présenter des URL propres, utilisant toutes le port 443 et non un port situé dans la plage de ports dynamique.

Ça commence à piquer les yeux. Pas de problème, on peut monter en charge et découper par rôle au sein de Windows Azure Pack. Maintenant on est presque au complet :

clip_image007

On notera au passage qu'à ce stade, on ne parle pas d'extensions additionnelles (Web Sites, Virtual machines) voire même des composants de la gamme System Center dont on aura besoin et pour lesquels il faudra assurer aussi la disponibilité. Avant de vous lancer dans la haute disponibilité, la lecture ci-dessous est vivement conseillée :

Windows Azure Pack High Availability – Lessons Learned.

 

Pour héberger des services clés en main

C'est la force de Windows Azure Pack. Beaucoup d'extensions sont déjà disponibles. On évite donc de réinventer la roue pour se focaliser sur le service à offrir aux utilisateurs :

  • Web sites : Un service de publication de site web très proche de celui disponible sur Azure
  • Services bus : Un service d'échange de message pour applications
  • MS SQL extension : Un service d'hébergement de bases SQL
  • MY SQL extension : Un service d'hébergement de bases My SQL
  • MY Cloud : Un service d'hébergement de machine virtuelle basé sur SCVMM
  • Cloud Cruiser : Un service tiers dédié au reporting & billing des services consommés par nos locataires
  • Grid-pro : Une passerelle vers Service Manager

Après, rien de vous empêche de développer vos propres extensions.

 

Service Management Automation

Le Cloud ne serait pas possible sans une bonne dose d'industrialisation. Avec Windows Azure Pack, Microsoft livre Service Management Automation, une solution d'orchestration totalement intégrée qui permet d'exploiter les évènements remontés par les différents composants (inscription d'un utilisateur, souscription à un plan, …) pour déclencher des actions reposant sur des Workflow PowerShell. Deux exemples parlants :

  • Créer automatiquement le VM Network ainsi que le contrôleur de domaine lors de la création d'un nouveau tenant. L'idée étant de lui pré-provisionner les briques minimales pour héberger son propre environnement. La première brique étant un annuaire Active Directory. Après, rien de nous empêche de provisionner automatiquement d'autres services.
  • Installer automatiquement un agent SCOM sur toute machine virtuelle nouvellement déployée par un locataire.

D'ailleurs, on notera que Windows Microsoft Azure propose désormais le même service sous la dénomination Microsoft Azure Automation.

 

ADFS et Windows Azure Pack

A un moment, il faudra bien parler d'authentification, que ce soit pour les locataires ou les administrateurs de la plateforme. Pour les locataires, l'usage d'ADFS s'impose de lui-même. Les lectures suivantes sont vivement conseillées ainsi que de prendre son temps :

Pour les administrateurs du service, on considère qu'ils utiliseront par défaut une authentification intégrée Windows. Or, un peu d'authentification forte, cela ferait pas de mal. Pour cela, on a Multi-Factor Authentication qu’il est possible d’intégrer à Windows Azure Pack :

 

Service Provider Foundation

Lorsqu'on voudra faire du IAAS, il faudra communiquer avec Virtual Machine Manager. Dans sa version actuelle (2012 R2), il n'est pas possible de consommer du SCVMM directement depuis Windows Azure Pack car le premier utilise uniquement des API Rest (oData), ce que le second ne comprend pas. De plus, pour consommer des ressources dans SCVMM, il faudra bien une identité au sens Active Directory pour séparer les usages entre les différents Clouds. Le Service Provider Foundation permet donc d'exposer les services de SCVMM (jusqu'à 5 instances de SCVMM) à Windows Azure Pack. De plus le SPF permettra de mesurer l'usage du service IAAS contribuant ainsi à rendre le service mesurable et facturable, comme tout bon service Cloud. Quelques lectures sur ce sujet :

 

Les extensions de Windows Azure Pack

Windows Azure Pack est modulaire. On peut donc simplement ajouter de nouvelles extensions pour proposer de nouveaux services :

 

Un peu de lecture

A ce stade, je suis resté volontairement très "high level". Le sujet étant très vaste, ci-dessous quelques lectures qui m'ont beaucoup aidé sur le sujet :

 

Quelques pointeurs pour commencer

Quelques session du TechEd America 2014

 

Quelques outils bien pratiques

Pour finir, quelques blogs de MVP bien utiles

 

Je retourne étendre mon lab.

 

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

More Posts Next page »