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

Quand Windows Azure Pack rencontre Web Application Proxy (WAP versus WAP)

Bienvenu dans le donjon. Remis de la dernière séance? Parfait, j'ai de nouveaux instruments de torture à essayer sur vous. Ils se nomment Subject Alternative Names, et Web Application Proxy. Ça vous tente? Entrez, le bourreau est à vous tout de suite. Après, ne vous inquiétez pas, il y a toujours les classiques de la maison : ADFS et Powershell en intraveineuse. Installez-vous, on va commencer.

Elle commence à avoir de la gueule notre plateforme Windows Azure Pack. Après une digression vers les "Resources Providers" pour prouver que notre installation distribuée tiens la route, revenons à des fondamentaux avec l'authentification via ADFS. C'est un sujet que j'avais déjà commencé à traiter avec la série de billets Windows Azure Pack – authentification ADFS Admin-Side : Les cercles de l’enfer :

Une mise en œuvre un peu rapide certes mais qui permettait de de poser les bases des mécanismes d'authentification. Dans le cadre de notre installation distribuée, nous allons remettre en place l'authentification des administrateurs de la plateforme avec ADFS, nous allons juste corser un peu les choses avec quelques digressions Powershell ici et là. On va introduire un certain nombre de changements :

  • Mieux sécuriser notre infrastructure ADFS en la publiant sur Internet avec un Web Application Proxy
  • Revoir le contenu des Claims pour limiter leur contenu

Nous nous focaliserons uniquement sur l'authentification des administrateurs de Windows Azure Pack. L'authentification des locataires fera l'objet d'une séance de torture spécifique.

 

Mise en place de l'infrastructure ADFS

Pour cela, nous mettons en place un serveur ADFS dans la zone réseau "Sécurité". Or notre portail d'administration qui va consommer les jetons d'authentification est lui en zone réseau "privilégiée".

clip_image001

 

Lors de la première série de billets, j'avais volontairement fait l'impasse sur l'utilisation des extensions Subject Alternative Names, cette fois on n'y coupe plus. Mon objectif, c'est de masquer le véritable nom de mon serveur ADFS. Y a juste une subtilité : Les autorités de certification publiques n'acceptent plus de référencer des FQDN internes tel que ".Local". C'est une pratique maintenant courante chez toutes les autorités de certification publiques tel que DigiCert.

Donc le certificat pour notre serveur ADFS est nécessairement obtenu auprès de notre infrastructure PKI interne. On utilisera un certificat public via le Web Application Proxy qui publiera notre infrastructure ADFS. Notre certificat interne doit impérativement référencer le FQDN interne et externe (donc public). Ma demande de certificat contient donc :

  • Le common name du serveur ADFS : adfs1.windowsazurepack.lan
  • Le DNS Name correspondant : adfs1.windowsazurepack.lan
  • Le DNS Name correspondant au nom DNS public sur Internet : adfs.windowsazurepack.fr

 

Vu qu'on utilise la PKI interne, on peut utiliser les interfaces "user-friendly" pour demander un certificat. J'ai un gabarit Web personnalisé pour le rendre exportable. Si demain j'ajoute d'autres serveurs ADFS à la ferme, il faudra avoir le même certificat sur tous.

clip_image002

 

Il faut juste pas oublier des références tous les FQDN dans les "Alternatives Names".

clip_image003

 

Pour pouvoir retrouver mon certificat, je positionne toujours un "Friendly Name".

clip_image004

 

Notre certificat est présent dans le magasin personnel du serveur. Avant d'aller plus loin, on va s'assurer que celui-ci contient bien les bonnes extensions.

$Cert = Get-ChildItem Cert:\Localmachine\My | Where {$_.Friendlyname -Match "ADFS1.WindowsAzurePack.Lan"}

$Cert

$Cert.Extensions

$Cert.Extensions | Where {$_.Oid.Friendlyname -Match "subject alternative name"}

($Cert.Extensions | Where {$_.Oid.Friendlyname -Match "subject alternative name"}).Format(1)

clip_image005

 

Vous reprendrez bien un peu de Powershell pour la mise en œuvre d'ADFS?

Dans le billet Windows Azure Pack – Authentificaction ADFS Admin-Side : Les cercles de l’enfer (1/7), je finissais en annonçant avoir été sympa car je n'avais pas poussé le vice de réaliser toute la configuration en Powershell. Non, je ne bluffe pas, c'est possible, j'ai été magnanime avec la demande de certificat, il est temps de redevenir sérieux / Powershell-Geek.

Avant de mettre en œuvre notre ADFS, je sais d'avance que je vais avoir besoin d'un compte de service. Vu que je suis sur une plateforme Windows Server 2012 R2, je vais utiliser un Group Managed Service Accounts (aussi nommé GMSA). Ça implique un peu de préparation avec la création d'une KDSRootKey avec la commande Add-KDSRootKey.

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Get-KDSRootKey

clip_image006

 

De là, nous pouvons commencer l'installation du rôle ADFS

Add-WindowsFeature -Name ADFS-Federation -IncludeManagementTools

clip_image007

 

Après, y a quand même quelques mises à jour à prévoir pour ADFS. Dans ma To-do list, j'ai toujours les suivants sur ADFS :

 

Une fois ces mises à jour installées, on peut mettre en place le premier serveur de ferme ADFS. Celui-ci sera configuré pour :

  • Utiliser le certificat que nous avons obtenu (ça servait aussi à ça de vérifier les extensions en Powershell, …)
  • Référencer le nom adfs.windowsazurepack.fr comme nom de service de fédération
  • Créer et utiliser le compte GMSA qui sera dédié à ADFS
  • Utiliser une base de données SQL Server sur un serveur tiers

Install-AdfsFarm -CertificateThumbprint:$cert.Thumbprint -FederationServiceDisplayName:"ADFS Windows Azure Pack" -FederationServiceName:"adfs.windowsazurepack.fr" -GroupServiceAccountIdentifier:"WAP\ADFS_GMSA`$" -SQLConnectionString:"Data Source=SQL01.WindowsAzurepack.lan;Initial Catalog=ADFSConfiguration;Integrated Security=True;Min Pool Size=20"

clip_image008

 

Pour rappel ADFS dispose du privilège "Generate security Audits", il saura donc produire des évènements de sécurité.

clip_image009

 

