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

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

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

Windows Server Techical Preview 2 : Start your engine

Pour l’instant, j’avais pas encore mis les main dans Windows 10. A cela plusieurs raisons :

  • Je passe plus de temps avec la gamme Server et les produits System Center
  • De ce que je comprenais de Windows 10 coté client, les fonctionnalités qui allaient m’intéresser n’allaient être utilisables qu’avec la version serveur qui va avec
  • Windows Azure Pack et Azure m’accaparent
  • J’ai trop de sujets en parallèle, il fallait bien que je choisisse.

 

Mais ce jour, on a enfin accès à une nouvelle Preview (seconde) de ce qui pourrait bien s’appeler Windows Server 2016?. Pour l’instant, c’est disponible sur MSDN. 

image

 

En attendant que le download se termine, je plonge dans le What’s new, il y a plein de lectures intéressantes. Network Controller et Web Application Proxy, me voila. Passage en mode matériel, demain soir, c’est cluster Hyper-V en mode Build Windows Windows Server (2016?).

 

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

Windows Azure Pack - IaaS : Introduction
Introduction

Après s'être torturé l'esprit avec l'authentification et les "Resources Providers les plus simples (SQL, et SMA), il y a un moment où il faut franchir un cap et s'attaquer au IaaS. Si vous êtes toujours là, on va se rapprocher de son grand frère Microsoft Azure. Dans cette série de billets, on va s'attaquer à la configuration du IaaS et faire le viaduc entre Windows Azure Pack et System Center Virtual Machine Manager. Ce sont deux mondes bien différents qui doivent communiquer entre eux au travers d'un nouveau composant nommé Service Provider Foundation.

Pas peur de vous faire mal? Très bien allons y. Que les survivants prennent place dans la salle des tortures.

 

Service Provider Foundation, un viaduc entre deux mondes

Encore une fois, on constate que Windows Azure Pack ne fonctionne pas comme les autres produits de chez Microsoft. C'est est un univers ou les Web Services communiquent entre eux en utilisant le standard Open Data Protocol (OData). Coté Virtual Machine Manager, il parle le PowerShell nativement. Bien, mais pour Windows Azure Pack, ça lui parle pas vraiment. Bref, on a déjà un problème de communication. Il nous faut un traducteur universel (Un genre de C3PO mais qui ne parle que deux langues).

Voilà la mission principal de Service Provider Foundation. Techniquement, il va un peu plus loin que cela mais dans l'idée générale cela reste un passe-plat entre deux mondes. Ce point permet de clore un point. Windows Azure Pack n'a aucune idée de ce qu'est System Center Virtual Machine Manager ni System Center Operation Manager. Pourtant ce sont des composants essentiels dans l'infrastructure.

Maintenant que nous avons compris cela, voyons comment cela s'intègre dans Windows Azure Pack. Pour rappel, nous avons un le Portail d'administration qui communique avec le Web Service "Admin API". Ce même Web Service permet de piloter les "Resources providers" et Service Provider Foundations sera l'un d'entre eux.

clip_image001

Là où cela se complique un peu, c'est que Service Provider Foundation fait un peu plus que traducteur Odata<=>PowerShell. Si on se souvient de l'intégration du "Resource Provider" de SQL Server, on avait les "Resources Providers" suivants :

  • Monitoring
  • MarketPlace
  • UsageService
  • SQLServers

Pour rappel, voilà comment on arrivait à ce résultat :

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 SQL.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_image002

 

Note : Ceux qui lisent le PowerShell entre les lignes auront remarqué que j'ai soumis mon authentification auprès du WindowsAuthSite, non pas auprès de l'infrastructure ADFS. C'est normal, j'ai reconfiguré ma maquette pour ne plus utiliser ADFS, que ce soit pour les administrateurs que pour les locataires.

 

Pour SQL Server, nous avions reconfiguré les URL pour les deux portails, la mesure des usages ainsi que pour la notification (notification des jobs en cours dans les portails). Le "Resource Provider" de SQL mettant à disposition des ressources, il est logique qu'il remonte les usages qui en sont fait au "Resource Provider" en question.

Pour Service Provider Foundations, ce n'est pas un "Resource Provider" mais plusieurs :

  • SystemCenter
  • CloudServices
  • Gallery

Le "Resource Provider" SystemCenter, c'est le traducteur universel vers SCVMM. Logiquement, il fournira des éléments pour enrichir le portail des administrateurs, des locataires, des notifications ainsi que l'usage des ressources VM des locataires (monitoring & suivi des usages).

Le "Resource Provider" CloudServices est une équivalence pour la notion disponible dans Microsoft Azure, à savoir exposer des endpoints pour des machines virtuelles. Dans le contexte de Windows Azure Pack, c'est le même principe mais en utilisant SCVMM.

Le "Resource Provider" Gallery est lui dédié au portail des locataires et permet d'exposer les VHD/VHDX et VM templates de la library SCVMM pour permettre aux locataires de créer des "StandAlone virtual machines" voire même des "Virtual Machine Role".

Après, il y a les subtilités car le Service Provider Foundation va aussi fournir des éléments à d'autres "Resource Provider" :

  • Service Management Automation (SMA) va être capable d'exploiter les évènements mis à disposition par Service Provider Foundation pour y associer des Runbooks. Par exemple, il est possible de déclencher l'exécution d'un runbook à la création d'un tenant pour déclencher le provisionnement de certaines ressources (VM Network, Contrôleur de domaine, …)
  • UsageCollector va être capable d'extraire les informations de supervision en provenance de Service Provider Foundation et les stocker dans sa base de données pendant quarante jours (Usage Database). La subtilité, c'est que lui-même sera allé piocher ces informations dans la ou les instances de SCVMM qui elles même auront récupérées l'information depuis SCOM, plus précisément de son Datawarehouse. Vous suivez?

image

 

A la fin, l'objectif est d'exposer toutes les données en relation avec les usages pour produire du reporting ou même de la facturation. On connait maintenant les premiers prérequis pour Service Provider Foundation :

  • System Center Virtual Machine Manager
  • Le Datawarehouse de System Center Operation Manager
  • System Center Operation Manager

 

La suite des réjouissances

On a posé les bases pour cette séance de torture, la suite arrive bientôt :

Entrez dans la salle de torture, le bourreau vous attend, …

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

Windows Azure Pack - IaaS : Création d'un Virtual Machine Role

Félicitations à ceux qui sont arrivés jusque-là, ils ne sont pas nombreux. Ceux qui sont arrivés jusque-là peuvent prétendre créer un Virtual Machine Role. Pour ne pas surcharger cette série de billet, j'ai fait l'impasse sur la création du Virtual Network (ma maquette ne prend pas encore en charge la virtualisation du réseau et la distinction entre Provider Address Space et Customer Address Space), ce sera pour une autre séance de torture. Dans la réalité, le locataire pourrait référencer son propre plan d'adressage et mettre en place une gateway. Les plus téméraires (s'il en reste) pourront consulter l'excellente session TechDays 2014 : Hyper-V Network Virtualization dans WS2012 R2 et SC2012R2. Il faut quand même un peu de travail pour mettre cela en place.

Revenons à l'essentiel et testons le provisioning de d'une Virtual Machine Role. Pour les VM Roles, Windows Azure Pack va s'adresser à au SPF qui va lui-même s'adresser à SCVMM.

clip_image001

 

On va donc déployer le seul Virtual Machine Role à notre disposition dans notre souscription.

clip_image002

 

Notre déploiement doit avoir un nom (comme dans Microsoft Azure), c'est la notion de Cloud Service . On précise aussi la version du rôle à utiliser. Cela a son importance, car le Resource Definition Package référence aussi cette version, tout comme les disques OS et données qui y sont associés. Ils sont été tagués pour ce rôle et cette version.

clip_image003

 

Windows Azure Pack exploite le Resource Definition Package pour proposer des choix au locataire. La Gallery ne proposera que le ou les disques OS/Datas pour lesquels le "Tag" correspond à celui du package.

clip_image004

 

Le paramètre Size est intéressant. Windows Azure Pack nous parle de sizing de machine virtuelle, sauf que ça n'a absolument rien à voir avec les VM templates que nous avons préalablement référencés dans la Gallery. C'est normal, les VM Templates, c'est pour les Standalone Virtual machines. Les VM Roles, c'est comme Microsoft Azure. Donc lorsqu'on utilise les VM Roles, Windows Azure Pack demande au SPF la construction d'une machine virtuelle. Il considère que le Cloud derrière le Service Provider Foundation est un Azure-like qui propose du IaaS. En plus, c'est SCVMM qui se présente comme tel car c'est bien lui qui gère les tailles de VM Roles :

