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

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 certificats SSL ainsi que les certificats de signature à échéance du 1er Janvier 2016.

On pourrait penser que cela ne nous impactera jamais mais ce n'est pas le cas. A ce jour, la position de Microsoft est que ses systèmes d'exploitation vont arrêter d'accepter les certificats utilisant SHA-1. 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).

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

 

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

 

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-05-2015 21:13 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)

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

On approche de la fin de la séance de torture, il ne reste plus qu'à reconfigurer le portail des locataires pour ne plus utiliser le fournisseur d'authentification ASP.NET Membership mais l'infrastructure ADFS mise à disposition. Vous reprendrez bien un peu de PowerShell pour la route.

Import-module MgmtSvcConfig

$ADFS = "ADFS.WINDOWSAZUREPACK.FR"

$DBServer = "SQL01.WINDOWSAZUREPACK.LAN"

$DBPassword = "Password123"

$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 tenant -ConnectionString $PortalConfigStoreConnectionString -MetadataEndpoint $MetadataEndpoint

Import-Module WebAdministration

Get-website -name "MgmtSvc-TenantSite" | Stop-Website

Get-website -name "MgmtSvc-TenantSite" | Start-Website

clip_image001

 

C'est presque trop facile.

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

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

C'est un sujet que nous avons déjà traité mais coté portail d'administration. C'est le même principe pour le portail des locataires. Subtilité cette fois, l'identifier sera http://azureservices/tenantSites

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

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

clip_image001

 

Si on regarde, le contenu du fichier federationmetadata.xml du portail des locataires, sa seule exigence, c'est que le jeton d'accès généré contienne un attribut UPN.

clip_image002

 

Jusque-là, pas de surprise. La subtilité, c'est que le portail des locataires de Windows Azure Pack ne reconnait qu'un seul fournisseur d'identité. Donc plus possible de filtrer à ce niveau, on donne tout au portail. Donc UPN pour commencer. Plus possible de filtrer à ce niveau, on doit tout envoyer au portail des locataires de Windows Azure Pack.

clip_image003

 

Même chose pour les groupes afin d'exploiter la fonctionnalité "Co-Administration". le portail des locataires accepte les groupes. Coté locataire, c'est lui qui a décidé de peupler ses jeton d'accès avec les groupes. Nous, on va juste passer le contenu du jeton que nous allons recevoir en provenance de notre locataire.

clip_image004

 

Le truc important, c'est de bien penser à avoir une règle d'autorisation. Vu que nous reconnaissons nos locataires comme fournisseurs d'identité de confiance, on doit leur faire confiance et autoriser l'accès.

clip_image005

 

Mais c'est simple Windows Azure Pack finalement?

 

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

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

Toujours là? Vous en redemandez? Vous avez trouvé cela très "simpliste". OK, élevons un peu le niveau, j'annonce : Web Application Proxy, fournisseur d'identité de confiance seront les nouveaux instruments de torture. J'ai sorti le chevalet, prenez place. Le bourreau va s'occuper de vous.

clip_image001

 

Si on avait fait l'impasse sur le Web Application Proxy (WAP aussi je sais) pour le portail des administrateurs, on ne peut plus y couper pour les locataires. Coté tenant, c'est un peu plus compliqué. Pour les administrateurs, nous utilisions l'annuaire Active Directory "Windowsazurepack.lan" comme fournisseur d'identités. Pour nos locataires, notre fournisseur d'identité par défaut, c'est ASP.Net membership, qui est pris en charge par le module AuthSite de Windows Azure Pack. En plus de fournir l'authentification de nos locataires, il offre deux fonctionnalités importantes :

  • L'enrôlement des locataires en libre-service (Le Sign-up en haut de la page)
  • La réinitialisation de mot de passe (lien forgot password)

clip_image002

 

Mettre en place une authentification ADFS pour nos locataires, cela veut dire que nos locataires auront une mire d'authentification ressemblant à celle-là :

clip_image003

 

C'est un peu plus léger. Certes on peut habiller la chose (merci Maxime Rastello), mais il manque quand même nos "Sign-up" et "Forgot Password". C'est un peu logique. Si nous mettons en place une authentification ADFS, c'est que nous avons un Identity Provider derrière (Active Directory par exemple) et c'est lui qui est en charge des opérations de provisionning d'identité pas Windows Azure Pack. Pareil pour le "Forgot Password". Pour corser un peu plus la chose, un portail de Windows Azure Pack, ne peut utiliser qu'un seul fournisseur d'identité.