Générer des évènements dans le journal de sécurité, c'est bien mais par défaut, les évènements ADFS liés aux authentifications elles-mêmes ne sont pas auditées. Rien d'insurmontable, trois lignes de Powershell et c'est tout bon.

(Get-AdfsProperties).LogLevel

Set-AdfsProperties -LogLevel $((Get-AdfsProperties).LogLevel + "SuccessAudits" + "FailureAudits")

(Get-AdfsProperties).LogLevel

clip_image010

 

Manque plus que de configurer le journal "Application Generated".

AuditPol.Exe /Get /Subcategory:"Application Generated"

AuditPol.Exe /Set /Subcategory:"Application Generated" /Success:Enable /Failure:Enable

AuditPol.Exe /Get /Subcategory:"Application Generated"

clip_image011

 

Notre serveur ADFS est prêt à être configuré. Il est raccordé au domaine "windowsazurepack.lan", donc reconnait ce domaine comme "Claims Provider trust". Ça tombe bien, nos exploitants disposent de comptes dans ce domaine. On sait donc avec quelle source notre serveur ADFS doit construire le jeton d'accès, reste maintenant à définir ce qu'il doit contenir. Le portail d'administration de Windows Azure Pack a des exigences quant au contenu des jetons d'accès.

 

Mise en place du Relying-Parties dans ADFS

Pour ceux qui n'ont pas suivi l'aventure, lorsque notre administrateur va tenter de se connecter au portail https://adminportal.Windowsazurepack.Fr et qu'il se présente sans claims exploitable à présenter, on va poliment le rediriger vers notre serveur ADFS https://adfs.Windowsazurepack.Fr pour qu'il s'authentifie et obtienne un jeton d'accès. Or pour construire un jeton, il faut que le demandeur (le portail d'administration Windows Aure Pack) exprime ses exigences Celles-ci sont exprimées sous la forme d'un fichier XML librement accessible.

clip_image012

 

Le seul claim obligatoire attendu, c'est un UPN. Après rien n'interdit d'en passer plus. Dans ADFS, cela correspond à déclarer un Relying-Party. Dès lors qu'on a cette URL, on peut facilement créer le Relying-Party pour notre portail d'administration avec la commande Powershell Add-ADFSRelyingPartyTrust.

Add-ADFSRelyingPartyTrust -Name "Windows Azure Pack Administration portal" -MetadataURL "https://adminportal.windowsazurepack.Fr/federationmetadata/2007-06/federationmetadata.xml" -EnableJWT $True -AutoUpdateEnabled $True -MonitoringEnabled $True

Get-AdfsRelyingPartyTrust -Name "Windows Azure Pack Administration portal"

clip_image013

 

Pour construire le jeton, c'est une autre histoire. Est-ce qu'il est possible de le faire en Powershell? Oui mais c'est pas intéressant tout de suite, les braises ne sont pas encore assez chaudes, … Notre jeton doit au moins besoin contenir deux informations. La première étant l'UPN de l'utilisateur. Pour nos exploitants, cette information sera extraite de l'annuaire Active Directory windowsazurepack.lan de ma maquette et on la placera sans aucune modification dans l'attribut UPN. On utilisera donc une règle "Send LDAP Attribute as Claims".

clip_image014

 

Une règle tout à fait basique, rien de bien particulier.

clip_image015

 

On va commencer par revenir sur l'UPN avec une règle de type "Pass Throught or Filter an Incoming Claim" pour imposer nos conditions. Appliqué aux UPN, cela permet de s'assurer que l'UPN passé est bien celui qui sera attendu au niveau Windows Azure Pack.

clip_image016

 

Pour les groupes, je voulais que le jeton généré ne contienne que le groupe autorisant l'accès au portail d'administration de Windows Azure Pack. Ce sera donc une règle "Send Group membership as a claim".

clip_image017

 

Et ce sera très sélect. Pas membre du groupe AD, alors pas d'attribut group configuré dans le jeton, donc jeté dehors par le portail.

clip_image018

 

Au final, nous avons les trois "Issuance Transform Rules" suivantes pour notre Relying Party.

clip_image019

 

Prochaine étape, il faut exposer notre ADFS vers la zone réseau publique. C'est maintenant que Windows Azure Pack rencontrer Web Application Proxy. WAP versus WAP.

 

Publication ADFS avec Web Application Proxy

J'ai donc ajouté un serveur Web Application Proxy dans la zone réseau publique.

clip_image020

 

C'est lui qui portera le certificat public pour le FQDN ADFS.windowsazurepack.fr. Si on voulait aussi utiliser WAP pour publier les deux portails, un certificat wildcard aurait été mieux. j'y reviendrais plus tard. Commençons par installer le rôle Web Application Proxy.

clip_image021

 

Une fois installé, on a accès à la "Remote Access Management Console", celle qui est partagée avec DirectAccess. En même temps, l'équipe en charge de WAP sont des anciens d'UAG, …

clip_image022

 

Pour Windows Azure Pack, le Web Application Proxy va jouer le rôle de proxy pour notre infrastructure ADFS. C'est sa fonction première pour nous.

clip_image023

 

Cela implique qu'on lui désigne notre infrastructure ADFS. Attention, il faudra référencer le SAN inscrit dans notre certificat. Notre serveur Web Application Proxy devra disposer du niveau de privilège Administrators sur les serveurs composant notre infrastructure ADFS interne. Donc une petite mise à jour du fichier host du serveur va s'imposer. Sinon, on va partir en boucle.

clip_image024

 

A l'extérieur, notre WAP (Web Application Proxy) va se présenter avec le certificat public que nous avons préalablement installé dans le magasin personnel de notre serveur.

clip_image025

 

OK, on aurait pu aussi le faire en Powershell. Ce sera pour une prochaine fois.

clip_image026

 

C'est fini pour la configuration du Web Application Proxy.

clip_image027

 

C'est tout pour la partie ADFS. Elle est maintenant exposée sur Internet. Pour la publication du portail, je vais l'impasse, pour l'instant. On y reviendra plus tard car il n'y a pas que le portail à exposer, il y a aussi les API d'administration.

 

Déclaration du Relying Party dans Windows Azure Pack

Dans l'état actuel de note plateforme, le portail d'administration http://adminportal.windowsazurepack.Fr sollicite toujours le fournisseur d'authentification par défaut (Mgmtsvc-WindowsAuthSite). Donc logiquement, on devrait pouvoir remplacer un fournisseur par un autre. On notera que je référence notre ADFS avec son futur nom public et non le nom FQDN du serveur Windows sur lequel le rôle est installé (sinon ça sert à quoi que le SAN dans tout ça?).Après avoir posé un peu de contexte, il ne reste plus qu'à déclarer le nouveau Relying Party avec la commande Set-MgmtSvcRelyingPartySettings.

