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

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

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

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

 

Quelle AC pour mes certificats?

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

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

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

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

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

 

FQDN & certificats

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

clip_image001

 

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

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

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

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

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

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

 

Cela amène quelques remarques :

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

 

Bourreau fait ton office!

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

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

clip_image002

 

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

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

clip_image003

 

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

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

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

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

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

clip_image004

 

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

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

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

clip_image005

 

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

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

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

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

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

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

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

clip_image006

 

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

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

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

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

clip_image007

 

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

clip_image008

 

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

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

clip_image009

 

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

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

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

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

clip_image010

 

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

clip_image011

 

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

$Cred = Get-Credential

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

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

clip_image012

 

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

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

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

clip_image013

 

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

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

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

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

clip_image014

 

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

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

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

clip_image015

 

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

 

Le bourreau entretien les braises en attendant la suite.

 

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

Benoit

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

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.