Archives mensuelles : décembre 2014

Kit de survie Scripting Microsoft Azure IAAS

Nouvelle année qui arrive, nouvelles résolutions. Adapté au Geek que je suis, Azure est ma résolution de l’année, que ce soit le grand frère (Microsoft Azure) ou son petit frère (Windows Azure Pack). Pour l’un ou l’autre, on a toujours besoin du module PowerShell "Microsoft Azure". Lorsqu’on ne l’a pas sous la main, y a plusieurs moyens. Le problème, c’est qu’il est mis à jour régulièrement pour intégrer les nouvelles fonctionnalités et que loi de Murphy oblige, c’est à ce moment là qu’on aurait bien besoin de la dernière version et qu’on se trouve privé de connexion Internet qui poutre pour ne pas attendre. passons en revue les différentes possibilités :

  1. La section downloads de Microsoft Azure
  2. Le GITHUB Microsoft Azure
  3. La solution du Geek
  4. La solution du Geek fainéant

Le premier choix est sympa mais un peu lourd. Au moment où j’avais besoin de l’installer j’étais dans une gare SNCF avec une connexion 3G asthmatique (loi de Murphy!). Si j’avais essayé avec la machine virtuelle Windows 7 que j’avais sous la main, je pense que j’y aurait passé beaucoup de temps, le coup à louper son train. En plus, je ne voulais faire que du IAAS, pourquoi aurais-je besoin d’avoir les outils de développement? Un simple ISE PowerShell est c’est partit.

Le second choix était jusqu’à peu ma solution. On y trouve directement le package MSI à installer, parfait pour installer sur ma machine virtuelle. Sauf que dans mon cas, ma machine virtuelle va certainement nécessiter quelques prérequis avant installation vu que c’est un template de Windows 7 qui trainait sur mon portable. Le Geek que je suis ne peut donc pas jouer avec les dernières features de Microsoft Azure. Un Geek sans nouveau jouet, c’est un Geek en manque, surtout à l’approche de Noël. C’est dangereux un Geek en manque.

Mon train étant annoncé en retard, j’ai donc décidé d’explorer une troisième voie, celle du Geek. Pour ceux qui ont osé entrer dans la salle des tortures de Windows Azure Pack, ils ont découvert que le Web Plateform Installer pouvait être utilisé de manière plus intelligente. L’interface graphique se contente juste d’utiliser un fichier XML. Donc on doit pouvoir exploiter cette liste avec la commande "WEBPICMD.EXE /List /ListOption:Available" comme illustré ci-dessous :

clip_image001

 

Donc si on connait le nom du package que l’on veut installer (WindowsAzurePowershellOnly dans mon cas), on peut aller direct à l’essentiel avec la commande "Webpicmd.exe /offline /Products:"WindowsAzurePowerShellOnly" /Path:"F:\Sources".

clip_image002

 

Ce qui est bien, c’est qu’il va aussi télécharger les packages dépendant. Pour certains d’entre eux on ne comprend pas trop ce qu’ils ont de dépendant avec le package demandé mais pour d’autres ça va me sauver la vie vu que mon template de machine virtuelle Windows 7 est un peu ancien. Par contre, il a quand même été nécessaire de downloader 346Mo pour qu’enfin commence le téléchargement de mon package de 13Mo. Bref, c’est bien pour se constituer un kit de survie mais pas optimum quand on est dans l’urgence (Finalement le train serait à l’heure).

clip_image003

Il nous reste donc la quatrième solution, celle du Geek fainéant, à savoir de se créer une machine virtuelle dans Azure depuis le portail et de reproduire la méthode du Geek directement depuis Microsoft Azure. La plus de problème de download, ma machine virtuelle de développement est toujours à portée de main. C’est maintenant ma nouvelle méthode.

Avec un Share SMB créé avec Azure File, je peux facilement récupérer mes scripts et continuer à scripter en attendant mon train. A moi les joies du scripting Azure dans le TER, à scripter entre les gares et lancer les déploiements lors des nombreux arrêts.

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

Salle de torture "Cœur de Windows Azure Pack" (suite)

Il faut battre le fer quand il est chaud et torturer quand la chair est encore tendre. Dans la précédente salle de torture, nous avons traité uniquement les modules privé de Windows Azure Pack. Il nous reste encore les modules publics isolés sur notre second serveur Windows Azure Pack. Un petit rappel s’impose.