Import-Module VirtualMachineManager

Get-CloudVMRoleSizeProfile | ft Name, Description, CpuCount, MemoryInMB –AutoSize

clip_image005

 

Dans Azure, on déploie des VMRole dans un Cloud Service, ce qui permet de faire du scale-out. Logiquement avec un VM Role dans Windows Azure Pack, on peut faire de même en fournissant le préfixe à utiliser pour la création des différences instances ainsi que le nombre minimum et maximum d'instances.

clip_image006

 

Dans le portail du locataire, on peut voir que les choses avancent. Au passage, un grand merci à Anders Bengtsson pour son billet Setting up VM Roles in WAP sans lequel je serai encore en train de chercher pourquoi mon déploiement de VM Role échouait.

clip_image007

 

Coté SCVMM, si on regarde les jobs, on constate les entrées suivantes pour le compte de benoit@simplebydesign.Fr:

  • La création d'un Cloud
  • La création d'une VM Role Resource

Import-Module VirtualMachineManager

Get-ScJobs | Where {$_.owner -match "benoit@simplebydesign.fr"} | Select -First 2

clip_image008

 

Subtilité du chef pour le dessert, du pour SCVMM, nous avons bien une machine virtuelle, mais aussi une "Cloud Resource".

Get-SCVirtualMachine | Select Name

Get-CloudResource

clip_image009

 

Ça ressemble furieusement à du Microsoft Azure IaaS. Si le locataire est patient, il a sa machine virtuelle sera provisionnée. Mon Windows Azure Pack, n'est pas aussi performant qu'un Datacenter de Microsoft Azure.

clip_image010

 

Si le portail nous indique qu'une machine virtuelle est provisionnée, notre locataire doit pouvoir faire de même en Powershell :

Get-WAPAckVM | Select CloudVMRoleName, ComputerName, Name, Status | Format-Table -Autosize

clip_image011

 

Si on revient au portail des locataires, on peut consulter l'utilisation que nous faisons de notre abonnement et où nous en sommes par rapport aux limites imposées. Visiblement, j'ai encore un peu de marge.

clip_image012

 

Notre Cloud Service contient une seule instance de notre machine virtuelle. Nous pouvons gérer chaque instance individuellement.

clip_image013

 

Pour chaque instance de notre VM Role, nous pouvons afficher les informations d'usage associées. Techniquement, ces informations sont récupérées par Service Provider Foundation auprès de SCOM qui lui-même les a collectées auprès de SCVMM. Ce sont des informations que nous fournisseur de service pouvons exploiter pour réaliser le capacity-planning de notre infrastructure.

clip_image014

 

Dans Microsoft Azure on peut Scaler le déploiement d'un Cloue Service. Dans Windows Azure Pack Aussi (Scale Up et Scale out). Dans l'exemple ci-dessous, j'ajoute une instance à mon Cloud Service existant.

clip_image015

 

Lorsqu'on regarde ce qui se passe pendant le provisioning (en Powershell), le Service Provider Foundation génère du PowerShell pour que l'infrastructure SCVMM délivre. Dans l'exemple ci-dessous c'est la tâche de scale-out que mon locataire vient juste de demander.

Import-Module VirtualMachineManager

Get-SC-Job | Where {$_.owner -match "benoit@simplebydesign.fr"} | select -First 1

clip_image016

 

Pour finir, notre locataire peut reconfigurer à souhait sa machine virtuelle, tant qu'il reste dans les limites imposées par le VM Role.

clip_image017

 

C'est la fin de cette séance de torture. Si vous avez trouvé cela complexe, dites-vous que ce n'est qu'un survol du module IaaS de Windows Azure Pack. Il reste tellement de sujets à développer :

  • La virtualisation de réseau avec NVGRE
  • La mise en place de la Gateway RDS
  • Le monitoring et le suivi des usages (System Center Service Reporting / Cloud Cruiser)

 

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

Windows Azure Pack - IaaS : L'expérience locataire

La fin se rapproche, mais c'est pas pour cela qu'on va faiblir, le bourreau est plein de ressources. Dans le portail du locataire, celui-ci dispose maintenant de la souscription nouvellement mise à disposition.

clip_image001

 

Trop facile? c'est pour cela qu'on va corser un peu plus la chose. On passe sous la moquette avec un peu de torture PowerShell, allons explorer la nouvelle souscription de notre locataire.

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 SQL.WindowsAzurePack.lan

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

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

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

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

Get-MgmtSvcUser -AdminUri $adminuri -Token $token

Get-MgmtsvcSubscription -AdminUri $adminuri -Token $token

clip_image002

 

Ma plateforme Windows Azure Pack accueillant son premier locataire, la commande Get-MgmtSvcUser ne retourne qu'un seul utilisateur, lequel a une seule souscription. La commande Get-MgmtSvcSubscription nous retourne l'unique souscription de notre locataire. Celle-ci est intéressante car c'est sous cet identifiant (SubscriptionID) qu'est référencé notre locataire qui vient consommer des ressources auprès du Service Provider Foundation sur notre serveur SCVMM. Vous suivez toujours? Ce qui compte pour Service Provider Foundation, c'est la souscription et non l'utilisateur qui a souscrit l'abonnement au "plan".

Import-Module SPFAdmin

Get-SCSPFTenant

$Tenant = Get-SCSPFTenant | Where {$_.Name -Match "benoit@simplebydesign.fr"}

Import-Module VirtualMachineManager

Get-SCUserRole | Where {$_.ID -eq $Tenant.Id}

clip_image003

 

Là où cela se complique, c'est dans SCVMM. Pour lui, on ne peut disposer de privilèges que si l'utilisateur est associé à un Rôle. Lors de la souscription Service Provider Foundation a demandé à SCVMM de créer un rôle qui est lié à la souscription et non à l'utilisateur Windows Azure Pack. C'est l'identifiant du Tenant qui permet de faire le lien avec le rôle dans SCVMM. Dans SCVMM, on constate bien la présence du rôle. Celui-ci est bien limité pour ne pouvoir consommer des ressources que dans le Cloud que nous avons référencé.

clip_image004

 

C'est quand même assez déroutant. Maintenant allons voir comment cela se présente du point de vue "PowerShell" du locataire. Après avoir installé le module Azure, il manque quand même quelque chose. Si on demande quels sont les environnements Azure à disposition, la commande Get-AzureEnvironment nous retourne la réponse ci-dessous :

clip_image005

 

Effectivement, on a bien Microsoft Azure, mais pas de trace de notre Windows Azure Pack. Pour cela, il faut le référencer à l'aide de la commande Add-AzureEnvironment, laquelle a besoin de trois informations :

  • Le nom de l'environnement à référencer
  • L'URL publique de la Tenant API
  • L'URL de publication des informations de souscription

Add-AzureEnvironment -name "My Windows Azure Pack" -ServiceEndPoint "https://tenantpublicapi.windowsazurepack.fr" -PublishSettingsFileUrl "https://tenantportal.windowsazurepack.fr/publishsettings"

clip_image006

 

Maintenant, c'est Azure "Like" ou presque, il faut juste préciser qu'on veut utiliser notre Windows Azure Pack pour aller récupérer notre fichier PublishSettings.

clip_image007

 

Une fois authentifié, nous sommes automatiquement redirigé vers l'URL de téléchargement de notre fichier PublishSettings. C'est tout comme Microsoft Azure.

clip_image008

 

Ne reste plus qu'à l'importer le fichier décrivant nos souscriptions à l'aide de la commande Import-WAPackPublishSettingsFile qui n'est jusque qu'un alias pour la commande Import-AzurePublishSettingsFile. La seule subtilité c'est de bien préciser notre environnement Windows Azure Pack.

Import-WAPackPublishSettingsFile -PublishSettingsFile 'c:\temp\SQL Server-IaaS-4-5-15-credentials.publishsettings' -Environment "My Windows Azure Pack"

clip_image009

 

Si cela fonctionne, le "Resource Provider" exposé via l'API publique des locataires devrait être capable de nous fournir des informations sur l'environnement IaaS mis à disposition comme l'infrastructure réseau avec la commande Get-WAPackVnet :

clip_image010

 