C'est un peu bloquant. Dans un scénario de type "Hosting provider", on aimerait bien pouvoir proposer aux locataires de pouvoir venir avec leur propre identité (implique qu'il disposent d'un Security Token Server correctement configuré pour générer des jeton d'accès consommables par Windows Azure Pack) ou d'utiliser une identité tierce. Pour arriver à ce résultat, un moyen, c'est d'avoir plusieurs portails pour les locataires de Windows Azure Pack. Avec cette approche, on pourrait avoir :

  • Un portail grand public
  • Un portail dédié aux entreprises
  • Des portails personnalisés pour les entreprises

Windows Azure Pack autorise cette souplesse. Il est effectivement possible d'avoir plusieurs instances du portail des locataires, chacune d'entre elle utilisant un fournisseur d'identité distinct. C'est une démarche qui est documenté dans cette série de billets : Azure Pack Tenant portal extensibilities.

clip_image004

Pour l'instant, je laisse cette solution de côté. On va déjà voir ce qu'implique une mise en œuvre plus traditionnelle pour nos locataires.

 

Un peu de réflexion pour commencer

Déjà posons-nous la question : Pouvons-nous nous contenter du fournisseur d'identité ASP.Net Membership? Voyons cela de plus près :

  • Auto-enrôlement des utilisateurs : Chaque utilisateur peut venir lui-même créer son propre compte. Celui-ci peut être automatiquement approuvé ou soumis à approbation. Cependant, c'est une identité supplémentaire à gérer pour l'utilisateur. De plus, si coté fournisseur nous devons fournir le service pour tous les utilisateurs d'une entreprise qui a souscrit le service, chaque utilisateur devra s'enrôler manuellement.
  • Gestion de son identité : A part désigner des Co-administrateurs et gérer les certificats d'accès, la gestion des identités vu du locataire est on ne peut plus sommaire. En même temps, c'est pas la fonction première de Windows Azure Pack.

clip_image005

  • Réinitialisation de mot de passe : L'utilisateur peut changer son mot de passe de lui-même et même le réinitialiser. Un mail lui sera envoyé pour générer un nouveau mot de passe. C'est pas mal pour des utilisateurs individuels mais pour des entreprise, c'est un peu limité (pas de jeu de question/réponse, politique de mot de passe spécifique par population, …).

clip_image006

  • Enfin, la gestion des comptes des locataires de Windows Azure Pack : C'est ce qu'il y a de plus sommaire, y a pas plus d'options que celles présentes dans l'interface ci-dessous :

clip_image007

 

Au final, le fournisseur d'identité ASP.Net Membership assure un service minimum. En même temps, c'est pas là qu'on attendait Windows Azure Pack. Ce qu'on attend de lui, c'est d'être capable de s'interfacer avec un autre fournisseur d'identité. C'est certainement pour ces raisons que Microsoft nous recommande d'utiliser un fournisseur d'identité tiers pour nos locataires. ADFS est le premier choix qui vienne à l'esprit. En même temps, c'est la solution la plus simple à mettre en œuvre.

 

Prenons un peu de hauteur

On a déjà abordé le sujet coté Administrateurs, coté locataires, c'est presque la même chose. La seule différence, c'est que le jeton ne sera pas généré par notre infrastructure ADFS (windowsazurepack.Fr) mais par l'infrastructure ADFS de notre locataire, laquelle nous reconnaissons le statuts de fournisseur d'identité. Coté infrastructure, voilà ce que cela donne :

clip_image008

 

Ça commence à piquer les yeux. Et encore, j'ai fait le choix d'utiliser l'infrastructure ADFS déjà existante (sans haute disponibilité) pour l'authentification de mes futurs locataires. C'est tout à fait envisageable tant que nous pouvons bien distinguer les différents fournisseurs d'identité avec des suffixes UPN bien distincts. C'est sur ce point que ça va devenir fun.