clip_image001

Va vous reviens? Bien, voyons ce qui nous attend coté certificats :

clip_image002

C’est déjà bien moins fourni. La séance de torture sera donc plus courte puisque seulement trois Web Services sont au programme :

  • AuthSite
  • TenantPublicAPI
  • TenantSite

Ce ne sont pas des inconnus pour nous. Coté zone DNS, ils dépendront de la zone DNS publique "Windowsazurepack.fr". Pour les mêmes raisons que dans le billet précédent, il nous faut aussi remplacer les ports de publication par défaut par des ports normalisés (TCP 443). Cela impliquera donc de répartir les Web Services sur différentes adresses IP. Le tableau ci-dessous référence les transformations que nous allons faire subir à nos Web Services.

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

AuthSite https://localhost:30071 192.168.5.106 https://TenantAuthSite.windowsazurepack.fr:443
TenantPublicAPI https://localhost:30006 192.168.5.107 https://tenantpublicapi.windowsazurepack.fr:443
TenantSite https://localhost:300081 192.168.5.105 https://tenantportal.windowsazurepack.Fr:443

 

Il reste quand même pas mal de travail. Cette séance se découpera en deux parties :

  • La partie émergée de l’iceberg avec le portail des locataires et le site web d’authentification
  • La partie submergée de l’iceberg avec la partie publique de l’API des locataires

 

La partie émergée de l’Iceberg

Pour les modules publics, il faut tenir compte de l’expérience utilisateur de nos futurs locataires. La première chose qu’ils verront, c’est leur portail. On va donc personnaliser URL et le port pour qu’ils puissent utiliser ‘https://tenantportal.windowsazurepack.fr‘. Pour les détails plus complet, voir le billet Personnalisation des URL de Windows Azure Pack. Jusqu’ici on est en terrain connu, ça fait que chatouiller. Normal, on fait que commencer.

clip_image003

 

Note : Pour être pris en compte, il est nécessaire de redémarrer le site web.

Comme pour le portail d’administration, il y a un web service chargé d’authentifier les utilisateurs se connectant au portail des locataires. Dans IIS, c’est le site web "MgmtSvc-AuthSite" qui utilise ASP.NET Membership comme fournisseur d’authentification. Pour faire simple, derrière, le fournisseur d’authentification sera la base de données SQL Server de Windows Azure Pack.

Vu que c’était trop simple, j’ai décidé de corser un peu les choses et introduit quelques changements. Premier point, j’utilise un FQDN distinct de celui du portail des locataires. Ça permet d’introduire plus tard une séparation entre le portail des locataires et le Web Service en charge de l’authentification. C’est bon pour la montée en charge. Pour l’instant, les deux sont sur le même hôte mais qui sait, si le succès est au rendez-vous, il faudra bien être prêt à tenir la charge. Pour améliorer l’expérience utilisateur, j’ai retenu de binder le Web Service sur le port 443, comme le portail. Pour éviter les conflits au niveau IIS (et de devoir utiliser Server Name Indication (SNI)), j’ai donc introduit une nouvelle adresse IP sur mon serveur Windows Azure Pack Public.

clip_image004

Certes SNI a ses avantages mais aussi ses inconvénients :

J’ai toujours votre attention? Bien. On va commencer par quelques sujets simples : Reconfigurer l’URL du portail des locataires de Windows Azure Pack. L’objectif est de présenter "https://tenantportal.windowsazurepack.fr" à nos futurs locataires et de se préparer à la haute disponibilité.

Get-MgmtsvcFqdn -Namespace "TenantSite" -Server "SQL01.WindowsAzurepack.Lan"

Set-MgmtSvcFqdn -NameSpace "TenantSite" -FullyQualifiedDomainName "Tenantportal.Windowsazurepack.Fr" -port 443 -Server "SQL01.Windowsazurepack.lan"

clip_image005

Après le portail, le site d’authentification associé. C’est le même principe mais avec le FQDN ‘https://tenantAuthSite.WindowsAzurepack.fr‘. C’est vers lui que les demandes d’authentification vont être redirigées sur le port 443. C’est plus user-friendly.

Get-MgmtSvcFqdn -Namespace "AuthSite" -Server "SQL01.WindowsAzurePack.lan"