Import-module MgmtSvcConfig

$ADFS = "ADFS.WINDOWSAZUREPACK.FR"

$DBServer = "SQL01.WINDOWSAZUREPACK.LAN"

$DBPassword = "********"

$MetadataEndpoint = "https://$ADFS/FederationMetadata/2007-06/FederationMetadata.xml"

$PortalConfigStoreConnectionString = [String]::Format('Data Source={0};Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=SA;Password={1}',$DBServer, $DBPassword)

Set-MgmtSvcRelyingPartySettings -Target Admin -ConnectionString $PortalConfigStoreConnectionString -MetadataEndpoint $MetadataEndpoint

Import-Module WebAdministration

Get-website -Name "MgmtSvc-AdminSite" | Stop-Website

Get-website -Name "MgmtSvc-AdminSite" | Start-Website

clip_image028

 

Comme notre administrateur va s'authentifier avec son UPN et non plus la notation NETBIOS, on peut déjà faire le ménage dans les utilisateurs autorisés et positionner uniquement le groupe "WAP\WAP_Admins" comme groupe autorisé pour accéder au portail d'administration de Windows Azure Pack.

Import-Module MgmtsvcConfig

$DBServer = "SQL01.Windowsazurepack.lan"

Get-MgmtSvcAdminUser -Server $dbServer

Remove-MgmtSvcAdminUser -Server $dbServer -principal "WAP\Administrator"

Add-MgmtSvcAdminUser -Principal "WAP\WAP_Admins" - Server $dbServer

Get-MgmtSvcAdminUser - Server $dbServer

Remove-MgmtSvcAdminUser -Server $dbServer -principal "WAPPRIV\Administrator"

Get-MgmtSvcAdminUser - Server $dbServer

clip_image029

 

Tout est en place pour pouvoir tester. Normalement, c'est maintenant adfs.windowsazurepack.fr qui demande à l'utilisateur de s'authentifier.

clip_image030

 

Au final, notre administrateur est bien authentifié et autorisé dans le portail d'administration de Windows Azure Pack (car il est membre du groupe), le tout avec un ADFS publié sur Internet avec un Web Application Proxy.

clip_image031

 

Les plus attentifs auront noté que nous n'avons fait que la moitié du chemin, il reste encore à vérifier que nous pouvons bien utiliser notre nouveau fournisseur d'authentification lorsque nous attaquons directement les API en Powershell. Je reviens pas sur le script Get-Token.PS1, c'est un sujet que vous avions déjà abordé dans une précédente séance de torture. Si on arrive à négocier un jeton et qu'on peut l'utiliser avec une commande Powershell liée à Windows Azure Pack, c'est gagné.

clip_image032

 

En utilisant le script "JWT Token Decode, on peut même voir le contenu de notre jeton filtré.

clip_image033

 

Pour les sceptiques, voilà à quoi ressemblerait le même jeton si on avait pas réalisé le filtrage au niveau ADFS. On est donc assuré que le jeton délivré ne pourra pas être détourné pour d'autres usages.

clip_image034

 

Il ne nous reste plus qu'à consommer notre jeton auprès de Windows Azure Pack.

Import-module MgmtsvcAdmin

$AdminAPIInfos = Get-MgmtsvcFQDN -Namespace AdminAPI -Server SQL01.WindowsAzurepack.Lan

$AdminAPIUrl = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

Get-MgmtSvcUser -AdminUri $AdminAPIUri -Token $Token

clip_image035

 

C'est opérationnel de bout en bout. C'est juste un peu plus compliqué que ce que je pensais lorsque j'ai commencé ce billet. Pour les locataires, ce sera une autre histoire / séance de torture.

 

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

Cloud Platform Integration Framework

Concevoir une infrastructure dans le cloud Microsoft Azure, c'est un peu disruptif. C'est beaucoup de technologies à assembler. On a un peu l'impression de jouer à Tetris mais en 3D. Rien que sur les aspects réseau, on peut y passer beaucoup de temps. Pour éviter qu'on perde trop de temps, Microsoft a mis à disposition un Cloud Platform Integration Framework qui regroupe un ensemble de documents présentant des "Design patterns" pour concevoir des architecture dans le cloud Microsoft Azure. Je recommande vivement la lecture du guide Hybride Networking pour commencer.

 

Bref que des lectures saines.

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

Premier service cloud avec Windows Azure Pack : SQL Server

Vous êtes remis de la séance de torture de la veille? Bien. On peut donc continuer avec les survivants.

Cette fois, on va mettre les doigts dans la prise et tester les nouveaux instruments de torture. Le "Resource Provider" le plus simple à mettre en œuvre c'est celui de SQL Server. Pour cette séance, plusieurs étapes :

  • Mise en œuvre du Resource provider SQL Server
  • Mise à disposition d'une ressource SQL Server
  • Consommation d'une ressource SQL Server
  • Suivi de l'usage de la ressource SQL Server
  • C'est l'heure de passer à la caisse

 

Mise en œuvre du Resource Provider SQL Server

Commençons par l'installer avec le Web Plateform Installer (C'est aussi possible en ligne de commande pour les plus téméraires). C'est le module "Windows Azure Pack :SQL Server extension". C'est sur le serveur "privilégié" de notre installation que cela se passe. Y a qu'à l'ajouter à la liste et demander l'installation.

clip_image001

 

Il n'a pas de prérequis particulier, la mise en œuvre devrait donc être simple. C'est pas le cas pour tous les "Resources Providers".

clip_image002

 

Toute installation d'un nouveau module de Windows Azure Pack implique qu'on repasse par le site web de configuration initiale que nous avons déjà souvent vu.

clip_image003

 

Vu que mes précédents composants utilisent le serveur SQL01.WindowsAzurepack.Lan, c'est logique de continuer avec lui. A noter que lors de la mise en œuvre d'un nouveau module de Windows Azure Pack, il est impératif de disposer de la pass-phrase de configuration. Sans elle, on ne peut pas accéder à la base de données de configuration.

clip_image004

 

Logiquement le site web de configuration comprend que certains modules sont déjà installés et configurés, il n'en reste donc que le petit nouveau à traiter.