Comme pour son grand frère, on retrouve le détail de nos souscriptions dans le portail des locataires de Windows Azure Pack ainsi que la présence du certificat auto-signé qui nous authentifie lorsqu'on utilise les commandes PowerShell d'Azure/Azure Pack.

clip_image011

 

Notre locataire va pouvoir enfin consommer des ressources. Ça tombe bien, c'était l'avant-dernier billet de cette série.

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

Windows Azure Pack - IaaS : Création du Plan

Du point de vue de nos futurs locataires, Windows Azure Pack, ce ne sont que des “plans” auxquels ils peuvent souscrire. Chaque “Plan” met à disposition des ressources en provenance d'un ou plusieurs "Resource Providers". Mettons la casquette du Service Provider et attaquons le sujet.

D'un point de vue technique, les ressources de SCVMM doivent être mises à mises à disposition de Windows Azure Pack pour permettre aux locataires de les consommer. Cette mise à disposition s'effectue sous la forme de "plan" que l'on peut traduire par abonnement auquel notre futur locataire pourra souscrire. On peut créer un nouveau "plan" ou associer nos ressources à un "plan" existant. C'est le premier scénario que j'ai retenu.

clip_image001

 

Notre nouveau plan ne va proposer qu'un seul type de ressource : des machines virtuelles. Cela ne veut pas dire que nos locataire ne pourront pas consommer du SQL as a Service mais que ce sera au travers d'un autre plan auquel il devra souscrire.

clip_image002

 

Pour cette souscription, on n'a pas encore d'extension à proposer à nos futurs locataires. On ne propose une extension aux locataires que pour étendre les moyens mis à disposition pour consommer les ressources que nous mettons à disposition.

clip_image003

 

Le "plan" nouvellement créé est pour l'instant pas encore visible par les locataires. Il est privé, uniquement disponible aux locataires si un administrateur leur associe à leur souscription (genre preview sur invitation), mais surtout, il reste de la configuration à faire.

clip_image004

 

Le portail nous indique que la souscription contient une ressource pour laquelle il manque de la configuration et que la consommation actuelle ressemble à un électrocardiogramme plat.

clip_image005

 

La première étape de la configuration, c'est de sélectionner l'instance SCVMM préalablement déclarées à l'étape précédente et de spécifier le Cloud SCVMM dans lequel on va venir consommer les ressources. Cela va conditionner beaucoup de choses car SCVMM va nous exposer ses ressources mais aussi ses contraintes. Dans la section "Usage Limits", on peut reconfigurer les limites du VM Cloud qui seront proposées aux locataires. N'oubliez pas de cliquer sur le bouton "Save" pour valider les changements, …

clip_image006

 

Si on regarde un peu plus bas, il y a d'autres options à configurer :

  • Network
  • Hardward Profiles
  • VM templates
  • Gallery

clip_image007

 

Le Network correspond à un VM Network déclaré dans SCVMM et associé au Cloud (idéalement, il devrait supporter NVGRE). Les Hardware profiles décrivent les configurations matérielles des machines virtuelles qui ont été utilisées pour préparer les templates de VM que nous avons aussi référencés. Ce sont les éléments qui seront présentés à nos futurs locataires pour provisionner des StandAlone VM. Pour La Gallery, cela correspond aux éléments que nous avons configuré avec le GRIT pour les VM Roles .

clip_image008

 

C'est prêt, y a plus qu'à rendre le plan "public" pour que les futurs locataires puissent y souscrire.

clip_image009

 

Après un peu d'attente, notre locataire peut enfin consommer. Il est temps d'aller voir à quoi cela ressemble du point de vue de notre futur locataire. C'est l'heure de la récompense pour les survivants.

 

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

Windows Azure Pack - IaaS : Gallery Resource Import Tool

Le Gallery Resource Import Tool (GRIT), c'est un outil magique qui va nous faciliter l'adaptation des avec une interface graphique. Sinon, ce ne serait que du Powershell, autant dire que ça pique les yeux. L'outil est disponible à cette adresse et en plus cocorico, l'auteur est un Français. Avant de l'exécuter dans une invite de commande PowerShell (avec tous les privilèges), il faut configurer quelques variables :

  • SCVMM : SCVMM.WINDOWSAZUREPACK.LAN
  • SPF :SPF.WINDOWAZUREPACK.FR

clip_image001

 

Depuis la version 1.2, l'outil prend en charge l'utilisation d'un Service Provider Foundation distant. Pour cela, l'outil a besoin d'une délégation Kerberos lors de l'exécution. Celle-ci sera automatiquement mise en place et retirée à la fin de l'exécution. C'est le cas de ma maquette puisque j'exécute le GRIT depuis le serveur sur lequel sont installés les modules privilégiés de Windows Azure Pack (AdminAPI, WindowsAutSite, AdminSite).

clip_image002

 

Qui dit délégation implique une identité, ce sera celle du compte de service que nous avons utilisé pour configurer le Service Provider Foundation. Le compte WAP\FT-SPF-SVC est membre du groupe WAP\FT-SPF-Admins .

clip_image003

 

Vu que le Web Plateform Installer est disponible sur mon serveur (et que celui-ci a accès à Internet), il me propose la liste des packages disponibles. Nous, nous l'avons déjà préalablement téléchargé, nous allons donc sélectionner un fichier RESDEF préalablement téléchargé.

clip_image004

 

Pour la suite de ce billet, j'ai sélectionné le package RESDEF "WS2012_WG_VMRole_PKG". C'est bien fait car pour chaque "Gallery resource", on a un fichier Word d'explication. A ce stade, le package n'est pas encore utilisable. Le package exprime des critères d'éligibilité (version d'OS, Rôle & Feature, …) que nous devons mettre à disposition. Lors du déploiement, Windows Azure Pack va demander au SPF de localiser les ressources disques VHD/VHDX utilisable avec le package RESDEF. Pour cela, il recherchera des "Tag" sur les disques présents dans la librairie SCVMM. La ressource obligatoire, c'est un système d'exploitation à déployer. J'en ai plusieurs dans ma librairie SCVMM, ce qui manque, c'est le lien entre les deux. On va se positionner dans l'onglet "Virtual Disks Configuration".

clip_image005

 

Si on consulte le document Word associé à la “Gallery resource”, il est indiqué que nous avons besoin d'un système d'exploitation Windows Server 2012. Maintenant, il faut bien lire l'encadré, c'est m'expression des prérequis pour le disque OS. Nous, nous devons juste sélectionner le ou les disques contenant un système d'exploitation Windows Server 2012. Lorsqu'on clique sur le bouton "Apply Theses OS Disk Settings to Selected Disk(s) and Refresh List", le Tag "WindowsServer2012;R1" sera configuré sur le disque VHDX.

clip_image006

 

Note : Si on en sélectionne plusieurs, le locataire devra choisir le disque OS à utiliser parmi ceux identifiés par le tag.

 

Après exécution, le VHDX mis à jour est reconnu comme un disque OS et le tag est bien positionné.

clip_image007

 