Set-MgmtSvcFqdn -Namespace "AuthSite" -FullyQualifiedDomainName "Tenantauthsite.windowsazurepack.fr" -port 443 -Server "SQL01.WindowsAzurePack.lan"

clip_image006

Les FQDN posés, on peut maintenant référencer le ‘https://tenantAuthSite.WindowsAzurepack.fr‘ comme URL pour le fournisseur d’identité. C’est une information que nous devrons référencer dans la base de données. On va donc créer une variable pour stocker le ‘connectionstring’ de notre base SQL ainsi qu’une autre variable qui référence le FQDN du partenaire de confiance vers lequel la demande d’authentification va être redirigée.

$Connectionstring = "Data Source=SQL01.Windowsazurepack.lan;User ID=SA;Password=*************"

$federationmetadata = "https://tenantauthsite.Windowsazurepack.fr/federationmetadata/2007-06/federationmetadata.xml"

Get-MgmtSvcRelyingPartySettings -Target "Tenant" -Server "SQL01.WindowsAzurepack.lan" | Format-List

Set-MgmtSvcRelyingPartySettings -Target "Tenant" -MetadataEndpoint $federationmetadata -ConnectionString $Connectionstring

clip_image007

Comme pour le portail d’administration, si on est redirigé pour authentification, il faudra bien revenir au portail et présenter le claims à consommer. Pour cela on doit l’indiquer à notre fournisseur d’authentification. Dans l’état actuel de notre plateforme c’est le ASP.NET Membership. Faut juste savoir à quelle URL on va rediriger.

$Federationmetadata = "https://tenantportal.windowsazurepack.fr/Federationmetadata/2007-06/federationmetadata.Xml"

Get-MgmtSvcIdentityProviderSettings -Target "Membership" -Server "SQL01.Windowsazurepack.lan"

Set-MgmtSvcIdentityProviderSettings -Target "Membership" -MetadataEndpoint $Federationmetadata -ConnectionString $Connectionstring

clip_image008

A ce stade, le portail doit être accessible. Certes, il n’y a pas encore de locataire mais on peut déjà tester la fonction "Sign-up" pour être un early-adopter:)

clip_image009

Dans la configuration actuelle de Windows Azure Pack, rien n’interdit à un utilisateur de créer son propre compte (on avait déjà vu que c’était possible). Par contre, notre installation n’inclus aucun "ressource provider" et encore moins de "plan" auquel l’utilisateur peut s’abonner. Le portail est bien opérationnel mais y a rien à consommer. Aller circulez, y a plus rien à voir en surface.

clip_image010

 

La partie submergée de l’iceberg

Comme vu dans le billet Windows Azure Pack–Les APIs publiques des locataires, le portail, ce n’est que la surface d’un service cloud digne de ce nom. En dessous, on a des API que nos locataires peuvent accéder pour exploiter les ressources mises à disposition. La première chose que nos futurs locataires vont voir, c’est le la partie publique du TenantAPI disponible sur le serveur public de Windows Azure Pack. Encore un certificat auto-signé à remplacer dans IIS.

clip_image011

 

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

Maintenant, on commence à le savoir, changer l’information dans IIS, c’est bien mais si on ne la change pas aussi dans la base de données de Windows Azure Pack, on va pas aller bien loin. Donc acte.

Get-MgmtSvcFqdn -Namespace ‘TenantPublicAPI’ -ConnectionString $ConnectionString | Format-Table -AutoSize

Set-MgmtSvcFqdn -Namespace ‘TenantPublicAPI’ -ConnectionString $ConnectionString -FQDN "tenantpublicapi.windowsazurepack.fr" -Port 443

clip_image012

Tout comme pour le module TenantAPI, il faut corriger le paramètre DisableSSLCertvalidation. Comme l’indique le mode Verbose de la commande Get-MgmtsvcSetting, l’opération consiste à ajouter un paramètre dans le fichier Web.Config du site web.

Get-MgmtSvcSetting -namespace "TenantPublicAPI" | Format-Table

Set-MgmtSvcSetting -namespace "TenantPublicAPI" -Name "DisableSslCertValidation" -Value False -Verbose

clip_image013

 