clip_image005

 

Au final, on a un nouveau "Resource provider" installé. Le fun, c'est est même possible de réaliser cela en Powershell. Allez faire un tour dans le module "MgmtSvcConfig", y a tout ce qu'il faut si le courant alternatif vous tente.

clip_image006

 

Si on a un nouveau "Resource Provider", on a donc beaucoup de travail. Logiquement, on a un nouveau site web sur notre serveur "privilégié" nommé "MgmtSvc-SQLServer" pour lequel un certificat-auto signé a été associé. On va le reconfigurer pour utiliser l'URL https://adminapi.windowsazurepack.fr.

clip_image007

 

Et on a les Urls à corriger avec notre script RPUPDATE.PS1 que j'ai mis à jour pour prendre en charge ce "Resource Provider". C'est que maintenant, on met à disposition des ressources pour nos futurs utilisateurs. Il n'y a donc pas que les URL du portail d'administration et celui des locataires mais aussi une URL pour :

  • Le Usage Endpoint pour gérer la souscription des futurs locataires
  • Le "Notification Endpoint pour gérer l'utilisation des ressources et exposer ces données pour la facturation

RPUPDATE.PS1 -ResourceProviderName sqlservers -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image008

 

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web MgmtSQLServer.

Histoire de constater la différence, revoilà la liste de tous les endpoints exposés par chaque "Resource Provider" avec le petit nouveau. Vous reprendrez bien un shoot de Powershell en intra-veineuse?

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-List

clip_image009

Au passage, j'ai ajouté les url des UsageEndpoint et NotificationEndpoint car si notre nouveau "Resource Provider" propose des extensions dans le portail des administrateurs et des locataires pour consommer des services faut au moins annoncer la consommation des ressources et le suivi des usages pour établir la facturation. La mise en place technique est terminée proposons notre nouvelle ressource à nos futurs locataires.

 

Même pas mal? Bien, on continue.

 

Mise à disposition d'une ressource SQL Server

Dans notre portail d'administration, nous avons maintenant un nouveau nœud, normal, il y a bien une URL "AdminEndpoint" pour notre nouveau "Resource Provider". En conséquence, l'AdminAPI est capable d'étendre le portail d'administration. Nous allons simplement déclarer un serveur SQL utilisable pour proposer le service.

clip_image010

 

L'objectif de ce billet est de prouver que notre infrastructure Windows Azure Pack est bien opérationnelle, pas de délivrer du service en production. Pour cette raison, je vais réutiliser la base de données de mon installation de Windows Azure Pack. Dans un véritable déploiement, la recommandation serait d'utiliser des instances dédiées à cet usage, voire même des serveurs / clusters dédiés à cet usage. Pour cette démonstration, je fais l'impasse sur la haute disponibilité de ce service. Pour notre serveur, nous déclarons une capacité d'hébergement de 200Go. Ce sera la limite de consommation pour cette ressource.

clip_image011

 

Le service est maintenant disponible mais pas encore visible pour les locataires.

clip_image012

 

Pour que cette ressource puisse être accessible à nos futurs locataires, il faut que notre locataire puisse souscrire à un “hosting plan” qui propose notre ressource. Pour faire simple, voyons cela comme un abonnement qui va inclure un ou plusieurs types de ressources. Nous allons donc créer un "Hosting plan".

clip_image013

 

On va commencer par le nommer de manière explicite, c'est sous ce nom qu'il sera présenté à nos futurs locataires.

clip_image014

 

Et lui associer le seul type de ressource à notre disposition pour l'instant : SQL Server.

clip_image015

 

Une fois créé, il faut encore rendre ce "Hosting Plan" public de manière à ce que nos locataires puissent y souscrire.

clip_image016

Pour le fun on pense avoir MySQL mais, c'est une autre histoire et donc une autre séance de torture.

clip_image017

 

Si vous trouvez que c’était bien trop simple, sachez que tout ce qu’on vient de faire depuis le portail est faisable en Powershell. par contre, c’est une séance de torture en one to one avec le bourreau.

 

Consommation d'une ressource SQL Server

Le service est disponible pour notre locataire, celui-ci n'a plus qu'à souscrire au "Hosting Plan". Dans le portail des locataires, notre utilisateur n'a qu'à cliquer sur le lien "Add Plan" présent dans le nœud "My Accounts".

clip_image018

 

C'est le moment de vérité pour le "Resource Provider" UsageService. Si le "Hosting Plan" n'apparait pas, c'est certainement que le Resource Provider ne fonctionne pas. C’est précisément à ce stade que je perd beaucoup de participants dans de longues séances de debug de Web Services / Certificats, négociations SSL inachevées. Le devOps vous gâte, …

clip_image019

 

Une fois l'abonnement souscrit on peut basculer dans l'onglet "Subscriptions", notre locataire peut constater qu'il est bien abonné et peut même personnaliser le nom sous lequel il est référencé. A ce stade, si le Resource Provider "Monitoring" n'est pas opérationnel, notre locataire n'est pas en mesure d'utiliser son service. Il y a de grande chances que l'état soit "Out of Sync".

clip_image020

 

La souscription de l'abonnement s'étant bien déroulée, notre locataire peut venir consommer du service et créer sa première base de données.

clip_image021

 

L'utilisateur n'a pas besoin de savoir sur quel serveur / cluster SQL sera mis en œuvre sa base de données. La notion d'édition correspond à la notion de groupe que nous n'avons pas mis en œuvre. La seule contrainte, c'est que le nom de la base de données soit bien unique sur le serveur / cluster / groupe.

clip_image022

 

Pour que notre locataire puisse accéder à sa base de données, il faut juste un compte et un mot de passe. Charge à lui de fournit un compte et un mot de passe respectant les exigences de complexité.

clip_image023

 

Victoire, notre plateforme Windows Azure Pack vient de livrer son premier service à ses locataires. Champagne. La base de données provisionnée est directement utilisable pour nos locataires. Par défaut, le locataire ne peut souscrire qu'à un seul abonnement offrant une capacité fixe, c'est un choix par défaut. Pour augmenter les capacités, l'utilisateur devra souscrire à des "Add-ons".

clip_image024

 

Avec le boutons infos, le locataire peut récupérer toutes les informations pour utiliser son nouveau service. Ce n'est qu'à ce stade qu'il découvre le nom du serveur / cluster SQL qui héberge sa base de données.

