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

Installation distribuée de Windows Azure Pack - Inauguration

J'inaugure un nouveau tag : Dungeon keeper. Comme déjà dit, Windows Azure Pack, c'est un peu une salle de torture tellement c’est disruptif avec que qu’on avait l’habitude de voir chez les produits Microsoft.

Ça correspond tout à fait à Dungeons keeper. On est nombreux à avoir joué à ce jeux sur PC et on est encore nombreux à y jouer sur tablettesTire la langue.

Cette série de billet a pour objectif de documenter la mise en place d'une installation distribuée de Windows Azure Pack dans un environnement aussi réaliste que possible. Je dis bien aussi réaliste que possible, dans la mesure des moyens de ma maquette.

Pour ce premier billet, on va déjà poser les bases de notre maquette avec un beau Visio. Attention, c'est une série sans fin, je sais pas encore quand je vais m'arrêter. D’où le Tag "Dungeon Keeper (Windows Azure Pack)". Aller on se lance.

clip_image001

Partons des bas-fonds du donjon avec la zone sécurité pour notre annuaire Active Directory "technique" nommé "Windowsazurepack.lan" et l'ADFS qui y sera associé. Je dis bien annuaire technique car je sais déjà qu'il n'aura aucune vocation à fournir les services d'authentification et d'autorisation pour mes futurs locataires. Dans le meilleur des cas ils authentifiera les exploitants de ma future plateforme, et encore, …

La zone Backend contiendra tous les services techniques mutualisés de la plateforme. Il faut comprendre les produits de la gamme System Center avec toutes les instances SQL server dédiées qui me seront nécessaires. Donc cela contiendra :

  • Un beau cluster SQL Server 2012 R2 en mode Always-On avec quelques instances
  • SCVMM 2012 R2
  • SCOM 2012 R2
  • SCORCH 2012 R2
  • Service Management Automation
  • Service Provider Foundation

La zone des PA/CA, c'est pour faire un détour pour parler un peu des Cluster Hyper-V que l'on va utiliser pour héberger les ressources mises à disposition de nos futurs locataires. Cette zone est sous-divisée en deux :

  • La Provider Address Space
  • La Customer Address space

C'est un domaine que je ne vais pas développer de tout de suite. De toute façon certains frenchies de DPE ont très bien traité le sujet au Teched 2014 à Barcelone dans la session: Deploying Hyper-V Network Virtualization, et en VO en plusClignement d'œil.

Nous en arrivons au cœur de Windows Azure Pack. La zone privilégiée avec les modules suivants :

  • Admin Site
  • Admin Authentication Site
  • Admin API
  • Tenant API
  • PowerShell API
  • Best Practice Analyzer

Enfin, il nous reste la zone publique, celle au plus proche de nos futurs locataires (donc sur Internet). A la surface des nuages, on va trouver les modules publics de Windows Azure Pack :

  • Tenant Site
  • Tenant Authentication Site
  • Tenant Public API

Au passage, c'est aussi dans cette zone que l'on va trouver la Gateway NVGRE mais ça c'est une autre histoire qui nécessitera une très grosse extension de mon lab.

 

Prêt à vous faire torturer à la demande?

 

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

Azure virtual Network pour plan d’adressage non compliant RFC1918

La RFC1918, défini clairement les réseaux IPv4 utilisables pour les réseau privés. Jusqu’à maintenant, Microsoft Azure ne permettait pas à des locataires de créer des réseaux usurpant des plages d’adresses publiques. D’un certain coté, c’est logique. Par contre pour un certain nombre de clients français, c’est un point bloquant car leur réseau “On-Premise” est lui même non-compliant avec la RFC1918. Lorsqu’on veut vendre du cloud Azure pour ce type de client, cette contrainte est un frein bloquant puisqu’il ne sera pas possible de mettre en place de tunnel site-to-site, ni même de déclarer des Address spaces non-compliant avec la RFC1918. Quelle ne fut pas ma surprise ce matin en découvrant cette annonce datant de la veille :

image

 

Surpris que j’étais, je me suis demandé si par le plus grand des hasard cette fonctionnalité n’était pas encore disponible pour la région européenne. Et oh surprise, c’est bien le cas. j’ai pu usurper l’adresse de base du sous-réseau dédié à Microsoft Tire la langue.