Si tout se passe bien, l’API publique des locataires est accessible via l’url ‘https://tenantpublicapi.windowsazurepack.fr‘. Le dire c’est bien mais le prouver c’est mieux. On avait déjà abordé le sujet dans le billet "Windows Azure Pack–Les APIs publiques des locataires".

Cependant, on doit interrompre la séance de torture. Dans cette installation, nous n’avons pas encore abordé le sujet des "Resources providers". Or sans eux, pas de ressources à proposer dans un “plan” auquel le locataire pourrait souscrire. Pour valider que cela fonctionne bien, il faudra mettre en œuvre un premier Resource Provider". Ça tombe bien, ce sera le sujet de notre prochaine séance de torture.

 

Vous pensiez sérieusement en avoir fini? Mais c’était que l’échauffement.

 

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

Salle de torture "Cœur de Windows Azure Pack"

Bien saignant, à feux vif et grillé juste ce qu’il faut à la fin mon cœur. Pour les assaisonnements, vous être libres. Bienvenu dans cette nouvelle salle de tortures (je sais toujours pas combien il y en aura, ça dépend du bourreau). Les certificats, Web Services et commandes PowerShell obscures vous ont manquées. Ça tombe bien, on a quelques nouveautés à vous faire tester.

Pour ce billet, j’ai déjà beaucoup de matières dans les billets suivants :

On va donc aller à l’essentiel (double séance torture pour les néophytes) mais aussi quelques nouveautés pour torturer les plus aguerris. Entrez, le bourreau vous attend, on le fait plus attendre.

 

Quelle AC pour mes certificats?

Une stratégie simpliste serait de se dire que seuls les modules publics de Windows Azure Pack sont exposés, donc seuls eux ont besoin de certificats publics (délivrés par un AC reconnue de tous). C’est vrai. Mais alors peut-on n’utiliser que des certificats délivrés par une autorité de certification interne pour les modules "privilégiés" Windows Azure Pack.

La réponse est oui et non. A un moment, nos exploitants vont devoir se connecter sur la plateforme (Portail, API). Or ces parties peuvent être exposées sur Internet. C’est par exemple le cas, si on choisit de déployer son infrastructure chez un hébergeur pour en confier l’exploitation à un tiers. C’est tellement old-school de faire un VPN pour cela.

Pour cette raison et pour éviter les problèmes (et de nombreux nervous breakdown), tous les certificats que je vais mettre en œuvre seront donc des certificats publics. Vu le nombre de certificats, le choix du wildcard va vite s’imposer comme un choix économique. Cependant, dans le cadre de cette maquette "évoluée" nous ne retiendrons pas cette option, ce sera pour une autre séance de torture.

Après, juste un rappel sur les certificats wildcard : le jour où le certificat expire, y a intérêt à avoir fait le tour de la plateforme pour le remplacement. Sinon c’est fatal et en cascade.

Cette stratégie n’est pas parfaite. Une autre stratégie serait d’avoir un wildcard pour les usages publics et un autre pour les usages privés et de distinguer les deux zones DNS (public et privilégiée). C’est ce qu’on devrait faire dans un environnement de production.

 

FQDN & certificats

Dans le contexte de ma maquette, c’est facile, ce sera la zone DNS "WindowsAzurePack.Fr". Pour rappel, voilà les certificats auto-signés sur le serveur Windows Azure Pack situé en zone "privilégié".

clip_image001

 

On va pas tous les traiter. Pour certains, ça n’a pas grand intérêt. C’est par exemple le cas de celui utilisé pour le site de configuration initiale. On n’en a besoin qu’une seule fois et à la limite, on peut s’en passer car il est possible de réaliser la configuration initiale directement en PowerShell. Un certificat en moins, plus que dix à traiter. Donc autant de séances de tortures.

Beaucoup de certificats à remplacer pour normaliser les URL, jusque-là pas beaucoup de changements par rapport à ce qu’on a déjà vu. Par contre dans mes billets précédents, je me souciais pas trop des ports utilisés surtout lorsque ceux-ci n’étaient pas visible du point de vue des utilisateurs finaux. Cette fois, on n’a pas trop le choix, il faudra les normaliser. La raison, c’est que le module Web Application Proxy que nous allons utiliser ne peut publier que des flux HTTPS, uniquement sur le port standard. Conclusion, il faudra bien reconfigurer les ports des Web Services qui seront exposés sur Internet.