clip_image025

 

Derrière, on retrouve bien la base de données de notre locataire.

clip_image026

 

Suivi de l'usage de la ressource SQL Server

Fournir un service c'est bien mais notre exploitant a besoin de suivre les usages pour :

  • Préparer le capacity planning de sa plateforme
  • Savoir si ses produits se vendent

 

Notre exploitant peut suivre la consommation des ressources mises à disposition avec la commande Powershell Get-MgmtSvcPlan. On a juste besoin d'un peu de contexte comme on a déjà vu :

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$Plan = Get-MgmtSvcPlan -AdminUri $AdminURI -Token $token

$Plan

$Plan.ServiceQuotas

clip_image027

 

Pour notre "Hosting Plan", on découvre que chaque locataire est limité à une seule souscription et que à ce moment, nous avons une souscription active pour notre service. Il y a bien un notion de cout mais elle n'est pas configurée. C'est un sujet sur lequel je reviendrais à la fin de ce billet. En explorant la propriété "ServiceQuotas" on découvre le "Resource Provider" mis à disposition par ce "Hosting Plan".

Voyons maintenant les choses du point de vue des souscriptions de nos utilisateurs. La commande Powershell Get-MgmtSvcSubscription va nous permettre d'explorer les souscriptions de tous nos utilisateurs.

$subscription = Get-MgmtSvcSubscription -AdminUri $AdminUri -Token $token

$subscription

$subscription.Services

clip_image028

 

On retrouve la souscription de notre utilisateur. En explorant la propriété "Services" on retrouve le "Resource Provider" impliqué dans cette souscription. Il ne nous reste plus qu'à mesurer son usage de cette ressource avec la commande Powershell Get-MgmtSvcSubscriptionUsage. On apprend que pour cette souscription, le locataire a créé une seule base de données, c'est peu. On peut clairement dire qu'il sous-utilise le service auquel il a souscrit puisque qu'il peut encore créer neuf bases de données dans la même souscription. C'est une bonne nouvelle pour nous exploitant car notre locataire consomme peu.

$usage = Get-MgmtSvcSubscriptionUsage -SubscriptionID $Subscription.SubscriptionID -AdminURI $AdminURI -Token $Token

$usage

$usage.usages

clip_image029

 

Dans le portail notre administrateur peut constater que son service est consommé (du point de vue de la souscription au "hosting plan"). Visiblement ça se vend bien.

clip_image030

 

Du point de vue de la ressource consommée, on constate bien la consommation d'un giga-octet sur les deux-cent giga-octets mis à disposition. C'est presque vrai, dans la réalité, vu que mon utilisateur n'a pas encore utilisé sa base de données, l'espace occupé est plutôt de cinq méga-octets.

clip_image031

 

Pour finir, on va explorer le module Powershell MgmtSvcSQLServer livré avec notre "Resource Provider".

Import-module MgmtsvcSQLServer

Get-command -module mgmtsvcSQLServer

clip_image032

 

On va demander les "metrics" d'usage du serveur SQL que nous avons mis à disposition. Vu que notre "Resource provider" permet de consommer des ressources, il est logique de remonter l'usage de la ressource. Le "Resource provider" UsageService" dispose d'un interface dans le Resource Provider SQL Server : Le UsageEndpoint. Ca y est, le lego commence à s'assembler, on approche de la délivrance. Encore un peu de Powershell pour identifier la ressource SQL dont nous voulons mesurer l'usage : Get-MgmtsvcSQLHostingServer, puis on peut demander les métrics pour notre ressource avec la commande Get-MgmtsvcSQLHostingServerMetric.

Get-MgmtsvcSQLHostingServer -AdminUri $AdminUri -token $token

$ServerID = (Get-MgmtsvcSQLHostingServer -AdminUri $AdminUri -Token $token).ServerID

$metrics = Get-MgmtsvcSQLHostingServermetric -Adminuri $adminUri -token $token -HostingServerID $ServerID

$metrics

clip_image033

 

Pour notre ressource SQL Server, nous avons deux metrics :

  • Le nombre de base de données (DatabaseCount) sur notre serveur
  • L'espace alloué aux bases de données sur notre serveur

Pour nos exploitant, ce n'est pas le nombre de bases de données qui importe, c'est le stockage que cela représente qui est important. Explorons un peu le second metric.

$DBUsageMetric = $Metrics | Where {$_.name -eq "TotalAllottedSpace"}

$DBUsageMetric

$DBUsageMetric.Payload

clip_image034

 

On a les niveaux minimum et maximum d'utilisation de la ressource sur ce serveur en particulier. Au vu des chiffres, on peut pas dire que notre serveur soit les plus utilisés. Pour le capacity planning, c'est bon à savoir. Par contre pour le Business, c'est pas forcément un service rentable. Tout service doit être rentable. C'est donc le moment pour parler gros-sous.

 

C'est l'heure de passer à la caisse

Le cloud, c'est pas que de la technique mais aussi du Business. En tant que fournisseur de services nous devons être en mesure de présenter la facture aux locataires. Jusqu'à maintenant, on n'a jamais parlé du coût du service mis à disposition. La raison est simple, c'est un autre "Resource Provider". Microsoft se contente de fournir les usages et les metrics associées, charge à nous de connecter une plateforme qui gèrera la facturation du service. Avec Windows Azure Pack, c'est CloudCruiser qui s'en charge.

clip_image035

Le choix de Microsoft peut sembler étrange mais lorsqu'on explore un peu la solution, on comprend que c'est une plateforme de facturation capable de prendre en charge aussi bien le "on premise" que toutes les plateformes de cloud du marché dont Windows Azure Pack. Il devient possible de facturer un même consommateur pour des ressources consommées sur différentes plateformes. Bel effort d'ouverture de Microsoft.

 

Conclusion

C'est la fin de cette séance de torture. Nous avons une plateforme Windows Azure Pack offrant maintenant un service cloud consommable par nos utilisateurs finaux. Pour ceux qui veulent en savoir plus sur le “Resource Provider” SQL Server, je vous recommande la lecture de ce billet : Automation–The New World of Tenant Provisioning with Windows Azure Pack (Part 5): Working with the SQL Server resource provider, and the ITIL dilemma. Attention, ce sera que du Powershell qui pique.