Pour le disque Data (qui n'est pas obligatoire mais vivement recommandé), le package RESDEF contient une expression des prérequis attendus. Dans l'illustration ci-dessous, j'ai plusieurs VHDX éligibles. J'en ai retenu un seul et cliqué sur le bouton "Apply theses OS Disk Settings to Selected Disk(s) and Refresh List".

clip_image008

 

Le tag "DataDisk" a été associé au fichier VHDX présent dans ma librairie.

clip_image009

 

On peut le vérifier dans SCVMM en demandant la liste des disques contenu dans la librairie pour lesquels la propriété “FamilyName” contient le tag "WindowsServer2012-R1" que nous venons de positionner, il n'y en a qu'un.

Import-module VirtualMachineManager

Get-ScVirtualHardDisk | Where {$_.FamilyName -Match "WindowsServer2012-R1"}

clip_image010

 

Note : Pour le disque de données, c'est le même principe sauf que le contenu de l'attribut “FamilyName” sera "DataDisk".

 

Passons maintenant à l'étape suivante avec les importations. Le package Resource Definition (RESDEF) est à destination de Windows Azure Pack et l'éventuel package RESDEFEXT est lui à destination de notre instance SCVMM. Dans le cas de notre VM Role Windows Server 2012 Workgroup, il n'y a aucune personnalisation à apporter post-installation, il n'y a donc rien à importer dans SCVMM. Pour cette raison, le GRIT ne nous propose pas de spécifier une instance de librairie SCVMM dans laquelle réaliser l'importation.

clip_image011

 

Derrière, le GRIT a fait le job, à savoir mettre à jour les deux disques et importé le Resource Definition Package dans Windows Azure Pack.

clip_image012

 

Note : Pour ceux qui se posent la question du versioning, chaque Resource Definition Package contient une version, c'est cette version qui sera utilisée pour rechercher le disque ayant le bon tag et la bonne version. Plusieurs versions peuvent ainsi être proposées au locataire.

 

Pour illustrer, je n'ai pas utilisé le GRIT pour réaliser l'importation du package RESDEF. Allons dans le portail d'administration de Windows Azure Pack, nous n'avions pas encore exploré la Gallery.

clip_image013

 

Y a plus qu'à sélectionner le Resource Definition package (Extension RESDEFPKG) à importer.

clip_image014

 

Notre Resource Definition Package est maintenant disponible dans Windows Azure Pack.

clip_image015

 

On peut consulter les informations qui seront accessibles aux futurs locataires. Bien entendu, c'est personnalisable avec le VM Authoring Tool.

clip_image016

 

Ne nous reste plus qu'à rendre cette ressource accessible en la rendant publique, sans cela, on ne pourra pas l'associer à un plan.

clip_image017

 

Arrivé à ce stade, dites-vous que le plus difficile est fait. La prochaine étape, c'est plus du marketing / Business que de la technique. Félicitation aux survivants qui ont tenu jusque-là.

 

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

Windows Azure Pack - IaaS : Standalone VM versus Virtual Machine Role

Nous savons déjà que Windows Azure Pack ne communique pas directement avec SCVMM. Coté Windows Azure Pack, il a juste besoin d'avoir une définition de ce qu'il doit demander avec la liste des prérequis à demander au locataire. Windows Azure Pack est capable de provisionner deux types de machines virtuelles :

  • StandAlone Virtual Machine
  • Virtual Machine Role

Pour une StandAlone Virtual Machine, Windows Azure Pack va se reposer sur SCVMM pour exploiter deux types de ressources : Les images VHD/VHDX et les templates de machines virtuelles . Ce sont des éléments de SCVMM que nous avons préalablement associé au Cloud utilisé dans Windows Azure Pack. C'est une approche simpliste puisque cela ne permet aucune forme de personnalisation (ajout de rôle, installation d'application via SCVMM ou même scale-out de la machine virtuelle). Pour le futur locataire, voilà à quoi cela ressemble :

clip_image001

 

Il sélectionne son template de machine virtuelle et on lance le déploiement. Pour les Virtual Machines Roles, c'est un peu plus sophistiqué. On va uniquement exploiter un ou plusieurs VHD/VHDX mis à disposition dans la librairie SCVMM pour composer une machine virtuelle personnalisable (JSON rules again). D'une part l'utilisateur pourra fournir des paramètres qui seront utilisés lors du déploiement de sa machine virtuelle mais en plus on sera capable de réaliser des actions post-déploiement tel que l'installation de rôles, logiciels. Cerise sur le gâteau, les Virtual Machine Roles sont scalables. C'est ce concept que nous allons développer, c'est bien plus "capilo-tracté". Pour arriver à ce tour de force, Windows Azure Pack a besoin de deux fichiers :

  • Le Resource Definition Package (RESDEF)
  • Le Resource Extension Package (RESDEFEXT)

Le Resource Definition Package (RESDEF) permet de spécifier les paramètres qui seront utilisés par Windows Azure Pack pour composer la future machine virtuelle. Cela comprend la définition des paramètres attendus lors de la création de la machine virtuelle et tout ce qui est nécessaire pour construire une interface facilitant le déploiement pour notre futur locataire. C'est donc un fichier qui est consommé par Windows Azure Pack, plus précisément par la Gallery.

Le Resource Extension Package (RESDEFEXT) exploite une capacité de SCVMM pour personnaliser la machine virtuelle nouvellement déployée sous la forme de scripts exécutés lors de la première ouverture de session ainsi que d'applications à déployer grâce à SCVMM. C’est donc un package qui est injecté lors du déploiement avec les paramètres attendus.

 

Prenons un cas concret avec le déploiement d'un contrôleur de domaine :

  • Le Resource Definition Package (RESDEF) contient de quoi déployer le système d'exploitation (NOM, IP, …) mais aussi de quoi poser les bonnes questions à notre locataire (Nom DNS du futur domaine, son nom NETBIOS, mot de passe DSRM, …).
  • Le Resource Extension Package (RESDEFEXT) utilise nos paramètres pour réaliser la promotion du contrôleur de domaine en exécutant un script lors d'une première ouverture de session.

clip_image002

 

On remarque tout de suite que cette approche a une limite, notre Virtual Machine Role ne peut contenir qu'une seule machine virtuelle. Pourtant dans le Web Plateform Installer, on nous propose de déployer des infrastructures Lync et SharePoint. Il y a une astuce mais c'est une autre histoire . Voila pour la version courte. Pour la version "Hurt me plenty baby", je conseille les lectures suivantes pour découvrir un univers à part dans Windows Azure Pack :

 

Maintenant que le décors est posé, peuplons notre Gallery. Pour avoir du contenu, on peut utiliser les ressources déjà mises à disposition par Microsoft. Si on reconfigure le Feed utilisé par le Web Plateform Installer à l'URL suivante http://www.microsoft.com/web/webpi/partners/servicemodels.xml, on arrive au contenu présenté ci-dessous : les Gallery Resources :

clip_image003

 

Une Gallery resource, c'est une ressource IaaS à laquelle nos locataire pourront souscrire. C’est du prêt à consommer. L'avantage, c'est qu'on peut proposer tout un éventail de machines virtuelles, de la plus basique, à la plus évoluée. J'ai fait mon marché en prenant de quoi faire un premier jeu de test basé sur Windows Server 2012 et Windows Server 2012 R2 pour des déploiement en Workgroup. La base quoi.

clip_image004

 

La liste de courses est complète, y a plus qu'à lancer le téléchargement et récupérer le contenu.

clip_image005

 

Je récupère ce contenu et le mets à disposition de de mon Windows Azure Pack.

clip_image006

 

Nous avons du contenu mais il n'est pas encore utilisable dans Windows Azure Pack. Ce contenu n'est même pas encore adapté à notre environnement. Les plus téméraires peuvent explorer le Resource Definition Package (RESDEFPKG) à l'aide du VM Authoring Tool mais ça va piquer les yeux. C'est un sujet sur lequel je reviendrait certainement dans un prochain billet.

Nous nous allons poursuivre avec l'adaptation et l'importation de ces packages (Resource Definition Package et Resource Extension Package) dans Windows Azure Pack et SCVMM. Vu que ce sont des packages génériques, ils ne savent pas quelles ressources utiliser dans SCVMM (disques OS, disques de données en particulier). Pour faire le lien entre les deux, il faut tagger les ressources à l'aide du Gallery Resource Import Tool. Ce sera l’objet du prochain billet.

 

Après ceux qui trouvent que je la joue petit bras en déployant du simple Windows, je leur recommande le téléchargement du Gallery resource “CPS WorkLoads Multi tier Gallery Resource” et les saines lectures associées :

 

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

Windows Azure Pack - IaaS : Déclaration du VM Cloud

Nous avons référencé une instance de Service Provider avec Windows Azure Pack, reste maintenant à configurer l'autre partie, à savoir déclarer le/les instances de SCVMM, lesquelles peuvent exposer un ou plusieurs Cloud dans lesquels on va pouvoir consommer des ressources. Il est possible d'instancier jusqu'à cinq SCVMM différents pour une seule instance du Service Provider Foundation.

clip_image001

 

Pour chaque association entre notre instance de Service Provider Foundation et une instance de SCVMM, nous devons référencer au moins deux informations :

  • Le FQDN de l'instance SCVMM
  • Le port utilisé pour administrer l'instance SCVMM

La configuration de la Remote Desktop Gateway n'est qu'optionnelle. C'est grâce à ce composant que nos locataires pourront se connecter en RDP aux instances de machines virtuelles sans que celles-ci ne soient directement exposées sur Internet. Le service existe à l'identique dans Microsoft Azure. La seule différence, c'est que dans Windows Azure Pack, il permettra à nos locataires d'accéder à leurs machines virtuelles même éteintes. Derrière, c'est une fonctionnalité de SCVMM 2012 R2 (Remote Console in System Center 2012 R2) qui est exploitée avec la Gateway de Remote Desktop Services. C'est un sujet un peu à part, il sera donc traité dans une série de billet distincte.