Ça va devenir un problème car si on a plusieurs web services écoutant sur une même adresse IP / Port (443 pour HTTPS), ça n’est possible que si on utilise la fonctionnalité Server Name indication de IIS. Or, je veux m’en passer (trop compliqué à gérer en mode Fallback). La seule solution est de répartir les Web Services sur plusieurs adresses IP. Le tableau ci-dessous résume les usages de certificats sur ma plateforme Windows Azure Pack améliorée et l’introduction des nouvelles adresses IP.

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

AdminAPI https://localhost:30004 192.168.4.102 https://adminapi.windowsazurepack.fr
AdminSite https://localhost:30091 192.168.4.100 https://adminportal.Windowsazurepack.Fr
Monitoring https://localhost:30020 192.168.4.100 https://localhost:30020
TenantAPI https://localhost:30005 192.168.4.100 https://tenantapi.windowsazurepack.fr:30005
Usage https://localhost:30022 192.168.4.100 https://localhost:30022
UsageCollector https://localhost:30024 192.168.4.100 https://localhost:30024
WebAppGallery https://localhost:30018 192.168.4.100 https://localhost:30018
WindowsAuthSite https://localhost:30072 192.168.4.101 https://windowsauthsite.windowsazurepack.Fr

Y a plus qu’à passer commande auprès de son fournisseur habituel. De préférence, avec l’option “Clé privée exportable”. Ca servira plus tard.

 

Cela amène quelques remarques :

  • Les modules Monitoring, Usage, Usage Collector et WebAppgallery, ce sera pour plus tard. Si on n’a pas de portail et d’API exposé, pas la peine de parler de consommation et de suivi des usages.
  • Le module de configuration de configuration de nous intéresse pas. On garde donc le certificat auto-signé.
  • Pour certains modules, vu qu’ils ne seront pas accessibles depuis l’extérieur (cas du TenantAPI), je me n’ai pas poussé le vice à reconfigurer FQDN et ports. Il faut qu’il en reste pour d’autres séances de tortures
  • De plus, la liste de mes certificats n’inclus pas encore les futurs usages exotiques tel que ADFS, MFA et autres boutades du genre. Pas de question? Ben on allume le barbecue et on commence par le cœur de Windows Azure Pack pour ce billet avec les modules "Privilégiés". ca tombe bien, les braises sont juste à point.

 

Bourreau fait ton office!

On va donc travailler sur le serveur WAPPRIV.WINDOWSAZUREPACL.LAN. Je vais rien inventer, juste reprendre la même démarche que pour le billet Personnalisation des URL de Windows Azure Pack. La logique étant identique, je ne m’attarderai que sur quelques points.

Changer le certificat du portail d’administration de Windows Azure Pack, c’est en premier lieu ajouter le nouveau certificat “adminportal.windowsazurepack.Fr” au niveau du binding IIS sur le site "mgmtsvc-Adminsite". Vu qu’il sera quand même exposé à nos exploitants, on va faire l’effort de personnaliser l’URL et le port.

clip_image002

 

Note : Pour être pris en compte, il est nécessaire de redémarrer le site web.

S’il y a un site web pour le portail, il y a forcément un web service qui gère l’authentification au portail d’administration de Windows Azure Pack. Contrairement au billet Personnalisation des URL de Windows Azure Pack, j’ai décidé qu’on allait personnaliser l’URL et le port. Motif? Torturer. Plus sérieusement c’est dans l’optique de la haute disponibilité, en attentant la mise en place d’ADFS pour le portail des exploitants de Windows Azure Pack.

clip_image003

 

Note : Pour être pris en compte, il est nécessaire de redémarrer le site web.

Un nouveau certificat, c’est donc aussi référencer le nouveau FQDN du Web Service dans la base de données de Windows Azure Pack. Par défaut, le portail d’administration pointe sur le nom de notre serveur privilégié.

Get-MgmtSvcFqdn -Namespace AdminSite -Server SQL01.windowsazurepack.lan | Format-Table -Property * -AutoSize

Get-Website -Name "Mgmtsvc-AdminSite" | Format-Table -AutoSize

Set-MgmtSvcFqdn -Namespace AdminSite -FullyQualifiedDomainName "adminportal.windowsazurepack.fr" -Port 443 -Server "SQL01.WindowsAzurePack.Lan"

clip_image004

 