Pour finir, si cela vous intéresse de proposer SQL Server sous la forme d'un service IaaS, je recommande vivement la lecture de ce billet : Working with the Windows Azure Pack SQL Server Resource Provider : Dedicating a part of the SQL Server fabric to a specific tenant. Attention, ça pique grave, on rentre chez les DevOps.

 

Si vous lisez ces lignes, c’est que vous êtes arrivés au terme de cette séance de torture. C’est bien, très bien, vous n’êtes pas nombreux à être arrivé à ce niveau. Ca mériterait presque une certification ou un badge “Torturé par Simple”. Ne vous en vantez pas trop, SQL Server, c’est le “Resource Provider” le plus simple à mettre en œuvre, …

 

Welcome my Young WAP Padawan, you have so much to learn, …

 

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

Introduction aux Resources Providers de Windows Azure Pack

Depuis le début de cette longue séance de torture, on parle de cloud, donc de mise à disposition de ressources mutualisées accessibles en libre-service. Pourtant à part le portail, on ne voit pas grand-chose comme ressources mises à disposition. C'est normal, on n'a pas encore abordé le sujet des "Resources Providers". Windows Azure Pack est modulaire et extensible. Toute la richesse du produit se situe dans les "Ressources providers" mis à disposition par Microsoft et ses partenaires, voire ceux que l'on voudrait développer soit même. Pour cette séance de torture, on va se focaliser sur un ensemble dit "Core", essentiel au bon fonctionnement de Windows Azure Pack, bref plein de choses dites "sous la moquette". Commençons par voir ceux que nous avons à disposition avec un peu de Powershell. Avant d'en introduire de nouveaux, on va commencer par traiter ceux qu'on a sous la main avec la commande Get-MgmtSvcResourceProvider. Pour cela, quelques prérequis sont nécessaires.

Pour commencer on va utiliser le module Windows Azure Pack Administration (MgmtSvcAdmin) et non plus le module Windows Azure Pack Configuration (MgmtSvcConfig). Après, c'est un peu comme une recette de cuisine mais en Powershell car faut pas compter sur une quelconque interface graphique. Un soupçon de credential stocké dans un objet de type System.Security.SecureString puis un peu de get-MgmtsvcNamespace pour construire les URL de connexion pour le Web Service AdminAPI et le site web d'authentification des administrateurs, le tout exécuté dans la marmite du serveur "Privilégié". Avec tout-ça, j'ai pu négocier un token JSON que je vais pouvoir aller présenter auprès du Web Service AdminAPI. Normalement, jusque-là, c'est des révisions, à la limite ça pique un peu. Pour commencer, j'ai volontairement limité le contenu retourné par la commande Get-MgmtSvcResourceProvider, histoire de poser un peu le tableau.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$AllRPs | Select Name, DisplayName | Format-Table -AutoSize

clip_image001

Donc, il y a seulement trois "Ressources Providers" sur ma plateforme. C'est normal. Pour faire simple, disons que ces trois-là forment un noyau autour duquel viendront se greffer les suivants. Un "Resource Provider", c'est un peu plus que de simples extensions pour les portails des locataires et administrateurs. Les Virtual Machines, les Web Sites, bases SQL sont aussi des "Resources Providers". Ils viennent se greffer dans Windows Azure Pack pour apporter de nouvelles fonctionnalités. Certaines seront visibles dans les différents portails, d'autres non (cas de nos trois premiers). Pourtant tous vont devoir communiquer avec Windows Azure Pack pour :

  • Permettre aux administrateurs de gérer les ressources mises à disposition des locataires
  • Permettre à nos locataires de souscrire a des ressources et de suivre leur usage
  • Permettre à nos locataires de suivre les usages de ses ressources
  • Gérer la consommation des ressources par rapport aux quotas
  • Mettre à disposition les données de supervision aussi bien à l'exploitant qu'au locataire

Prenons un exemple concret avec le "Resource Provider" SQLSERVER que nous introduirons prochainement. Pour communiquer avec Windows Azure Pack, il va s'exposer sous un certain nombre d'URL nommées "Endpoint" :

  • Administrator Endpoint : C'est lui qui va recevoir les requêtes émises depuis l'API de gestion de Windows Azure Pack (AdminAPI). Lorsqu'un administrateur configure un plan (abonnement) pour proposer du SQL Server en PaaS à la souscription, derrière, le "Resource Provider" nommé SQLSERVER recevoir la demande sur ce "Endpoint". Pour faire simple, c'est ce que l'administrateur de Windows Azure Pack voit dans le portail lorsqu'il configure les ressources de type SQL Server".
  • Tenant Endpoint : C'est lui qui va traiter les requêtes en provenance du Tenant API (via le Tenant Public API) . Lorsqu'un utilisateur va vouloir souscrire à un plan contenant des ressources de type SQLSERVER, c'est lui qui va être à la manœuvre. Le Tenant Portal va demander via le Tenant Public API de souscrire à un abonnement via le Tenant API. Ce dernier va alors relayer la demande au "Resource Provider" SQL Server.
  • Notification Endpoint : C'est auprès de lui qu'on vient gérer la souscription (état, statuts des ressources) à une ressource donnée ainsi qu'assurer le suivi de sa consommation (quotas).
  • Usage Endpoint : Enfin, s'il y a suivi des usages, il y aura nécessairement exposition des données de facturation. A ce niveau, on parle de "metrics", pas encore de facturation. Pour parler de facturation, encore faut-il avoir positionné un prix sur la ressource mise à disposition.

Note : En réalité, il y en a un cinquième mais il ne nous intéresse pas pour le moment.

On parle de Web Services, allons voir un peu à quoi cela ressemble. J'ai conservé ma variable $AllRPs, j'ai juste besoin de détailler un peu le contenu des attributs AdminEndpoint et TenantEndpoint. Au passage, j'ai piqué l'astuce ci-dessous chez http://www.hyper-v.nu pour récupérer et formater les URL.

$AllRPs | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}} | Format-Table -AutoSize

clip_image002

Je me suis volontairement limité aux URL correspondant au AdminEndpoint et TenantEndpoint car c'est le sujet qui nous occupe pour cette séance de torture. Pour vous donner une idée voilà à quoi ressemble une installation de Windows Azure pack en mode (Next-Next-Next tout sur la même machine à la barbare). Ça promet quelques "nervous breakdown" à base de certificats et Web Services. Une séance de torture des plus habituelles nous attend donc.

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}},@{e={$_.HealthCheckEndpoint.ForwardingAddress}},@{e={$_.NotificationEndpoint.ForwardingAddress}}