Une fois en place, la cinématique de connexion sera la suivante :

  1. Un utilisateur au sein d'un de nos locataires veut accéder au portail https://tenantportal.windowsazurepack.fr
  2. Le portail constatant l'absence de jeton va le renvoyer vers notre infrastructure ADFS (En fait, c'est même le Web Application Proxy qui va se charger de cela)
  3. L'infrastructure ADFS (windowsazurepack.Fr) demande à l'utilisateur de renseigner son adresse de messagerie ou la notation UPN de son compte
  4. En fonction des données renseignées, notre infrastructure ADFS va identifier le suffixe UPN et rediriger l'utilisateur vers l'infrastructure ADFS du locataire pour authentification
  5. L'infrastructure ADFS du locataire va authentifier l'utilisateur et générer un jeton d'accès signé pour l'utilisateur en sollicitant l'annuaire Active Directory du locataire comme fournisseur d'identité
  6. L'infrastructure ADFS du locataire va renvoyer l'utilisateur vers le portail https://tenantportal.windowsazurepack.fr pour que celui consomme le jeton
  7. Le portail sollicite l'infrastructure ADFS de Windows Azure Pack pour délivrer un nouveau jeton en utilisant les informations contenues dans celui qui a été généré par l'infrastructure ADFS de notre locataire (notion de confiance dans le fournisseur d'identité)
  8. L'infrastructure ADFS de Windows Azure Pack renvoie l'utilisateur vers le portail https://tenantportal.windowsazurepack.fr pour que celui-ci exploite le jeton signé

 

Si nos clients ne disposent pas encore d'une infrastructure ADFS, on va les aider. Sur cette partie, j'ai pas de plus-value, le travail a déjà été très bien fait et c'est en français. C'est du Next-Next-Finish direct dans Azure :

 

Après, cela va se dérouler en plusieurs étapes que je vais publier progressivement :

 

Prêt pour le début de la séance? Patience, ça arrive. Détendez-vous, …

 

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

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

Recevoir des jeton d'accès en provenance de notre futur locataire, cela implique de le reconnaitre comme fournisseur d'identité (IP). Notre infrastructure ADFS doit donc référencer l'infrastructure ADFS de notre nouveau locataire comme fournisseur d'identité de confiance (IP). On va donc déclarer un nouveau "Claims Provider trust".

clip_image001

 

C'est l'ADFS de notre futur locataire.

clip_image002

 

C'est sous ce nom que le fournisseur d'identité sera référencé dans la mire d'authentification ADFS.

clip_image003

 

La configuration est presque terminée.

clip_image004

 

On n'a plus qu'à causer des règles à appliquer pour générer des jetons d'accès que le portail pourra consommer. Le portail des locataires de Windows Azure Pack ne reconnait qu'un seul fournisseur, l'infrastructure ADFS à laquelle il a été connectée. C'est uniquement de lui qu'il va accepter les jetons d'accès.

clip_image005

 

Y a moins d'onglets mais on va procéder de la même manière.

clip_image006

 

Maintenant, deux petites règles pour filtrer. La première pour s'assurer que l'UPN contient bien le suffixe UPN que nous avons associé à notre futur locataire.

clip_image007

 

Et la seconde pour bien récupérer tous les groupes issus du claims initial.

clip_image008

 

Au final, cela nous fait deux règles.

clip_image009

 

La seule chose importante dans le jeton que nous venons de recevoir contient bien l'UPN que nous attentons en provenant de ce locataire. Notre infrastructure ADFS reconnait maintenant deux fournisseurs d'identités.

clip_image010

 

Maintenant, on va aider un peu les choses. Pour éviter que notre locataire se voit proposer tous les fournisseurs d'identité disponibles, on va configurer le RelyingParty dédié au portail des locataires de Windows Azure Pack pour limiter les fournisseurs d'identité proposés. C'est une fonctionnalité native d'ADFSV3. C'est configurable au niveau du "Relying Party Trust" avec la propriété ClaimsProviderName.

Import-module Adfs

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

clip_image011

 

On va peupler cette propriété avec le nom du fournisseur d'identité de notre premier locataire.

Set-AdfsrelyingPartyTrust -TargetName "Windows Azure Pack Tenant portal" -ClaimsproviderName @("adfs.tenant.Fr")

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

clip_image012

 

Question bête mais on va forcément avoir plusieurs locataires qui se connectent sur le portail? Oui, donc à chaque nouveau locataire on viendra enrichir la propriété.

 

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

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

Notre futur locataire doit être en mesure de générer un jeton d'accès qui sera consommé par le portail des locataires de Windows Azure Pack. Le contenu de ce jeton d'accès devra contenir au minimum l'UPN des utilisateurs, voire l'appartenances aux groupes. C'est notre locataire qui va générer le jeton d'accès. Son serveur ADFS étant membre de son domaine Active Directory, ce dernier qui devra être référencé comme fournisseur d'identité. Notre locataire devra référencer notre infrastructure ADFS comme Relying Party. C'est le Web Application Proxy qui joue le rôle d'ADFS Proxy qui va répondre pour l'URL : https://Adfs.windowsazurepack.fr/Federationmetadata/2007-06/federationmetadata.xml

clip_image001

 

Notre locataire peut conserver le FQDN public par défaut de l'infrastructure ADFS de Windows Azure Pack.

clip_image002

 

Imposer une authentification force par le locataire, c'est une fausse bonne idée. Autant ça va fonctionner pour l'accès au portail, autant pour l'accès au TenantPublicAPI, ça va pas être possible.

clip_image003

 

Par contre, notre locataire peut sélectionner lesquels de ses utilisateurs pourront accéder à nos services. Charge au locataire de bien définir quel critère utiliser (attribut, appartenance de groupe, rôle, …).

clip_image004

 

Le Replying Party trust est en place. Reste quelques détails que nous connaissons déjà.

clip_image005

 

Le seul attribut obligatoire exigé par le portail des locataires de Windows Azure Pack. Notre locataire va donc se conformer avec une règle "Send LDAP Attributes as Claims" et simplement mapper l'attribut "User-Principal-Name" issu de son fournisseur d'identité (Active Directory) et le mapper sur l'attribut UPN dans le jeton d'accès à générer.

clip_image006

 

Coté infrastructure ADFS, nous devons pouvoir clairement identifier le fournisseur d'identité de chacun de nos clients. Il ne faut pas que deux clients utilisent le même suffixe UPN. Pour éviter les conflits, on va imposer à nos locataire de n'inclure dans le jeton d'accès qu'un seul UPN. Pour cela nous devons retoucher le jeton d'accès avec une règle de type "Pass Throught of Filter an incoming Claim".

clip_image007

 

Nous allons retraiter l'attribut UPN pour nous assurer que celui-ci ne contienne que l'UPN unique que nous avons associé à notre locataire.

clip_image008

 

Pour les locataires, la présence des groupes dans le jeton n'est pas obligatoire mais vivement recommandée pour exploiter la fonctionnalité de "Co-Administration" d'un tenant. Le propriétaire d'un tenant dans Windows Azure Pack peut désigner des Co-Administrateurs. Pour cela, il faut donc que les jeton d'accès contienne des groupes.

clip_image009

 

Par contre, ce qu'il faut savoir, c'est que Windows Azure Pack n'aime pas les espaces dans les noms des groupes. Un sujet à communiquer à notre futur locataire.

clip_image010

 

C'est au choix du locataire. S'il ne veut pas utiliser la fonctionnalité de "Co-Administration", c'est son choix. S'il veut l'utiliser, On doit donc peupler l'attribut. Pour faire simple, on va utiliser une règle de type "Send LDAP Attributes as Claims".

clip_image011

 

On peuple de la même manière que pour l'UPN, sauf que nous prenons soin de bien utiliser l'attribut Token-groups - Qualified by Long Domain Name" pour peupler l'attribut "group" du jeton d'accès.

clip_image012

 

A noter qu'avec cette approche, le locataire va envoyer tous les groupes sont ses utilisateurs sont membres. Techniquement, il est possible de filtrer le contenu des groupes référencés dans le jeton d'accès. Pour cela, je vous renvoie en révision vers la précédente séance de torture. Pour les autres, notre locataire a donc trois règles pour construire son jeton d'accès.

clip_image013

 

Vu qu'on peut pas faire autrement, nous devons demander à notre locataire d'exécuter trois commandes Powershell:

Import-Module ADFS

Set-ADFSRelyingPartyTrust -Targetidentifier http://adfs.windowsazurepack.Fr/adfs.services/trust -EnableJWT $True

Get-ADFSRelyingPartyTrust -Name adfs.windowsazurepack.fr | Select EnableJWT

clip_image014

 

Tout cela n'était pas trop compliqué pour notre futur locataire. Il a fait au plus simple. Pour les gestionnaires de l'infrastructure Windows Azure Pack, c'est maintenant que la séance de torture commence. Avant de clore quelques points complémentaires pour compléter la mise en œuvre de l'infrastructure ADFS de notre locataire :

  • Alternate Login ID
  • Extranet account lockout protection

 

Alternate login ID

Il se peut que notre locataire ne puisse pas utiliser leur suffixe UPN pour d'authentifier auprès de notre infrastructure ADFS. C'est par exemple le cas si le suffixe UPN est non routable (.local par exemple). Si notre locataire ne peut pas changer le suffixe UPN, jusqu'à récemment la solution était d'utiliser une règle "Pass Throught of Filter an incoming Claim" pour positionner le bon UPN dans le jeton d'accès. Avec la mise à jour Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 update: April 2014, on dispose maintenant de la fonctionnalité Alternate ID Login. Je recommande la lecture du billet suivant : Introduction to Active Directory Federation Services (AD FS) AlternateLoginID Feature.

 

Extranet account lockout protection

Mettre en place une infrastructure ADFS, c'est aussi exposer nos comptes. Rien n'est plus aisé que de deviner l'UPN d'un utilisateur, généralement, c'est l'adresse de messagerie de l'utilisateur. Heureusement, ADFSv3 propose la fonctionnalité "Extranet Account Lockout protection" qui permet de bloquer les tentatives d'accès externes frauduleuses pendant une certaine période de temps sans challenger l'annuaire Active Directory. Il est donc beaucoup plus difficile de verrouiller des comptes massivement. La mise en place de cette fonctionnalité est vivement recommandée :

 

Bien entendu, ces recommandations d'appliquent aussi du côté de l'infrastructure ADFS coté Windows Azure Pack.

 

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

Windows Azure Pack Update Rollup 5

La livraison de l’Update Rollup 5 de la gamme System Center 2012 R2 est disponible :

A noter que l’Update Rollup de SCVMM 2012 R2 inclus la prise en charge de la vulnérabilité MS015-017 : Vulnerability in Virtual Machine Manager could allow elevation of privilege. Logiquement, on a donc aussi un  : Update Rollup 5 for Windows Azure Pack apportant son lot de corrections ainsi que quelques nouveautés :

  • Support de SQL Governor dans le SQL Resource Provider
  • Présentation des détails de configuration des machines virtuelles aux locataires (mémoire fixe / dynamique, mémoire au démarrage, mémoire minimale et maximale)
  • Correction de la commande Powershell Get-MgmtSvcRelyingPartySettings (ça évitera que je confonde les Relying Parties)
  • Correction de la problématique de connexion console RDP via translation d’adresse

 

L’installation de toute nouvelle plateforme Windows Azure Pack va donc automatiquement utiliser la version de l’Update Rollup 5. Pour les installations existantes, pensez à bien suivre la procédure de mise à niveau, y a une spécificité pour activer la prise en charge de SQL Governor.

 

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

Nouvelles versions d’ADMPWD

J'ai déjà publié quelques billets sur ADMPWD d'une mise en œuvre classique, jusqu'à son intégration dans des processus complexes avec SCSM. Fin novembre 2014, la solution avait été mise à jour pour intégrer un mécanisme de protection contre les politique d'expiration de mot de passe abusive. Ca permettait d'éviter qu'on puisse éviter qu'ADMPWD ne renouvèle le mot de passe avec une date d'expiration trop lointaine.

clip_image001

 

Début Janvier 2015, l'auteur nous gratifiait d'une dernière version en intégrant :

  • Correction de la valeur "SearchFlags" dans l'extension de schéma pour éviter que le mot de passe ne soit notifié dans les audit tracking de Windows Server 2012/2012 R2
  • La création des comptes administrateurs locaux directement dans le package d'installation

clip_image002

 

Mais l'auteur nous promettait une nouvelle version avec plein de fonctionnalités sexy.

clip_image003

 

Bonne nouvelle, cette nouvelle version existe. Mauvaise nouvelle, elle sera dédiée aux clients ayant souscrit un contrat du support Premier ;). En contrepartie, beaucoup de nouveautés :

  • Prise en charge du chiffrement des mots de passe dans l'Active Directory
  • Diffusion de la clé de chiffrement par GPO
  • Configuration automatique des agents ADMPWD par mécanisme d'auto-découverte
  • Mise à disposition d'un Web Service pour gérer la révélation des mots de passe sécurités par ADMPWD
  • Une interface Web