Même principe pour le Web Service en charge de l’authentification pour le portail d’exploitation de Windows Azure Pack.

Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server sql01.windowsazurepack.lan

Set-MgmtSvcFqdn -Namespace WindowsAuthSite -FullyQualifiedDomainname "windowsauthSite.WindowsAzurePack.fr" – Port 443

clip_image005

 

Donc à ce stade, le portail de Windows Azure Pack est accessible à l’URL https://adminportal.Windowsazurepack.fr et https://WindowsAuthsite.WindowsAzurepack.fr pour le Web Service "WindowsAuthSite".

Prochaine étape gérer l’authentification à ce portail. Lorsqu’on se présente sans claims, on doit être redirigé vers un fournisseur d’authentification. A ce stade, le seul disponible pour notre portail d’administration, c’est celui par défaut : "WindowsAuthSite".

La seule subtilité par rapport au billet Personnalisation des URL de Windows Azure Pack, c’est que je ne redirige pas vers le nom réel du serveur mais le nom générique que j’ai créé. Ca permettra d’intégrer la haute disponibilité dans un proche avenir (la salle de torture est en cours de construction tout comme la formation des bourreaux). Donc je créé une "Connection string" permettant de me connecter à la base SQL Server pour référencer un MetadataEndpoint.

$ConnectionString = "Data Source=SQL01.windowsazurepack.lan;User ID=SA;Password=*************"

$metadataendpoint = "https://windowsauthsite.windowsazurepack.fr:443/FederationMetadata/2007-06/Federationmetadata.xml"

Get-MgmtSvcRelyingPartySettings -Target Admin -Server SQL01.windowsazurepack.lan | format-list

Set-MgmtSvcRelyingPartySettings -Target Admin -MetadataEndpoint $metadataendpoint -ConnectionString $connectionstring

clip_image006

 

Une fois authentifié par le Web Service "WindowsAuthSite", il faut retourner au portail. Qu’à cela ne tienne, on doit juste retourner à l’URL "https://adminportal.windowsazurepack.fr" pour que le portail exploite le claims mis à disposition de l’utilisateur.

$federationmetadata = "https://adminportal.windowsazurepack.fr/FederationMetadata/2007-06/FederationMetadata.Xml"

Get-MgmtSvcIdentityProviderSettings -Target Windows -Server SQL01.WindowsAzurepack.lan | Format-List

Set-MgmtSvcIdentityProviderSettings -Target Windows -MetadataEndpoint $federationmetadata -ConnectionString $connectionstring -DisableCertificateValidation

clip_image007

 

Normalement, à ce stade, le portail d’administration devrait répondre à l’URL "https://adminportal.windowsazurepack.fr".

clip_image008

 

Le portail, c’est bien mais faut pas oublier l’ADMINAPI qui se trouve en dessous. C’était un de mes oublis de mon billet Personnalisation des URL de Windows Azure Pack. Quitte à faire les choses bien, autant le faire jusqu’au bout de l’auto-flagellation et :

  • Remplacer le certificat auto-signé et le remplacer par "https://adminapi.windowsazurepack.fr".
  • Reconfigurer le port par défaut du Web Service pour utiliser 443 ou lieu de 30004
  • Et donc logiquement lui associer une adresse IP distincte vu qu’on a déjà des occupants pour 192.168.4.101 et 192.168.4.102

clip_image009

 

Note : Pour être pris en compte, il est nécessaire de redémarrer le site web.

Après, y a plus qu’à référencer la nouvelle URL du Web Service "AdminAPI" dans la base de données. je détaille plus, on y va au fer rouge direct.

Get-MgmtSvcFqdn -Namespace ADMINAPI -ConnectionString $ConnectionString | Format-Table -Autosize

Set-MgmtsvcFqdn -Namespace ADMINAPI -FQDN "adminapi.windowsazurepack.fr" -Port 443 -ConnectionString $ConnectionString

clip_image010

 

Vu qu’on touche à quelque chose qui se trouve au cœur de Windows Azure Pack, ce serait pas mal qu’on puisse vérifier que cela fonctionne toujours. Pour cela rien de plus simple que d’attaquer directement l’API avec la commande Get-MgmtSvcToken. Sauf qu’on avait vu que ça fonctionnait pas vraiment.

clip_image011

 