clip_image003

Donc chaque "Resource provider" qui sera ajouté par la suite sur la plateforme viendra annoncer ses différentes URL.

Un "Resource Provider" comme celui de SQL Server que nous traiterons prochainement va donc venir se greffer sur nos premiers "Resources Providers". Ces premiers "Resources Providers" sont un peu un bus de communication pour gérer les usages, la souscription, la supervision et le Marketplace proposé à nos locataires. A ce stade, de la séance de torture, on peut déjà en déduire que :

  • Toute installation d'un nouveau "Resource Provider" implique qu'on viendra corriger les URL par défaut
  • Chaque "Resource Provider" étant représenté par un site web avec un certificat auto-signé associé, on sait ce qu'il adviendra.
  • Tous les "Resources providers" s'installent uniquement sur le serveur "Privilégié"

Les trois "Resources Providers" que nous avons sur notre plateforme sont essentiel au bon fonctionnement de Windows Azure Pack. Sans eux, les futurs "Resources Providers" que nous installerons ne fonctionneront pas. Pour faire simple, Ces "Resources Providers" serviront à :

  • Monitoring : Les administrateurs auront une vue consolidée du monitoring de toutes les ressources mises à disposition
  • Monitoring : Les locataires auront une vue consolidée du monitoring de toutes les ressources auxquelles il a souscrit
  • Usage Service : Les administrateurs pourront gérer les quotas associés à chaque "Resource Provider" et avoir une idée du capacité planning de la plateforme
  • Usage Service : les locataires pourront suivre la consommation des ressources qui ont été mises à sa disposition
  • Marketplace : Les locataires auront accès à un Marketplace

On va donc commencer par passer un peu de temps en leur compagnie et s'assurer qu'ils puissent fonctionner avec des nom DNS et de véritables certificats. De ce côté-là, Windows Azure pack, c'est un peu un service de torture à la demande :). Ce qui est bien, c'est que c'est très bien documenté chez Microsoft : Update FQDNs for Resource Providers. Je vais donc reprendre la méthodologie et expliquer un peu en détail.

Pour simplifier le billet, j'ai développé le script RPUPDATE.PS1 disponible ici. C'est le même principe que le script développé par Microsoft. Le truc, c'est que chaque "Resource Provider" va utiliser la même URL de base (logique car hébergé sur notre serveur "privilégié") mais avec des ports différents. Jusque-là, c'est simple.

Resource Provider

Port par défaut

Monitoring

30020

Marketplace

30018

UsageService

30022

 

Là où cela se complique, c'est que chaque "Resource Provider" n'a pas une URL à exposer mais jusqu'à cinq. Pour nos trois premiers "Resource Providers", ils ne permettent pas de consommer de ressources, donc logiquement, pas besoin de monitoring à remonter aux utilisateurs, encore moins de suivi des usages. Notre tableau s'en trouve donc un peu simplifié. Ce ne sont donc que des simples extension des portails de Windows Azure Pack.

Resource Provider

Type de EndPoint

URL

Monitoring AdminEndpoint

https://wappriv//30020/

  TenantEndpoint

https://wappriv//30020/

MarketPlace AdminEndpoint

https://wappriv//30018/

  TenantEndpoint https://wappriv//30018/subscriptions
UsageService AdminEndpoint

https://wappriv//30022/

  TenantEndpoint

https://wappriv//30022/

 

Donc pour nos trois "Resource Provider", nous devons :

  1. Charger la configuration du "Resource Provider" avec la commande Get-MgmtSvcResourceProvider
  2. Mettre à jour les URL des Endpoints avec un nouveau FQDN commun dans l'objet Powershell retourné par la commande précédente
  3. Sauvegarder la configuration du "Resource provider" avec la commande Set-MgmtSvcResourceProvider
  4. Remplacer le certificat auto-signé

Commençons avec le "Resource Provider" du Monitoring. J'ai choisi de mutualiser tous les "Resources Providers" sur une même URL de base : https://adminapi.Windowsazurepack.fr. Cela implique déjà que le site web utilise MgmtSvc-Monitoring bien le bon certificat. Sinon, c'est un coup à se taper des "Nervous breakdowns comme ils disent".

clip_image004

Ceci-fait, on peut utiliser mon script RPUPDATE.PS1. Il va générer un jeu d'URL pour chaque Endpoint du "Resource Provider" demandé en utilisant comme base le FQDN passé en paramètre, dans notre cas, "https://adminapi.windowsazurepack.Fr".

RPUPDATE.PS1 -ResourceProviderName monitoring -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image005

Une fois exécuté, la configuration du "Resource provider" a été mise à jour avec la commande Set-MgmtSvcResourceProvider. Dans l'illustration ci-dessus, on constate que seuls les Endpoints AdminEndpoint et TenantEndpoint sont configurés. C'est normal, ils ne gèrent pas de ressources mises à disposition des utilisateurs finaux.

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web MgmtSvc-monitoring.

Continuons avec celui du Marketplace. Ce qui est rigolo avec celui-là, c'est que le site web associé ne se nomme pas MgmtSvc-Marketplace comme on pourrait s'y attendre mais MgmtSvc-WebAppGallery. Pourquoi? Ben j'en sais rien. Ici encore, on associe notre certificat pour notre url https://adminapi.windowsazurepack.fr.

clip_image006

On réutilise notre script, en indiquant qu'on veut mettre à jour le "Marketplace" cette fois.

RPUPDATE.PS1 -ResourceProviderName marketplace -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image007

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web Mgmtsvc-WebAppGallery.

Et finissons par le site web MgmtSvc-UsageService.

clip_image008

Plus besoin de présenter le script.

RPUPDATE.PS1 -ResourceProviderName usageservice -HLBAdminUrl https://adminapi.windowsazurepack.fr

clip_image009

Note : Pour que la configuration soit prise en compte, ne pas oublier de redémarrer le site web MgmtsvcUsageService.

 

Pour être sûr, on reprend notre démarche du début pour constater que les Url ont bien été reconfigurées.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL01.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}}

clip_image010

A ce stade, on permet déjà à Windows Azure Pack de fonctionner à minima. Des Web Services situés sur le serveur "public" (Tenant Portal, tenant Public API) sont capables de communiquer avec des Web Services présents sur le serveur "privilégié" (Tenant API, Admin API, Resources Providers) sans avoir de problème de nom d'hôte ou de certificats. Sans eux, la souscription aux différentes ressources ne fonctionnera pas. C'est essentiel dans le prochain billet, on va commencer à rentrer dans le dur du sujet avec la mise en place du "Resource Provider" SQLServer. Vu que c'est la nouvelle année, je suis sympa, la prochaine séance de torture attendra.

 

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