clip_image002

 

Note : Pour que cela fonctionne, cela implique que le contexte de Web Service VMM inclus dans Service Provider Foundation se présenter devant SCVMM avec le niveau de privilège le plus élevé, à savoir Administrator. C'est sous ce contexte (WAP\FT-SPF-SVC) que Windows Azure Pack se présentera auprès de SCVMM pour faire traiter ses demandes. Pour que le tout fonctionne, il y a quelques prérequis, juste un peu, ...

 

Ci-dessous, le cas de ma maquette, mon instance de SCVMM ne contient un seul Cloud qui annonce ses capacités. On peut déjà dire tout de suite que les capacités annoncées sont loin d'être illimitées.

clip_image003

 

En dessous, il faut comprendre que ce n'est pas le Windows Azure Pack que nous configurons pour utiliser notre instance de SCVMM mais bien le Service Provider Foundation. Plus précisément, on déclare un Stamp. Un Stamp représente un package de ressources (Compute, storage, Network, …) qui est géré par une instance de Virtual Machine Manager. Service Provider Foundation peut être connecté à de multiples stamp représentant des SCVMM distincts. Au final, Windows Azure Pack n'a aucune notion de ce qu'il y a derrière, Service provider Foundation agissant comme une couche d'abstraction qui permet de délivrer du service IaaS.

Derrière un Stamp, on peut tout à fait avoir un Datacenter ou même plusieurs Datacenters si tous sont managés avec une même instance de SCVMM. Suite à cette configuration, on peut constater que c'est bien dans le Service Provider Foundation qui a été configuré pour référencer notre SCVMM, pas Windows Azure Pack.

clip_image004

 

Vu que notre Stamp est tout neuf, il n'y a donc aucune ressource consommée dedans.

clip_image005

 

A ce stade, nous avons n'avons encore aucune ressource à proposer à nos futurs locataires. Il est temps de se soucier de proposer un peu de contenu. La construction de l’infrastructure est terminée. On passe maintenant en mode “Fournisseur de service”. Finalement, c’était pas si compliqué (Si VMM est bien configuré et que l’installation du SPF a été réalisée dans les règles de l’art).

 

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

Solve W2K12R2 DirectAccess OTP activation problem with Powershell

I was working on a DirectAccess POC for a customer of mine a few months ago. Now it’s time to go in production and moving from Windows 2012 to Windows Server 2012 R2. I was rebuilding my lab and have a closer look at KB2883952 to avoid most of problems. This time, problem is not in the list. I was not able to configure OTP authentication for DirectAccess because no capable ADCS can be used to provide required certificates.

0

Not logic, my lab worked like a charm in Windows Server 2012, so ADCS role configuration was good. Because it’s only a prerequisite check, let’s try to configure OTP scenario using the Enable-DAOTPAuthentication PowerShell commandlet and surprised, it worked !

1

Even if it worked from the PowerShell commandlet, the console does not recognize ADCS as compatible but it’s no longer blocking in the configuration process.

2

PowerShell rules!

Edit 24/04/2015 : Now KB3047733 fix that problem. My workaround is no longer required.

 

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

Windows Azure Pack - IaaS : Intégration de Service Provider Foundation

Du point de vue de Windows Azure Pack, nous devons déclarer notre C3PO, alias Service Provider Foundation. Dans le portail d'administration, cela se passe dans le nœud "VM Cloud".

clip_image001

 

L'URL attendue, c'est l'URL de base de du site web présent sur l'hôte sur lequel Service Provider Foundation a été installé. Pour le contexte de sécurité, c'est le compte WAP\SPF-SVC utilisé pour le le Web Service d'administration du Service Provider Foundation.

clip_image002

 

Si tous les prérequis d'installation ont été respectés, l'enregistrement doit fonctionner. Nous avons même une notification dans le portail.

clip_image003

 

Dans les subtilités, j'avais annoncé que le Service Provider Foundation fournissait des évènements sur lequel Service Management Automation pouvait venir s'interfacer. Pour cela, encore faut-il déclarer auprès de quel SMA annoncer ces évènements.

clip_image004

 

Ma maquette disposant déjà d'un Service Management Automation, il suffit juste d'en référencer l'URL qui a été utilisée pour le “Resource Provider”.

clip_image005

 

Nous recevons une notification comme quoi le "System Center Automation endpoint" a été créé.

clip_image006

 

Cela signifie que Service Management Automation sera en mesure d'exploiter les évènements générés par Service Provider Foundation et d'y attacher des Runbooks pour exécution. La subtilité, c'est que seuls les Runbooks ayant le tag SPF pourront être utilisés.

Pour finir, nous devons référencer le endpoint qui expose l'usage des machines virtuelles : https://spf.windowsazurepack.Fr:8090/USAGE avec le compte qui va avec.

clip_image007

 

Nous sommes notifiés comme quoi le endpoint a bien été référencé. C'est maintenant que les choses intéressantes commencent.

clip_image008

 