image

On peut donc tout à fait continuer à usurper les adresses Internet publiques tout en faisant du cloud. C’est moche d’un point de vue réseau mais c’est une bonne nouvelle pour les entreprises qui sont concernées par ces problématiques.

 

Si même Microsoft Azure devient disruptif, mais ou va t’on?

 

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

Posted: 11-18-2014 14:12 by Benoît SAUTIERE | with no comments
Filed under:
Windows Azure Pack– Authentification ADFS Admin-Side : Les cercles de l’enfer (7/7)

Donner accès au portail d'administration Windows Azure Pack aux exploitants du service c'est bien. Le faire en ADFS, c'est déjà pas mal. Problème, depuis le début, on ne parle que de portail. Quid de la bonne vielle invite de commande PowerShell. Comment nos exploitants vont-ils pouvoir s'authentifier en ADFS et exploiter à distance. Bienvenu dans le dernier cercle de l'enfer. Si on reprend la cinématique de connexion, tout part d'un navigateur qui va se faire rediriger vers notre serveur 'adfs.windowsazurepack.lan'. Comment expliquer à PowerShell ce concept?

clip_image001

Problème intéressant non? Avant-cela, il faut résoudre un autre problème. Comment installer les modules PowerShell en relation avec Windows Azure Pack. Ne cherchez pas, ce n'est pas inclus avec le module PowerShell de Microsoft Azure.

 

Un peu d'installation

Le Web Plateform Installer est prévu pour fonctionner avec une connexion Internet. On télécharge un élément de ‘bootstrap’ et nous présente le contenu téléchargeable. Problème, il ne nous proposera de télécharger des composants de Windows Azure Pack que si nous sommes sur un système d'exploitation compatible, donc Windows Server 2012 R2. Or ma station d'administration est un système d'exploitation client (Windows 7 pour l'occasion). Il faut donc tricher un peu et utiliser le mode d'installation "Offline". Au passage, c'est prévu par Microsoft puisque documenté ici.

On va donc commencer par télécharger et installer le package MSI du Web Plateform Installer :

De là, on va utiliser le Web Plateform Installer mais en ligne de commande WEBPICMD.EXE.

clip_image002

Bonne nouvelle, il y a des options intéressantes tel que /List et Offline. Commençons avec /List en précisant qu'on veut tout.

clip_image003

Avec un peu de patience, il finit par nous afficher la liste de tout ce qui est disponible chez Microsoft pour le Web Plateform Installer.

clip_image004

Mais d’où vient cette liste? Réponse : https://www.microsoft.com/web/webpi/5.0/webproductlist.xml. On peut donc attaquer le téléchargement avec l'option "/Offline". Pour la source, on sait quoi renseigner.

clip_image005

Dans la liste, on va forcément avoir des modules en relation avec Windows Azure Pack.

clip_image006

Deux choses à noter à la fin. Premièrement, il conserve l'historique des sources, c'est pratique.

clip_image007

Deuxièmement, il nous a généré un fichier XML. C'est la source que nous pouvons utiliser pour le Web Platreform Installer au lieu de le télécharger sur Internet.

clip_image008

Vu que je sais ce dont j'ai besoin, je vais aller direct à l'essentiel. Dans mon répertoire de téléchargement, j'ai un sous-répertoire pour les binaires d'installation. Il y en a qu'un qui m'intéresse : ‘WAP_PowershellAPI’.

clip_image009

A l'intérieur, on trouvera un simple package Windows Installer qu'il suffit d'installer.

clip_image010

Une fois installé, on peut constater qu'on dispose bien des modules d'administration et de configuration de Windows Azure Pack.

clip_image011

Quelques mise à jour à installer et on en a fini avec l'installation des prérequis. On va pouvoir revenir au nœud du problème.

 

Vous reprendrez bien un token pour la route?

Comment faire comprendre à PowerShell qu'il faudra utiliser ADFS comme fournisseur d'authentification. La réponse se trouve dans le module 'Windows Azure Pack Administration' et plus précisément dans la commande Get-MgmtsvcToken.

clip_image012

Pour en savoir plus, on va commencer par mettre à jour l'aide (update-help) avant de voir ce qu'on peut appendre sur cette commande.