Le cap du 500ème billet

En plus il tombe pile pour la nouvelle année. Donc on va faire un package. Meilleurs vœux à mes lecteurs qui me supportent. Puissiez-vous continuer à supporter mes pérégrinations qui m'ont amenées de DirectAccess à Windows Azure Pack et ses multiples salles de torture. Que votre stock d'aspirine soit renouvelé, vous allez en avoir besoin.

C'est le 500ème et j'ai rien à dire. j'en aurai écrit des bêtises. J'ai commencé ce blog le 19 octobre 2009, le premier billet après un peu plus d'une année sur une autre plateforme de blog avant de migrer en urgence ici. Dans ces 499 billets, il y a eu quelques thèmes récurrents, DirectAccess a été l'un d'entre eux mais pas que. Bizarrement, ce sont effectivement des billets très populaires mais la palme revient quand même à mon vieux compagnon Active Directory que j'ai accompagné depuis Windows 2000 et même un peu avant quand certains "White papers" le dénommaient encore "répertoire Actif" (Ca s'invente pas). Dans le top 10 des billets ayant passé les 10000 views on a donc :

Au final, ça fait quand même presque 200 000 consultations pour environ 68000 utilisateurs selon Google Analytics. Pas trop mauvais score. On va essayer de faire mieux avec Windows Azure Pack Sournois.

Bref, ça fait beaucoup de DirectAccess dans le top 10 avec toujours un peu de Powershell qui traine un peu partout. Le Geek que je suis a découvert DirectAccess grâce à une session Techdays d'Arnaud Lheureux qui date de 2009 (ca fait loin). J'ai mis un doigt dans la prise réseau et tout y est passé, IPv6, IPSEC, les gros câbles et tout ce qui s'en suit.

Ce 500ème billet est aussi l'occasion pour moi de délaisser un peu le sujet DirectAccess pour mieux me focaliser sur l'ami Windows Azure Pack aussi nommé “Service de torture à la demande” tellement le produit est disruptif dans on approche par rapport à tout ce que nous connaissons dans les infrastructure "On-premise".

Bref, se soyez pas surpris si le 501ème billet pourrait traiter de Windows Azure Pack. Prochain chalenge arriver au 1000ème billet.

 

Merci à vous lecteur.

 

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

Posted: 01-04-2015 19:36 by Benoît SAUTIERE | with no comments
Filed under:
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 manqueAgressif.

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 13MoTriste. 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)

Posted: 12-29-2014 11:52 by Benoît SAUTIERE | with no comments
Filed under: ,
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 torturesDiable
  • 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)

Identifier les GPO préparées pour ADMPWD

Dans la série ADMPWD, une petite problématique d’exploitation. Le commandlet Powershell propose la commande Register-ADMPWDWithGPO permet de référencer le Client-Side extension lié à ADMPWD. techniquement, la commande se contente de configurer l’attribut ‘gpcmachineextensionnames’ avec le bon contenu : L’identifiant du Client-Side Extension d’ADMPWD.

 

C’est bien mais comment vérifier que c’est bien fait? Pour cela, il faut faire le travail nous même. le script ci-dessous permet de rechercher parmi toutes les GPO celles pour lesquelles l’attribut ‘gpcmachineextensionnames’ a été configuré pour ADMPWD.

$allGPOs = ([adsisearcher]'(objectCategory=groupPolicyContainer)').FindAll()

$allGPOs | ForEach-Object {

    if ($_.Properties.gpcmachineextensionnames -ne $null)

    {

        $content = $_.Properties.gpcmachineextensionnames

        If ($content -match '{D76B9641-3288-4f75-942D-087DE603E3EA}{D76B9641-3288-4f75-942D-087DE603E3EA}]')         

{

            $_.Properties.displayname

        }

    }

}

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

Installation des modules public de Windows Azure Pack

La partie publique de Windows Azure Pack, c'est celle que nous exposons à nos futurs locataires. Donc on aura le portail des locataires, le site d'authentification et la partie publique de l'API permettant à nos locataires de consommer des services. La modularité de Windows Azure Pack fait qu'il n'est pas obligatoire que le système d'exploitation sous-jacent soit raccordé au domaine. Si on le fait, c'est plus par facilité de gestion et d'administration que pour des contraintes techniques (pas un seul appel RPC, pas de plage dynamique associée, bref de quoi faire apprécier Windows en DMZ aux équipes réseau).

 

Formalités administratives

Comme pour le cœur de réseau, il y a quelques formalités administratives à respecter. Un peu de PowerShell et on en parle plus. Pour rappel, 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

 

Même principe d'installation pour la partie publique, on réutilise les sources qu'on a déjà téléchargé et on utilise le même fichier de "feed".

clip_image002

 

Coté package à installer, la liste est un peu différente :

  • Windows Azure Pack Tenant Portal
  • Windows Azure Pack Tenant Public API
  • Windows Azure Pack Tenant Authentication Site

clip_image003

 

Ceux qui ont l'œil remarqueront la présence des modules GridPro et Cloud Cruiser. Ce ne sont pas des modules "core" de Windows Azure Pack mais des modules complémentaires qui peuvent être très intéressants.

clip_image004

 

Vu qu'on a activé l'option sur notre premier Windows Azure Pack, on va donc continuer dans la même stratégie.

clip_image005

 

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 re-installer la KB2990942 après.

Je passe sur les derniers écrans, c'est la même chose que pour le précédent serveur, tout comme le site de configuration de Windows Azure Pack. Certes, on ne l'a pas demandé, mais on est bien content de l'avoir pour ne pas avoir à configurer cela en PowerShell (mais c'est quand même faisable, c'est un sujet pour bientôt).

clip_image006

 

La seule différence, c'est que la liste des modules de Windows Azure Pack installés est plus que restreinte.

clip_image007

 

Le nombre de modules étant limité, le nombre de certificats qu'on va devoir remplacer est très limité.

clip_image008

 

Seconde piqure de rappel. Pour le prochain billet, on remettra les doigts dans la prise. Mais pourquoi est-il si méchant?

 

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

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)

More Posts Next page »