Allons voir ce que cela a changé du point de vue des “Resource Providers” déclarés dans Windows Azure Pack. On retourne donc explorer le CommandLet Powershell MgmtsvcAdmin :

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 SQL.WindowsAzurePack.lan

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

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL.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, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}}, @{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-table -AutoSize

clip_image009

 

On constate la présence de nouveaux "Resource Providers" :

  • System Center
  • CloudServices
  • Gallery

 

La bonne nouvelle, c'est que vu que nous n'avons pas utilisé de certificat auto-signé, pas besoin de revenir corriger les FQDN, c'est déjà opérationnel.

 

Note : Ceux qui lisent le PowerShell entre les lignes auront remarqué que j'ai soumis mon authentification auprès du WindowsAuthSite, non pas auprès de l'infrastructure ADFS. C'est normal, j'ai reconfiguré ma maquette pour ne plus utiliser ADFS, que ce soit pour les administrateurs que pour les locataires.

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

Windows Azure Pack - IaaS : Installation du Service Provider Foundation

L'installation du Service Provider Foundation en elle-même n'est pas très compliquée. Les prérequis sont disponible ici. La subtilité, c'est que Service Provider Foundation va mettre en place quatre Web Services. Chaque Web Service devant disposer d'un contexte de sécurité qui lui est propre, cela implique un peu d'isolation. Chaque Web Service disposera donc :

  • D'un compte de domaine pour le contexte d'exécution
  • D'un groupe local de Sécurité sur le serveur SPF
  • D'un pool applicatif IIS

 

Compte AD de service

Groupe de sécurité local

Pool applicatif IIS

WAP\FT-SPF-SVC SPF_Admin Admin
WAP\FT-SPF-Provider SPF_Provider Provider
WAP\FT-SPF-VMM SPF_VMM VMM
WAP\FT-SPF-Usage SPF_Usage Usage

 

Pour le détail des explications, je renvoie vers le Technet : Security Planning for Service Provider Foundation. Ma maquette devenant un peu à l'étroit, je suis obligé de réduire la voilure. Je comptais installer le Service provider Foundation sur un serveur dédié pour préparer la haute disponibilité mais j'ai finalement retenu de l'installer sur mon serveur SCVMM. En même temps, ce n'est pas illogique. En plus, cela réduit le nombre de prérequis à installer car la console SCVMM sera déjà présente.

clip_image001

 

D'un point de vue sizing, j'ai retenu les recommandations Microsoft : Capacity Planning for Service Provider Foundation.

Nombre de VM

CPU

RAM

Moins de 5000 4 cœurs 8 Go RAM
Entre 5 000 et 12 000 VM 8 cœurs 8 Go RAM
Entre 12 000 et 25 000 VM 16 cœurs 8 Go RAM

 

Ça peut paraitre beaucoup mais derrière, le SPF va cracher du PowerShell. Il faut pouvoir paralléliser un tant soit peu. Par défaut, notre SPF est capable de traiter jusqu'à 1000 connexions concurrentes pour ses Web Services.

On peut s'attaquer à l'installation du Service Provider Foundation. Le composant est disponible sur le média d'installation d'Orchestrator 2012 R2.

clip_image002

 

Coté prérequis il y a du monde. D'un côté nous avons Windows Azure Pack qui ne communique que par Web Service (OData). Logiquement, on a donc un IIS pour les prérequis, avec le "Management Odata IIS Extension". De l'autre côté, le Service Provider Foundation doit communiquer avec SCVMM. Pour cela, rien de mieux que la console SCVMM et le module PowerShell associé. Pour les autres, ce ne sont que quelques rôles et fonctionnalités.

clip_image003

 

Le premier besoin de Service Provider Foundation, c'est une base de données. L'objectif est de stocker la configuration mais aussi les éléments tel que les mesures d'usages qui seront remontées au UsageCollector de Windows Azure Pack. Il faut juste se rappeler que les données d'usage sont conservées pendant quarante jours. Pour 25000 machines virtuelles, il faut au prévoir 5Gb pour cette base de données.

clip_image004

 

Pour commencer, il nous faut un site web IIS qui utilisera un port spécifique (8090). Il sera utilisé pour héberger un Web Service qui utilisera un certificat SSL. Pour notre installation, nous avons exclus l'utilisation d'un certificat auto-signé pour un véritable certificat émis par notre autorité de certification interne (C'est une erreur sur l'illustration ci-dessous, je le précise).

clip_image005

 

Le premier Web service est dédié à l’administration de Service Provider Foundation. Un contexte de sécurité spécifique a été mis en place pour cela avec le compte WAP\FT-SPF-SVC.

clip_image006

 

Second Web service va s'interfacer avec Windows Azure Pack sous la forme d'un Resource Provider. On a donc une identité distincte avec le compte WAP\FT-SPF-Provider.

clip_image007

 

Le Service Provider Foundation devant communiquer avec SCVMM, il mettra en place un Web Service chargé de la communication avec ce dernier. C'est un contexte de sécurité distinct : WAP\FT-SPF-VMM.

clip_image008

 

Pour la collecte des usages du service IaaS. Service Provider Foundation doit mettre en place son endpoint pour exposer les usages. Ce sera encore un contexte de sécurité distincte : WAP\FT-SPF-USAGE.

clip_image009

 

Y a plus qu'à installer le tout.

clip_image010

 

Si tout se passe bien, on en arrive là.

clip_image011

 

Dans la console IIS, on trouve un site web dédié à Service Provider Foundation sur lequel on a lié notre certificat.

clip_image012

 

C'est ce site Web qui porte les quatre Web Services suivants :

 

Pour valider notre installation on peut valider que les deux premiers répondent bien en testant les URL localement. Pour le Web Service d'administration, c'est : https://localhost:8090/SC2012/Admin/microsoft.management.odata.svc/

clip_image013

 

On commence à comprendre ce que Service Provider Foundation va offrir à Windows Azure Pack. Pour tester le Web Service en relation avec SCVMM, c'est l'URL suivante : https://localhost:8090/SC2012/VMM/microsoft.management.odata.svc/

clip_image014

 

A voir le contenu, on comprend aussi qu'on va causer exclusivement d'objets en relation avec System Center Virtual machine Manager. Si l'envie vous en prend de tester avec la véritable URL, il faudra utiliser le compte de service correspondant.

 

Notre C3PO est en place, prochaine étape, mettre tous les interlocuteurs autour d'une table de discussion pour cause IaaS.

 

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

Certification Microsoft infrastructure

Le sujet fait débat régulièrement avec les pro / Cons sur les certifications éditeurs informatique. Entre autres arguments avancés on a :

  • Cela ne reflète pas des scénarios réels
  • Pas actualisé avec les versions intermédiaires / Service Pack
  • Avec des dump on les passe facilement
  • Cela ne prend en compte que les technologies de l'éditeur
  • Sans mise en situation, cela ne vaut rien
  • Ça vaut plus rien, y a trop de monde certifié, pas un facteur différenciant

 

Pour la suite de ce billet, petit rappel : je suis un pur “infra”, donc le cursus de certification développement m’est étranger.

 

Les certifications Microsoft et moi, ça commence à me connaitre. J'ai commencé en 1999 avec Windows NT 4.0. Ca commence à faire loin. A l'époque, mon employeur me donnait même une prime pour chaque certification passée. Grosse erreur de sa partTire la langue. Entre temps, j'ai continué avec Windows 2000 (avec le fameux 70-240 "Pass or fail"), Windows 2003, Windows 2008 et enfin Windows Server 2012 la semaine dernière.

Avec Windows Server 2008, j'étais resté sur ma faim. J'avais trouvé cela un peu léger et j'avoue que j'avais un peu les mêmes reproches et je craignais que ce soit la même chose. Avec Windows Server 2012, j'avoue avoir été surpris. Déjà avec 70-417, on avait beaucoup de contenu (voire même trop) mais au moins cela nous obligeait à travailler un minimum chaque sujet (OK, ADRMS, j'avais fait l'impasse, c'est pas mon truc). Certes l'examen était plus complexe mais encore trop proche de la génération Windows Server 2008. J'avais donc des craintes pour le plat de résistance.

Là, j'ai pris ma claque car Microsoft a élevé le niveau pour 70-413 et 70-414 . Je dis cela parce que cela faisait longtemps que j'avais pas échoué à une certification (70-413), et pour cause :

  • Véritables scénarios intégrant plusieurs technologies Microsoft (voire même Azure)
  • Question actualisées (j'ai eu des questions sur Azure Site Recovery)
  • Scénarios bien complexes
  • Nouveau format de question (assertion / reason)
  • Trop de produits impliqués

 

C'est là que j'ai été surpris. Je ne m'attendais pas à avoir des questions incluant SCCM, SCVMM, SCORCH et toute la gamme System Center. Alors quand Azure a débarqué dans la liste des questions, j'ai compris que j'allais échouer. Même si je pratique beaucoup de ces produits, ça faisait trop à couvrir surtout sans préparation. J'ai donc repris les choses à la base avec le contenu de l'examen 70-414 (avec quelques actualisations pour Windows Server 2012 R2). Avec du temps et beaucoup de labs, on fini par y arriver. Au final, cela efface beaucoup des griefs sur les certifications Microsoft. Ne restent que :

  • La mise en situation
  • Le problème des "Dump"
  • Valeur de la certification sur le marché

La mise en situation existait chez Microsoft. Je dis bien existait car Microsoft n'a pas donné suite au Microsoft Certified Master. C'est dommage. Après, il vaut voir que pour préparer cette certification, j'ai été obligé de travailler le sujet (je dis pas la taille de mon lab, c'est indécent, même pour un Geek). D'ailleurs, cela pose problème pour préparer la certification Private Cloud. On a pas tous un cloud privé à la maison, c'est pas WAF compliant.

Les dump. Oui ça existe mais je suis de moins en moins convaincu que cela puisse aider. Le formaliste des questions (Assertion / reason) ainsi que les séries de question presque identiques mais pour lesquels il n'est pas possible de revenir en arrière font que le risque d'erreur est trop important. Je peux comprendre qu'on utilise les dumps pour se préparer à la certification (notion d'examen blanc) mais apprendre les questions et les réponses par cœur, ça n'apporte pas grand-chose. C’est même dévalorisant.

La certification, c'est aussi une forme de remise en question. Windows ne reste pas éternellement Windows, un jour DCPROMO.EXE sera déprécié. Les certifications Microsoft ont maintenant une durée de vie limitée de trois ans. C’est donc un bon moyen de rester à la page.

S'il y a eu régression, c'est plutôt autour des compétences réseau fondamentales. Les projets d'infrastructure sont de plus en plus dépendant de composants réseau. Rien que dans les domaines de la virtualisation et du stockage, sans réseau, il n'y a plus rien.

Reste la valeur de la certification. OK, disons le tout de suite, une certification AWS a plus de valeur aujourd'hui qu'une certification Microsoft du fait du nombre de personnes qui ont survécu au cursus et obtenu la certification. En plus, c'est du cloud, c'est tendance. La certification Azure devrait permettre de redresser le niveau. De mon point de vue, la valeur de la certification, c’est ce qu’on en fait après.

Enfin, dernier détail, une certification a aussi de la valeur pour nos employeurs (SSII en particulier) car ils en ont besoin. Chaque partenaire doit justifier d'un nombre de personnes certifiées pour maintenir des niveaux de partenariats avec l'éditeur. les deux parties ont donc intérêt à investir dans ces certifications.

 

Si Microsoft développait une certification DirectAccess/IPv6, je m’inscrit.

 

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

ADCS, quick and dirty et conséquences.