clip_image013

Plusieurs choses ont retenu mon attention. Premièrement, cela permet bien de générer un token JSON consommable par Windows Azure Pack. Deuxièmement, il est bien prévu d'utiliser ADFS comme fournisseur d'identité. Bref, ça commence pas mal. C'est maintenant que cela se complique. J'ai eu beau chercher dans tous les sens, la commande fonctionnait bien lorsqu'exécutée depuis mon serveur Windows Azure Pack mais pas depuis mon poste d'administration. Après beaucoup de recherches, je suis tombé sur cette page de troubleshooting sécurité de Windows Azure Pack.

clip_image014

 

J’ai pas encore trouvé le pourquoi de la chose. Dès que j’ai trouvé, l’article sera updaté. En attendant, on va utiliser le workaround proposé par Microsoft. Le script a juste besoin d'être personnalisé avec quelques informations :

  • L'URL du serveur ADFS
  • Mon compte
  • Mon mot de passe

clip_image015

Si tout se passe bien, le script nous retourne un contenu tel que celui illustré ci-dessous :

clip_image016

Oui, j'ai caché quelques caractères Tire la langue. Il nous manque juste une chose :  à qui va-t-on s'adresser pour soumettre nos commandes PowerShell? réponse : au module AdminAPI de Windows Azure Pack.

Sur ma maquette actuelle, je n'ai pas encore personnalisé cette URL (c'est une erreur regrettableFou furieux). Cela veut dire que c'est toujours le certificat auto-signé qui est en place avec le nom de mon serveur Windows Azure Pack (Tiens un sujet prochain billet très fun). C'est un point dont il faudra prendre compte pour appeler nos commandes PowerShell. Commençons par quelque chose de simple, afficher la liste de nos locataires avec Get-MgmtSvcUser. Le truc, c'est de bien spécifier les paramètres -"AdminURI" et "Token" et de ne pas oublier qu’on à un certificat autosigné qui traine. Donc le paramètre ‘-DisableCertificateValidation’ est obligatoire.

clip_image017

Vu qu'on peut afficher la liste de nos locataires, on devrait aussi pouvoir en créer un nouveau avec la commande Add-MgmtSvcUser. Ça fonctionne toujours sur le même principe.

clip_image018

Pour vérifier, on peut aller faire un tour dans le portail et effectivement, on a bien notre nouveau locataire.

clip_image019

 

Pour ce dernier, j'ai eu beaucoup d'aide :

 

C’est la fin de cette série d’article sur la configuration d’ADFS pour les administrateurs de Windows Azure Pack. j’ai volontairement écourté cette série mais il reste tant à faire :

  • Configuration du module AdminAPI avec un véritable certificat
  • Mise en place d’un mécanisme d’authentification forte
  • Publication d’ l’ADFS avec un Web Application Proxy (l’autre WAP)

 

Plein de sujets pour de prochains articles. Alors Windows Azure Pack est il assez disruptif pour vous? Aller oust, les survivants sont libérés!

 

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 (6/7)

En soit, authentifier un utilisateur c'est pas un exploit mais ce serait plus simple de gérer des groupes et l'appartenance à un groupe. A première vue, on pourrait penser que ce sera très simple. Pourtant, il m'a fallu du temps pour comprendre mes erreurs. C'est suffisant pour moi pour y dédier un billet.

Si on se souvient bien du second cercle de l'enfer, on avait dit que le claims allait aussi contenir l'appartenance de l'utilisateur à tous les groupes dont il est membre. Donc on devrait pouvoir exploiter cette information pour autoriser l'accès au portail d'administration de Windows Azure Pack. Voyons ce que l'aide de la commande "Add-MgmgSvcAdminUser" peut nous apprendre sur ce sujet.

clip_image001

Visiblement, on est sur la bonne voie. A la vue des paramètres, on aura la même chaine de connexion à construire que dans le cinquième cercle de l'enfer. C'est donc du réchauffé jusque-là.

clip_image002

Mon groupe, c'est le 'WAP Admins' qui a pour seul et unique membre le compte 'WindowsAzurepack.lan\WApAdministrators'. Au passage, ce groupe n’est membre d’aucun groupe de domaine ou groupe local.