clip_image004

 

Par contre implique un nouvel attribut pour prendre en compte l'historique des mots de passe. Si la solution vous intéresse, je vous recommande de consulter la présentation suivante : https://sway.com/OFNqS4N9i5d3neb_

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

Intégration du Resource Provider Service Management Automation à Windows Azure Pack

Séance légère aujourd'hui. On va faire une pause avec les scénarios d'authentification de Windows Azure Pack et installer un nouveau Resource Provider : Service Management Automation. SMA est la nouvelle génération de solution d'automatisation de Datacenter de Microsoft. C'est toujours des Runbook mais uniquement en Powershell, plus précisément des workflow Powershell.

Du point de vue Architecture, Service Management Automation reprend un certain nombre de principes que nous connaissons avec Orchestrator 2012 R2. Au passage SMA est disponible sur le média d'installation de ce dernier.

Windows Azure Pack va venir s'interfacer avec le Web Service de SMA via un Resource Provider installé par défaut mais pas encore configuré. Ce Web Service va piloter une ou plusieurs instances de Runbook Workers qui viendront chercher des jobs déclarés dans la base de données de SMA, voilà pour la version courte.

clip_image001

 

Là où cela devient subtil, c'est que c'est le portail d'administration de Windows Azure Pack qui est la console d'administration de SMA. Prêt pour une rapide séance de torture? Le déploiement en lui-même du produit ne pose pas de problème particulier, c'est disponible sur le Technet à cette adresse : Deploy Service Management Automation. Il y a juste quelques prérequis, pas bien méchant :

  • On sait qu'il faudra une base de données SQL Server proposant de l'authentification Windows intégrée
  • On sait qu'il faudra avoir préalablement créé un groupe AD représentant les administrateurs de la plateforme Service Management Automation (qui sera membre du groupe local administrators)
  • On sait qu'il faudra avoir un compte de service membre du dit groupe et que celui-ci sera utilisé pour faire fonctionner les services de SMA