Avec la génération d'OS W2K8, les produits Microsoft ont consommé de plus en plus de certificats, certains à vocation sécurité, d'autres à usage technique (Prouver la conformité de mon poste de travail avec Network Access Protection par exemple). C'est à partir de ce moment que j'ai vu fleurir ce que je nome les PKI "Quick-Next" ou plus pudiquement "PKI a vocation techniques uniquement". Vous-vous reconnaissez? Moi aussi. Ci-dessous les deux premières erreurs que nous faisons tous avec ces PKI :

clip_image001

 

L'algorithme de signature pour les certificats émis par notre autorité de certification est SHA-1 par défaut, avec une longueur de clé de 2048. Pour la taille de la clé privée, on ne pourra rien faire. Par contre, SHA-1 est considéré par Microsoft comme un algorithme déprécié, tout du moins pour les autorités de certification reconnues par les systèmes d'exploitation. Pour figurer parmi les Windows Root Certificate Program, Microsoft demande que l'algorithme SHA-1 soit remplacé par SHA-2. Pour les autorités de certification “privées”, cela n’a pas d’impact immédiat. Les autorités de certification “Publiques” ont elles l’obligation de ne plus utiliser SHA-1 en 2017. Au 1er Janvier 2017, Windows arrêtera de prendre en charge les certificats SSL. La migration vers SHA-2 s'impose. Ça fait longtemps que SHA-2 est supporté par tous les systèmes d'exploitation, y compris pour les plus vénérables que sont Windows XP et Windows 2003. Microsoft a publié les correctifs nécessaires pour supporter SHA-2 : (KB968730 and KB938397).

 

Remarque d’un lecteur : Migrer vers SHA-2 ne peut se faire que si on est assuré que les systèmes et applications à qui on va délivrer les certificats le supportent. Il sera donc nécessaire de s’assurer ce ce point avant de procéder à la mise à niveau. Merci Eric S.

 

Maintenant qu'on a compris l'intérêt, voyons comment corriger le problème. Je pars du principe que notre PKI utilise bien le CNG comme Key Storage Provider qui supporte bien SHA-2. Avant de commencer, vérifions que notre PKI "Quick and Dirty" utilise bien l'algorithme incriminé.

clip_image002

 

Ci-dessus, on constate que SHA-1 est bien utilisé comme algorithme de signature pour les certificats délivrés mais aussi pour le certificat qu'elle s'est-elle-même délivrée. Ça c'est du Quick and Dirty. Passons sous la moquette avec un peu de CERTUTIL.EXE -GetReg CA\CSP\CNGHashAlgorithm

clip_image003

A ce stade, notre PKI utilise cet algorithme pour :

  • Tout certificat qu'elle délivre
  • Les CRL qu'elle signe
  • Son propre certificat

Commençons par forcer notre PKI à utilisa SHA-2 :

CERTUTIL.EXE -SetReg CA\CSP\CNGHashAlgorithm SHA256

NET STOP CERTSVC

NET START CERTVC

clip_image004

 

Si on regarde de nouveau les caractéristiques de notre PKI Quick and Dirty, c'est mieux. On pourrait s'arrêter là dans l'immédiat mais au 1er Janvier 2017 on aura un autre problème avec le certificat de l'autorité de certification qui utilise toujours SHA-1. Le certificat est toujours valide après tout.

clip_image005

 

Afin d'anticiper, on va donc demander à notre autorité de certification de renouveler son propre certificat auprès d'elle-même.

clip_image006

 

Ce qui implique un arrêt du service.

clip_image007

 

Pour demander la génération d'un nouveau certificat ainsi que la génération d'une nouvelle parie de clés.

clip_image008

 

Remarque d’un lecteur : Le choix de renouveler le couple clé privée / clé publique peut être impactant. De mon point de vue, il n’est nécessaire que si la taille de la clé existante est beaucoup trop faible. Cela ne devrait pas être le cas avec les autorités de certification opérant sous Windows 2erver 2008 / 2008 R2. Merci Eric S.

 

Maintenant, c'est beaucoup mieux.

clip_image009

 

Lors de la génération de la prochaine CRL, celle-ci sera signée en SHA-2.

clip_image010

 

Remarque d’un lecteur : Ne pas oublier le CERTUTIL.EXE –DSPUBLISH pour forcer ADCS à publier le nouveau certificat dans l’Active Directory. Le certificat doit aussi être mis à disposition des équipements réseau qui ne dépendent pas de l’annuaire Active Directory. Merci Eric S.

 

C'est le bon moment pour sauvegarder la nouvelle clé privée de notre PKI. Vous-souvenez-vous si elle est sauvegardée et où elle est? Allez donc vous rafraichir la mémoire ici http://danstoncloud.com/blogs/simplebydesign/archive/2014/02/06/adcs-ca-private-key-location-change-again.aspx. Si nécessaire prenez les mesures d'urgence.

 

Voilà, c'est moins "Quick and Dirty". Deux petits clics auraient tout changé.

 

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

Posted: 03-06-2015 13:39 by Benoît SAUTIERE | with no comments
Filed under:
Authentification des locataires de Windows Azure Pack avec ADFS (7/7)

Bonus Track car c'est pas obligatoire mais quand même bienvenu de le faire. Une fois la mise en place terminée, si on va faire un tour sur le page de logon de notre infrastructure ADFS (celle de Windows Azure Pack), y a comme un problème.

Lorsqu'ADFS a plusieurs fournisseurs d'identité, il doit demander à l'utilisateur de sélectionner le fournisseur à utiliser. Dans l'illustration ci-dessous, nous avons le fournisseur utilisé pour l'authentification des administrateurs de la plateforme Windows Azure Pack mais aussi celui de notre premier locataire. Pas cool. C'est mon choix d'avoir cumulé les deux usages sur une même infrastructure.

clip_image001

 

Autant on peut dédier une infrastructure ADFS pour les exploitants de la plateforme Windows Azure Pack, autant mettre en place une infrastructure ADFS par locataire n'est pas viable techniquement ou économiquement. Pourtant, on voudrait éviter qu'il puissent se voir entre eux.

Par défaut, une infrastructure ADFS a un seul fournisseur d'identité de confiance, à savoir l'annuaire Active Directory auquel il est raccordé. Il n'y a donc aucun problème, il sait à qui parler. Dès lors qu'on introduit un nouveau fournisseur d'identité de confiance, ça se complique. C'est là qu'intervient la fonctionnalité Home Realm Discovery (HRD). Comme notre ADFS ne sait pas encore à quel fournisseur d'identité solliciter, il doit poser la question à l'utilisateur. C'est la raison pour laquelle on arrive sur la page Client Realm Discovery. La bonne nouvelle, c'est que le choix de l'utilisateur sera consigné dans un cookie sur le poste de travail de notre locataire.

Ce qui manque à notre ADFS, c'est la capacité à reconnaitre le suffixe UPN associé à notre locataire. Allons explorer le Claims Provider Trust avec un peu de PowerShell.

Import-Module ADFS

Get-AdfsClaimsproviderTrust -Name adfs.tenant.fr

clip_image002

 

Vu que l'attribut "OrganizationalAccountSuffix" est vide, notre infrastructure ADFS ne sait pas reconnaitre l'UPN de notre locataire. On va l'aider un peu en peuplant l'attribut avec le suffixe UPN que nous avons imposé à notre locataire.

Set-ADFSClaimsProviderTrust -Targetname adfs.tenant.fr -OrganizationalAccountSuffix "tenant.fr" -PassThru

clip_image003

 

Coté expérience utilisateur c'est déjà mieux.

clip_image004

 

Lorsque l'utilisateur clique sur "Autre organisation", il lui est demandé de renseigner son UPN. Pour les locataires, le problème est clos.

clip_image005

 

On pourrait penser qu'il est possible de faire de même avec le fournisseur d'identité par défaut mais ce serait trop simple. Va falloir se torturer un peu l'esprit.

clip_image006

 

On va jouer à un autre niveau avec les méthodes d'authentification. ADFS est capable de distinguer une authentification selon quelle est issue de l'intérieur ou de l'extérieur. Si l'utilisateur a le choix de la méthode d'authentification, alors ADFS présente les méthodes disponibles. Dans notre cas, le problème ne se pose que pour les authentifications réalisées en interne. On va donc s'assurer de ne plus permettre l'authentification Windows intégrée. Donc que ce soit interne ou externe, ce sera toujours de l'authentification par formulaire.

clip_image007

 

Victoire, c'est totalement neutre. Il est donc possible de n'avoir qu'une seule infrastructure ADFS mutualisée pour tous les besoins d'authentification. Par contre, la conséquence, c’est qu’il n’y a plus de SSO pour les exploitants de notre plateforme Windows Azure Pack.