clip_image003

C'est un rappel mais le claims va contenir l'UPN de l'utilisateur. Il faut faire attention à ce détail car pour les groupes ça a toute son importance. On y reviendra bientôt. Voyons déjà ce qu'il y a dans les utilisateurs / groupes autorisés à accéder au portail d'administration de Windows Azure Pack.

clip_image004

Il n'y a que mon utilisateur nouvellement accrédité ainsi que le contenu historique. Ajoutons notre groupe avec la commande "Add-MgmgSvcAdminUser" en prenant soin d'utiliser la notation FQDN et non NETBIOS pour désigner le domaine.

clip_image005

Normalement, à ce stade, ça plante. Le groupe est bien référencé mais Windows Azure Pack refuse l'accès à mon utilisateur ‘WapAdministrator@WindowsAzurepack.lan’.

 

C'est en mettant en place les logs comme expliqué dans le billet précédent cinquième cercle de l'enfer que j'ai compris d’où venait mon erreur. La configuration du claims tel que documentée dans le billet second cercle de l'enfer indique bien d'inclure les groupes. Voyons ce qu'elle précisait.

clip_image006

Dans le billet, je précisais de mapper l'attribut "Token-groups – Qualified by Domain Name" dans le claims pour les groupes. C'était une erreur de ma part. Cet attribut désigne bien le groupe mais avec une notation NETBIOS pour le domaine. Pour utiliser une notation FQDN, il faut utiliser l'attribut "Token groups - Qualified by Long Domain name" Agressif. Comment perdre deux heures.

clip_image007

Une fois la contenu du claims change, ça fonctionne tout de suite mieux.

clip_image008

Si on voulait pouvoir utiliser les deux notations (DNS et FQDN), il aurait fallu écrire des règles de transformations pour peupler l'attribut 'group' pour réécrire la partie domaine. C'est faisable mais ça complique déjà pas mal les choses. On va essayer de rester simple, surtout qu'il reste encore le dernier cercle de l'enfer à explorer après.

Les observateurs assidus ont dû remarquer que notre utilisateur est membre d'un seul groupe Active Directory et que celui-ci donne uniquement le privilège d'administrer le service Windows Azure Pack et non la plateforme sous-jacente. Cela signifie que les membres de ce groupe n'ont absolument aucun privilège sur les serveurs de notre plateforme. Encore un point qui fait que Windows Azure Pack est disruptif dans son approche : Dissocier l'administration du service de la plateforme.

Vous êtes toujours là. Bien, il reste juste une salle de torture.

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" “Token groups - Qualified by Long Domain name” que nous allons positionner dans le claims "Group". C'est la seconde règle du Claims club.

FIXADFSCLAIMS

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 – Authentification ADFS Admin-Side : Les cercles de l’enfer (5/7)

C'est comme pour le poker, c'est l'heure du showdown. Show me your claims! C'est la séquence : ça tombe en marche ou pas. Si on essaie tout de suite de se connecter à mon portail d'administration (https://wapadmin.windowsazurepack.lan/) , ça commence bien, nous sommes redirigés vers ADFS qui va nous demander de nous authentifier et fournir un token. Dans l'illustration ci-dessous, on constate bien que c'est ADFS qui sollicite que nous nous authentifions.

clip_image001

Selon la configuration d'ADFS, l'expérience utilisateur peut être différente de celle illustrée ci-dessus. Dans mon cas, mon client est localisé sur le réseau interne (Donc Local Intranet du point de vue Internet Explorer). J'ai juste fait en sorte que mon navigateur ne soumette pas automatiquement mes credentials pour la démonstration. Du point de vue ADFS, c'est personnalisable.

clip_image002

Pourtant au final, ça n'a pas l'air de fonctionner. Dans la cinématique on aura constaté la redirection vers notre serveur "adfs.windowsazurepack.lan" puis le retour vers le portail. Il y a bien eu authentification mais il est clairement indiqué que nous ne sommes pas autorisés.

clip_image003

Etrange, pourtant si on demande à WAP la liste des administrateurs de la plateforme, mon compte apparait bien dans la liste des utilisateurs accrédités à administrer la plateforme Windows Azure Pack.

clip_image004