J’ai pas eu le temps de creuser beaucoup plus depuis ma série sur les sept cercles de l’enfer mais le problème semble se situer lors de la négociation de l’authentification. Il semble que selon la zone DNS on n’utilise pas la bonne méthode. A ma grande surprise, cela fonctionne sans avoir à tricher avec le paramètre "-DisableCertificatevalidation".

$Cred = Get-Credential

$Token = Get-MgmtSvcToken -Type Windows -AuthenticationSite "https://windowsauthsite.windowsazurepack.fr" -ClientRealm "http://azureServices/AdminSite" -User $Cred -DisableCertificateValidation

Get-MgmtSvcResourceProvider -AdminURI "https://adminapi.windowsazurepack.fr" -Token $token

clip_image012

 

Note : Les plus observateurs ont certainement remarqué que j’ai basculé sur un autre module PowerShell de Windows Azure Pack.

Pour finir sur cette partie, la commande Get-MgmtSvcResourceProvider utilisée nous révèle deux Web Services ignorés jusque-là. Ceux en relation avec la supervision et le Marketplace. Il faut les voir comme des plug-ins qui viennent se greffer sur la plateforme Windows Azure Pack pour l’étendre eu proposer de nouveaux services. On ira s’en occuper plus tard. Pour l’instant concentrons-nous sur le cœur de Windows Azure Pack.

D’un point de vue architecture, un locataire ne voit que le Web service "TenantPublicAPI" disponible sur le serveur public de Windows Azure Pack. Sur le serveur Windows Azure Pack situé en zone privilégiée, on a le Web Service "TenantAPI". C’est encore un certificat à remplacer dans IIS. Le web service n’étant pas exposé sur Internet, pas besoin de normaliser le port, on se contentera de l’URL.

clip_image013

 

Note : On n’oubliera pas de redémarrer le site Web pour que le binding soit actualisé.

C’est devenu une évidence, si on change le certificat dans IIS, il faut forcément aussi changer le FQDN référencé dans la base de données de Windows Azure Pack pour que les autres Web Services sachent comment le solliciter.

Get-MgmtSvcFqdn -Namespace "TenantAPI" -ConnectionString $ConnectionString | Format-Table -AutoSize

Set-MgmtSvcFqdn -Namespace "TenantAPI" -FQDN "tenantapi.windowsazurepack.fr" -ConnectionString $ConnectionString -Port 30005

clip_image014

 

C’est maintenant que cela redevient intéressant. Les Web Services “TenantAPI” et “TenantPublicAPI” ont une particularité. Par défaut ils acceptent les certificats auto-signés. On va s’occuper de ça. Comme l’indique le mode Verbose de la commande, l’opération consiste à ajouter un paramètre dans le fichier Web.Config du site web.

Get-MgmtSvcSetting -Namespace "TenantAPI" | Format-Table

Set-MgmtSvcSetting -Namespace "TenantAPI" -Name "DisableSslCertValidation" -Value False -Verbose

clip_image015

 

Facile me direz-vous, même pas mal ou alors juste un peu? Vous en redemandez? Pas de problème, la salle de torture suivante vous attendra prochainement. En attendant, vous pouvez souffler.

 

Le bourreau entretien les braises en attendant la suite.

 

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

Installation du cœur de Windows Azure Pack

On a posé les bases de l’architecture, entrons dans la salle de torture. Il faut commencer par construire un cœur solide. La montée en charge n’est pas encore au programme de ce billet mais on va tenter de faire ça bien pour que le moment venu, ce ne soit qu’une formalité ou presque. On va commencer par les formalités administratives.

Formalités administratives

Circulez, y a rien à voir sinon une belle ligne de commande Powershell à se coltiner. Au passage, il y a bien le DVD d’installation de Windows Server 2012 R2 dans mon lecteur de DVD pour permettre l’installation du Framework 3.5 (Enable .NET Framework 3.5 by using the Add Roles and Features Wizard)

Add-WindowsFeature FileAndStorage-Services,Storage-Services,Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Basic-Auth,Web-Url-Auth,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Ftp-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Scripting-Tools,NET-Framework-Features,NET-Framework-Core,NET-Framework-45-Features,NET-Framework-45-Core,NET-Framework-45-ASPNET,NET-WCF-Services45,NET-WCF-HTTP-Activation45,NET-WCF-TCP-PortSharing45,ManagementOdata,FS-SMB1,User-Interfaces-Infra,Server-Gui-Mgmt-Infra,Server-Gui-Shell,PowerShellRoot,PowerShell,PowerShell-V2,PowerShell-ISE,WAS,WAS-Process-Model,WAS-Config-APIs,WoW64-Support -source « d:\source\sxs\ »