clip_image008

 

Fin du bonus track et fin de la séance de torture. On en a enfin fini avec la partie authentification de Windows Azure Pack, pour les grandes lignes. Maintenant, ce qui serait bien, c’est de consommer du service. Prochaine étape le IAAS avec l’intégration de SCVMM et de Service Provider Foundations. On va donc rajouter des instruments de torture.

 

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

Authentification des locataires de Windows Azure Pack avec ADFS (6/7)

A ce stade, nous n'utilisons le Web Application Proxy que pour sa fonction Proxy pour ADFS mais pas encore pour ses capacités de publication / reverse proxy. Voyons un peu ce qu'on peut faire avec WAP. Lorsqu'on regarde un peu ce que qu'il nous propose, il y a deux choix :

  • Publication en mode pré-authentification ADFS
  • Publication en mode pré-authentification Pass-Throught

 

Commençons par le portail des locataires. Le mode Pass-Throught n'est pas intéressant à ce niveau. Par contre, le mode ADFS va nous permettre de nous assurer que nos locataires se présentent bien avec un jeton d'accès avant même de joindre le portail des locataires. D'un point de vue sécurité, c'est plus qu'intéressant. On va donc suivre cette voie. Avant de commencer, il faut s'assurer que le certificat public pour le portail des locataires de Windows Azure Pack a bien été importé dans le magasin personnel du serveur WAP.

clip_image001

 

Après, c'est dans la console "Remote Access Management Console" que cela se passe. Nous avons un bouton "Publish". C'est lé début d'une séquence "click-next-next-finish".

clip_image002

 

Pour le portail, le choix est logique, on va utiliser ADFS comme méthode de pré-authentification.

clip_image003

 

Pour l'authentification, WAP sait déjà quelle infrastructure ADFS solliciter. Par contre, il a le choix des Relying Parties. Pour notre portail des locataires, c'est donc "Windows Azure Pack Tenant portal".

clip_image004

 

Le WAP est capable de traduire une URL externe en URL interne. Par contre attention, cette réécriture n'est possible que pour le FQDN, pas pour l'URI. Pas possible non plus de changer de protocole en cours de route (HTTPS vers HTTP par exemple). A ce stade, quelques astuces :

  • Ne jamais oublier le "/"
  • Le certificat wildcard est un must to have
  • Etes-vous sur de bien disposer de la clé privée associée au certificat?

clip_image005

 

Pour notre exemple, j'ai volontairement fait simple. Il aurait tout à fait été possible d'avoir un FQDN interne distinct du FQDN externe, voire même pire, un FQDN par locataire, mais là c'est du vice.

clip_image006

 

Le portail des locataires est maintenant publié. Ne reste plus qu'a le tester.

clip_image007

 

Note personnelle : Le wizard du Web Application Proxy détecte bien la présence du certificat. Par contre, il n'est pas regardant quant à la présence de la clé privée qui va avec. On met un certain temps avant de comprendre ce qui se passe. l'évènement 12021 présent dans le journal Microsoft-Windows-WebApplicationProxy/Admin ne nous aide pas vraiment.

 

Testons avec un utilisateur du locataire. En tenant d'accéder au portail https://tenantportal.windowsazurepack.Fr, On est bien redirigé vers l'infrastructure ADFS de notre locataire. On peut utiliser n'importe quel compte AD issu de son domaine.

clip_image008

Note : j'ai volontairement reconfiguré l'infrastructure ADFS du locataire pour désactiver l'authentification intégrée, ce qui force l'utilisateur à s'authentifier.

 

Et ça fonctionne.

clip_image009

 

Pour preuve, dans le portail d'administration, on commence à voir apparaitre des utilisateurs qui ont tous le suffixe UPN "tenant.Fr”. Ces utilisateurs ne sont plus créés / générés par le fournisseur d'identité ASP.Net membership. Windows Azure Pack utilise bien un fournisseur d'identité externe.

clip_image010

 

Note : A ce stade, le fournisseur d'identité ASP.Net membership n'est plus disponible, donc l'utilisateur "benoits@simplebydesign.fr" ne peut plus s'authentifier. Il y a moyen d'y remédier mais ce n'est pas le but de cette série d'article.

OK, on sait que l'UPN issu de l'infrastructure ADFS de notre fournisseur est bien interprété. Qu'en est-il des groupes? Ben ça fonctionne aussi. Ci-dessous un autre utilisateur du même locataire qui a réussi à référencer d'autres co-administrateurs, en utilisant un groupe.

clip_image011

 

Le portail, c'est bien mais voyons comment traiter la publication du de l'API publique des locataires. On va commencer par installer le certificat public (sauf si on a pensé à utiliser un certificat wildcard).

clip_image012

 

C'est dans le WAP que ça va se compliquer. Lorsqu'on attaque Windows Azure Pack en Powershell, la seule méthode d'authentification disponible, c'est le certificat auto-signé. Difficile de faire digérer cela au Web Application Proxy. On va donc publier le tenantpublicapi.windowsazurepack.Fr en mode pass-throught.

clip_image013

 

Tout comme pour le portail, on a une URL externe et une url interne.

clip_image014

 

C'est direct et ça marche immédiatement.

clip_image015

 

Coté client, c'est plus sioux. Déjà, notre locataire a installé son environnement de travail et composé son Kit de survie. Le problème, c'est que par défaut, sa plateforme de développement ne connait que deux environnements :

  • Azure
  • Azure en chine

clip_image016

 

Aucune trace de Windows Azure Pack. Notre locataire doit lui-même déclarer mon service Windows Azure Pack en référençant l'URL de la TenantPublicAPI ainsi que portail des locataires à solliciter : Add-WapackEnvironment -Name "My Windows Azure Pack" - PublishSettingsFileUrl "https://tenantportal.windowsazurepack.fr/publishsettings" -ServiceEndpoint "https://tenantpublicapi.windowsazurepack.Fr"

clip_image017

 

Après avoir référencé son environnement Windows Azure Pack, il n'y a plus qu'à demander le téléchargement du fichier PublishSettings pour notre environnement avec la commande Get-WAPACKPublishSettingsFile -Environment "My Windows Azure Pack". Cela va nous amener sur la page https://tenantportal.windowsazurepack.fr/publishsettings pour télécharger la seule souscription disponible actuellement : SQL Server.

clip_image018

 

Dans le portail, le locataire pourra constater la génération d'un certificat auto-signé.

clip_image019

 

Après, y a plus qu'à faire un import, comme Microsoft Azure :

Import-WAPPAckPublishSettingsFile -PublishSettingsFile 'Test SQL Server Plan-2-9-2015-credentials.publishsettings’ -Environment "My Windows Azure Pack"

clip_image020

 

Notre locataire peut enfin accéder aux services auxquels il a souscrit, que ce soit via le portail ou bien en Powershell. Maintenant, c'est une histoire de certificat auto-signé, comme pour Microsoft Azure. That's end folks.

 

Conclusion

On pourrait penser qu'on conserverait le fournisseur d'identité ASP.Net Membership pour le portail grand public, mais il n'en est rien. Microsoft ne recommande pas l'utilisation de ce fournisseur d'identité pour Windows Azure Pack et préfère qu'on utilise un fournisseur d'identité tiers. ADFS est un bon candidat à ce poste, mais c'est un peu complexe à mettre en œuvre. Ce qu'il faudrait c'est un fournisseur d'identité que nous puissions approuvé et que celui-ci soit reconnu par le plus grand nombre ou qu'il offre des passerelles vers d'autres fournisseurs d'identité. Ce je viens de décrire existe, cela se nomme Microsoft Azure Access Control Service (ACS), c'est un composant du Microsoft Azure Active Directory.

clip_image021

 

Dans cette approche, Windows Azure Pack devient indépendant du fournisseur d'identité final qui peut être aussi bien de l'ADFS, du Windows Azure Active Directory, du Facebook voire même du LiveID de Microsoft. Au passage, tous ces fournisseurs d'identité proposent des mécanismes de réinitialisation de mot de passe, voire même des mécanismes d'authentification forte. Je recommande vivement la lecture de la série de billets suivante sur l'utilisation de Windows Azure Active Directory comme fournisseur d'identité pour les locataires :

 

Vous avez fait le plus dur. Maintenant, c'est que du bonus.

 

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

More Posts Next page »