Ce qu'il faut comprendre, c'est que par défaut, aucun utilisateur n'a accès au portail d'administration de Windows Azure Pack. ADFS a authentifié mon utilisateur, il ne l'a pas autorisé. Là, c'est Windows Azure Pack qui décide. C'est donc tout simplement que mon UPN n'est pas référencé. Corrigeons ce problème avec la commande "Add-MgmgSvcAdminUser"

clip_image005

Si on redemande la liste des exploitants de la plateforme, on constate bien une différence.

clip_image006

Maintenant ca se passe tout de suite mieux.

clip_image007

Note pour les buses intergalactiques comme moi

De temps en temps, on échoue à la dernière étape. Ça a été mon cas à ce stade. J'ai buté jusqu'à me souvenir que par défaut mon compte administrateur n'a pas d'UPN de configuré. Ceci corrigé, cela fonctionne tout de suite mieux. Ouvrir une session avec un UPN, c'est pas un exploit, à moins de prouver qu'il y a bien eu authentification via ADFS.

 

Un coup de bluff?

On pourrait penser à un coup de bluff. Pour cela, on va revenir en arrière au niveau ADFS. Nous avions bien prévu de journaliser les évènements en relation avec notre serveur ADFS.

clip_image008

Il y a juste que si on prend le temps de lire la petite note en bas de l'interface, il faut encore faut-il pouvoir suivre l'activité générée par notre serveur ADFS du point de vue du système d'exploitation. Pour rappel, ADFS fonctionne dans le contexte dans un compte de service de type Group Managed Service Accounts (GMSA). Dans une installation par défaut d'ADFS, il est bien prévu que le compte de service d'ADFS puisse générer des évènements de sécurité.

clip_image009

C'est bien mais encore faut-il que la journalisation des évènements générés par des applications ait été activée. Un petit tour de magie avec "AuditPol.Exe" et le tour est joué.

clip_image010

Après un "GPUPDATE / Force", on est prêt pour le showdown des claims. Dans le journal de sécurité de mon serveur ADFS, on commence par un évènement 403 indiquant qu'il y a bien eu réception d'une requête au niveau ADFS.

clip_image011

Après qu'ADFS ait authentifié la demande, il a émis un jeton. On notera l'information 'Instance ID', ça va être notre fil d'Ariane.

clip_image012

Cet évènement nous mène à un évènement 501. On peut faire le lien entre les deux évènements avec l'information 'Instance ID'. Cet évènement nous révèle le contenu du claims : Showdown.

clip_image013

On trouvera plusieurs instances de l'évènement, car le claims contient beaucoup d'informations, dont la liste des groupes dont mon utilisateur est membre. C'est normal, nous l'avions demandé lors du second cercle de l'enfer.

Si vous avez bien suivi, on est au cinquième cercle de l'enfer. Ça veut dire qu'il nous en reste deux salles de tortures à traverser.

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 (4/7)

Dans le cercle précédent, on a traité la partie ADFS. Il nous reste à voir la partie Windows Azure Pack. Pour cela, un peu exploration avec un petit peu de PowerShell. La commande Get-MgmtsvcEndpoint permet de se rendre compte que tous les modules de Windows Azure Pack utilisent des Web Services pour communiquer entre eux. C'est pas nouveau. Par contre, si on se penche sur le cas du module "WindowsAuthSite", on voir bien qu'il cause "ADFS".

clip_image001

En fait, c'est un peu plus compliqué que cela. Nativement sans avoir mis en œuvre ADFS, Windows Azure Pack utilise déjà des tokens JSON. Pour le module WindowsAuthSite, il va exploiter l'annuaire Active Directory. Voyons si d'autres modules ne seraient pas en mesure d'utiliser des tokens JSON.

clip_image002