clip_image001

 

Récupération des sources de Windows Azure Pack

Vu que ce sera le cœur de notre réseau, pas vraiment d’accès Internet ou alors le minimum vital. Pour cette raison, on va commencer par récupérer les sources d’installation avec le Web Plateform Installer. Dans le dernier cercle de l’enfer, on avait déjà expérimenté cette approche. Pour rappel, voilà ce que propose le WEBPICMD.EXE :

clip_image002

On a tout ce qu’il nous faut et on va lancer le téléchargement avec la ligne WEBPICMD-X64.EXE /Offline /products: »Wap_SingleMachineInstallation » /path: »c:\sources »

/xml:https://www.microsoft.com/web/webpi/5.0/WebproductList.xml

/log: »c:\temp\log.txt »

clip_image003

Pour rappel le fichier XML (dit Feed) sera utilisé ultérieurement pour réaliser les installations « offline ». Après un peu de temps, on arrive enfin à la fin des téléchargements.

clip_image004

Source : Troubleshooting Installation of Windows Azure Pack

 

Installation du cœur de Windows Azure Pack

Le Web Plateform Installer a téléchargé les packages en relation avec Windows Azure Pack. On en a même une liste. C’est celle-ci que nous utilisons comme « primary feed » pour réaliser l’installation du cœur de Windows Azure Pack.

clip_image005

Tous les packages en relation avec Windows Azure Pack sont référencés dans la section « Products ». L’interface nous indique bien que la liste des produits est issue de notre fichier XML offline.

clip_image006

C’est maintenant que nous faisons nos courses des modules à installer :

  • Windows Azure Pack Admin Site
  • Windows Azure Pack Authentication Site
  • Windows Azure Pack Admin API
  • Windows Azure Pack Tenant API
  • Windows Azure Pack PowerShell API
  • Windows Azure Pack Best Practice Analyzer

clip_image007

Nos modules sont en attente d’installation. l’interface ci-dessous permet de récupérer les éventuels modules complémentaires qui ont des dépendances avec nos modules. C’est par exemple le cas du portail d’administration de Cloud Cruiser (un bijoux).

clip_image008

Comme vu dans le billet Windows Azure Pack – Les updates de System Center, Windows Azure Pack est lié à la gamme System Center pour ses mises à jour. Au jour de l’écriture de ce billet, ce sera donc Update 4.

clip_image009

Note : Attention à bien désinstaller la KB2990942 avant d’installer le Rollup 4 for System Center 2012 R2 and Azure Pack (KB2992027). Il sera possible de réinstaller la KB2990942 après.

La mise en place initiale de nos modules est maintenant terminée.

clip_image010

A ce stade, notre cœur n’est pas encore vraiment opérationnel sans une configuration initiale.

clip_image011

 

Configuration initiale du cœur de Windows Azure Pack

La configuration initiale de Windows Azure Pack, c’est très simple : Qu’est-ce que tous ces composants vont bien avoir en commun? Une base de données SQL Server pour y stocker leurs informations respectives et au passage savoir comment localiser les autres modules. La seule particularité, c’est qu’on utilise une authentification SQL Server et non une authentification intégrée.

clip_image012

Pour être sûr que seuls des composants de Windows Azure Pack puisse accéder à la base de données SQL partagée, il y a une phrase secrète partagée par tous. Il faut la mettre de côté car sans elle, pas possible d’installer / réinstaller de nouveaux serveurs.

clip_image013

Une fois le cœur installé, on pourra constater que le portail d’administration est bien opérationnel.

clip_image014

Ca y est, ça pulse. Coté certificats, c’est moins pire qu’une installation mono-serveur avec tous les rôles installés sur un même serveur. On aura donc du travail. Heureusement on a déjà travaillé le sujet.

clip_image015

C’était juste une piqure de rappel. Pour l’instant on reste sur des choses accessibles. Il en sera de même pour le prochain billet. Mais ça pourra pas durer bien longtemps.

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