Là où cela va coincer, c'est qu'on va nous parler de certificats. Par défaut, Microsoft vous propose de générer un certificat auto-signé. Autant dire qu'avec Windows Azure Pack, ça va pas le faire, surtout avec une installation distribuée.

clip_image002

 

Si vous avez déjà installé votre Service Management Automation, avec un certificat auto-signé, je vous conseille vivement de suivre la procédure suivante : Post-installation tasks for Service Management Automation. On s'évitera ainsi quelques "nervous breakdown" avec les certificats et les Resource Providers. Le certificat sera présent sur tous les serveurs hébergeant le rôle SMA Web Service. Il n'a pas besoin d'être délivré par une autorité de certification publique car les locataires n'ont pas accès à SMA.

Service Management Automation est vu par Windows Azure Pack comme un Resource Provider qui vient fournir des services à destination des administrateurs de la plateforme Windows Azure Pack. Le nœud "Automation" n'attendait que nous. Il nous propose de référencer le Web Service de notre infrastructure SMA.

clip_image003

 

Le processus est assez direct. Il faut juste fournir l'URL pour joindre le dit Web Service et fournir le compte de service à utiliser pour se connecter à l'infrastructure SMA. Cette information a été communiquée à la fin du processus d'installation de SMA.

clip_image004

 