On retrouve notre portail d'administration de Windows Azure Pack. C'est logique, il doit être en mesure de rediriger les demandes d'accès non authentifiées ou dont le token n'est pas conforme à ce qu'il attend. A ce stade, il fait confiance au module WindowsAuthSite. Ils nous faut donc le reconfigurer pour soumettre les authentifications à notre ADFS. Si Windows Azure pack est un partenaire de confiance d'ADFS, encore faut-il que Windows Azure Pack sollicite ADFS les services d'ADFS. Pour cela nous devons reconfigurer le RelyingPartySettings pour que celui-ci ne sollicite plus le module WindowsAuthSite mais bien ADFS. En cherchant un peu dans le module PowerShell, on trouve la commande “Set-MgmtsvcrelyingPartySettings”. C'est maintenant que cela se complique et pas qu'un peu. Il nous faut construire une chaine de connexion. Toutes les informations de configuration de Windows Azure Pack sont stockées dans la base de données, allons voir ce qu'on peut y trouver avec la commande Get-MgmtsvcDefaultDatabase.

clip_image003

Y en a un qui nous intéresse tout de suite, c'est le "Microsoft.MgmtSvc.PortalConfigStore". Allons voir dans le SQL Server ce qu'on trouve dans cette base de données. Je suis allé direct à l'essentiel à savoir à quel fournisseur d'identité notre portail des exploitants de Windows Azure Pack doit faire confiance.

clip_image004

Dans la capture ci-dessus, mon ADFS est déjà en place. Maintenant qu'on sait où réaliser le changement, on pourrait penser qu'il n'y a qu'à référencer mon ADFS et bingo le tour est joué. Il suffit de regarder attentivement le contenu du paramètre pour s'apercevoir qu'on nous parle d'un peu plus qu'un simple FQDN. On cause Realm, Endpoint et certificat associé. Bref, c'est plutôt risqué de changer cela directement dans la base SQL. Par contre, il y a une nouvelle notion qui nous intéresse : le Endpoint. C'est lui qui désigne le fournisseur d'identité de Windows Azure Pack. Pour réaliser le changement, explorons de nouveau le module MgmtSvcConfig.

clip_image005

C'est la commande Set-MgmtSvcRelyingPartySettings qui va nous intéresser. Nous avons besoin des informations suivantes. Voyons un peu ce que l'aide PowerShell de cette commande peut nous apprendre (après avoir fait un Update-help).

clip_image006

C'est presque notre cas. Nous, c'est le portail d'administration de Windows Azure Pack. Donc pour le paramètre "Target", on sait que c'est "Admin". Le paramètre "MetaDataEndpoint", c'est lui qui désigne le partenaire de confiance. Il faut construire une chaine de caractère comprenant à la fois le FQDN de notre serveur ADFS mais aussi l'URL menant au fichier MetadataEndPoint.XML. Allons voir dans la console ADFS où se trouve ce fichier.

clip_image007

On peut donc déduire que le contenu du paramètre MetadataEndpoint sera https://adfs.Windowsazurepack.lan/FederationMetadata/2007-06/FederationMetadata.XML. Il ne nous reste plus qu'un paramètre à construire, le "ConnectionString". En regardant un peu l'aide de la commande Set-MgmtSvcRelyingPartySettings, on découvre que cela désigne une chaine de connexion SQL. L'aide nous donne même un exemple de construction. Pour la construire, j'ai besoin des éléments suivants :

  • Data Source : C'est le serveur SQL auquel on va se connecter. Pour moi, c'est “SQL.Windows AzurePack.Lan”
  • Initial Catalog : C'est la base de données dans laquelle on va réaliser les modifications : “Microsoft.MgmtSvc.PortalConfigStore”
  • User : Le compte SQL avec lequel on va se connecter pour réaliser la mise à jour (je rappelle que notre SQL est configuré pour supporter l'authentification SQL et l'authentification Windows)
  • Password : Vous pensez quand même pas que j'allais révéler cette information.

On a tout ce qu'il nous faut. Je vais commencer par poser quelques variables avant de construire le chaine de connexion.

clip_image008

Maintenant, c'est David Coperfield ou Garcimore. Si tout se passe bien la commande Set-MgmtSvcRelyingPartySettings doit retourner un résultat tel qu'illustré ci-dessous :

clip_image009

Note : Ne pas oublier de redémarrer le site web du portail d'administration de Windows Azure Pack pour le forcer à prendre en compte le changement opéré. Pour ceux qui m'ont suivi jusqu'ici respect, vous n'êtes pas nombreux. Dites-vous que le plus dur est passé, reste à voir si ça tombe en marche.

 

Non, je ne suis pas méchant. Sadique? peut-être.

 

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

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–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

More Posts Next page »