Archives mensuelles : janvier 2015

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

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)