Quelques secondes plus tard, oh magie, le Resource Provider Service Management Automation est bien déclaré.

clip_image005

 

Vu que nous avions prévu d'utiliser un véritable certificat avant d'installer SMA, l'enregistrement du Resource Provider s'est effectué avec le FQDN indiqué. On n'a donc plus rien à corriger. Snif, le bourreau n'a pas de nouvel instrument de torture à essayer.

clip_image006

 

Au passage, vu que mon infrastructure utilise maintenant ADFS pour l'authentification des administrateurs, plus possible d'utiliser Get-MgmtSvcToken, c'est un bug référencé. Ce même script est aussi disponible sur nos serveur Windows Azure Pack, préalablement personnalisé pour chaque scénario :

clip_image007

 

Fin de cette courte séance de torture? Oui car pour continuer avec Service Management Automation, il faut plonger dans Service Provider Foundations. Et là, ce sera une véritable séance de torture. C'est pour bientôt

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

La cryptographie expliquée au format A3

Lorsqu’on fait de l’analyse de flux réseau (Network Monitor / Message Analyzer), on passe beaucoup de temps avec des termes barbares liés à la sécurité. Le problème, c’est qu’il y en a beaucoup et qu’on sait pas toujours dans quelle catégorie les classer ou même savoir si c’est le plus sécurisé qui se présente devant nous. Donc un grand merci à Erez Benari (un historique des produits IAG/UAG) pour cette infographie.

[Cryptographic%2520Protocols%2520and%2520concepts%2520poster%2520012015%2520Wallpaperjpg%255B4%255D.jpg]

 

A imprimer au format A3 et à regarder à chaque fois qu’on fait de l’analyse protocolaire.

 

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

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)

More Posts Next page »