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

Salle de torture "Cœur de Windows Azure Pack" (suite)

Il faut battre le fer quand il est chaud et torturer quand la chair est encore tendre. Dans la précédente salle de torture, nous avons traité uniquement les modules privé de Windows Azure Pack. Il nous reste encore les modules publics isolés sur notre second serveur Windows Azure Pack. Un petit rappel s'impose.

clip_image001

Va vous reviens? Bien, voyons ce qui nous attend coté certificats :

clip_image002

C'est déjà bien moins fourni. La séance de torture sera donc plus courte puisque seulement trois Web Services sont au programme :

  • AuthSite
  • TenantPublicAPI
  • TenantSite

Ce ne sont pas des inconnus pour nous. Coté zone DNS, ils dépendront de la zone DNS publique "Windowsazurepack.fr". Pour les mêmes raisons que dans le billet précédent, il nous faut aussi remplacer les ports de publication par défaut par des ports normalisés (TCP 443). Cela impliquera donc de répartir les Web Services sur différentes adresses IP. Le tableau ci-dessous référence les transformations que nous allons faire subir à nos Web Services.

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

AuthSite https://localhost:30071 192.168.5.106 https://TenantAuthSite.windowsazurepack.fr:443
TenantPublicAPI https://localhost:30006 192.168.5.107 https://tenantpublicapi.windowsazurepack.fr:443
TenantSite https://localhost:300081 192.168.5.105 https://tenantportal.windowsazurepack.Fr:443

 

Il reste quand même pas mal de travail. Cette séance se découpera en deux parties :

  • La partie émergée de l'iceberg avec le portail des locataires et le site web d'authentification
  • La partie submergée de l'iceberg avec la partie publique de l'API des locataires

 

La partie émergée de l'Iceberg

Pour les modules publics, il faut tenir compte de l'expérience utilisateur de nos futurs locataires. La première chose qu'ils verront, c'est leur portail. On va donc personnaliser URL et le port pour qu'ils puissent utiliser 'https://tenantportal.windowsazurepack.fr'. Pour les détails plus complet, voir le billet Personnalisation des URL de Windows Azure Pack. Jusqu'ici on est en terrain connu, ça fait que chatouiller. Normal, on fait que commencer.

clip_image003

 

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

Comme pour le portail d'administration, il y a un web service chargé d'authentifier les utilisateurs se connectant au portail des locataires. Dans IIS, c'est le site web "MgmtSvc-AuthSite" qui utilise ASP.NET Membership comme fournisseur d'authentification. Pour faire simple, derrière, le fournisseur d'authentification sera la base de données SQL Server de Windows Azure Pack.

Vu que c'était trop simple, j'ai décidé de corser un peu les choses et introduit quelques changements. Premier point, j'utilise un FQDN distinct de celui du portail des locataires. Ça permet d'introduire plus tard une séparation entre le portail des locataires et le Web Service en charge de l'authentification. C'est bon pour la montée en charge. Pour l'instant, les deux sont sur le même hôte mais qui sait, si le succès est au rendez-vous, il faudra bien être prêt à tenir la charge. Pour améliorer l'expérience utilisateur, j'ai retenu de binder le Web Service sur le port 443, comme le portail. Pour éviter les conflits au niveau IIS (et de devoir utiliser Server Name Indication (SNI)), j'ai donc introduit une nouvelle adresse IP sur mon serveur Windows Azure Pack Public.

clip_image004

Certes SNI a ses avantages mais aussi ses inconvénients :

J'ai toujours votre attention? Bien. On va commencer par quelques sujets simples : Reconfigurer l'URL du portail des locataires de Windows Azure Pack. L'objectif est de présenter "https://tenantportal.windowsazurepack.fr" à nos futurs locataires et de se préparer à la haute disponibilité.

Get-MgmtsvcFqdn -Namespace "TenantSite" -Server "SQL01.WindowsAzurepack.Lan"

Set-MgmtSvcFqdn -NameSpace "TenantSite" -FullyQualifiedDomainName "Tenantportal.Windowsazurepack.Fr" -port 443 -Server "SQL01.Windowsazurepack.lan"

clip_image005

Après le portail, le site d'authentification associé. C'est le même principe mais avec le FQDN 'https://tenantAuthSite.WindowsAzurepack.fr'. C'est vers lui que les demandes d'authentification vont être redirigées sur le port 443. C'est plus user-friendly.

Get-MgmtSvcFqdn -Namespace "AuthSite" -Server "SQL01.WindowsAzurePack.lan"

Set-MgmtSvcFqdn -Namespace "AuthSite" -FullyQualifiedDomainName "Tenantauthsite.windowsazurepack.fr" -port 443 -Server "SQL01.WindowsAzurePack.lan"

clip_image006

Les FQDN posés, on peut maintenant référencer le 'https://tenantAuthSite.WindowsAzurepack.fr' comme URL pour le fournisseur d'identité. C'est une information que nous devrons référencer dans la base de données. On va donc créer une variable pour stocker le 'connectionstring' de notre base SQL ainsi qu'une autre variable qui référence le FQDN du partenaire de confiance vers lequel la demande d'authentification va être redirigée.

$Connectionstring = "Data Source=SQL01.Windowsazurepack.lan;User ID=SA;Password=*************"

$federationmetadata = "https://tenantauthsite.Windowsazurepack.fr/federationmetadata/2007-06/federationmetadata.xml"

Get-MgmtSvcRelyingPartySettings -Target "Tenant" -Server "SQL01.WindowsAzurepack.lan" | Format-List

Set-MgmtSvcRelyingPartySettings -Target "Tenant" -MetadataEndpoint $federationmetadata -ConnectionString $Connectionstring

clip_image007

Comme pour le portail d'administration, si on est redirigé pour authentification, il faudra bien revenir au portail et présenter le claims à consommer. Pour cela on doit l'indiquer à notre fournisseur d'authentification. Dans l'état actuel de notre plateforme c'est le ASP.NET Membership. Faut juste savoir à quelle URL on va rediriger.

$Federationmetadata = "https://tenantportal.windowsazurepack.fr/Federationmetadata/2007-06/federationmetadata.Xml"

Get-MgmtSvcIdentityProviderSettings -Target "Membership" -Server "SQL01.Windowsazurepack.lan"

Set-MgmtSvcIdentityProviderSettings -Target "Membership" -MetadataEndpoint $Federationmetadata -ConnectionString $Connectionstring

clip_image008

A ce stade, le portail doit être accessible. Certes, il n'y a pas encore de locataire mais on peut déjà tester la fonction "Sign-up" pour être un early-adopter:)

clip_image009

Dans la configuration actuelle de Windows Azure Pack, rien n'interdit à un utilisateur de créer son propre compte (on avait déjà vu que c'était possible). Par contre, notre installation n'inclus aucun "ressource provider" et encore moins de "plan" auquel l'utilisateur peut s'abonner. Le portail est bien opérationnel mais y a rien à consommer. Aller circulez, y a plus rien à voir en surface.

clip_image010

 

La partie submergée de l'iceberg

Comme vu dans le billet Windows Azure Pack–Les APIs publiques des locataires, le portail, ce n'est que la surface d'un service cloud digne de ce nom. En dessous, on a des API que nos locataires peuvent accéder pour exploiter les ressources mises à disposition. La première chose que nos futurs locataires vont voir, c'est le la partie publique du TenantAPI disponible sur le serveur public de Windows Azure Pack. Encore un certificat auto-signé à remplacer dans IIS.

clip_image011

 

Note : Redémarrer le site web est encore essentiel. On va écraser le binding actuel, le TenantPublicAPI ne répondra plus.

Maintenant, on commence à le savoir, changer l'information dans IIS, c'est bien mais si on ne la change pas aussi dans la base de données de Windows Azure Pack, on va pas aller bien loin. Donc acte.

Get-MgmtSvcFqdn -Namespace 'TenantPublicAPI' -ConnectionString $ConnectionString | Format-Table -AutoSize

Set-MgmtSvcFqdn -Namespace 'TenantPublicAPI' -ConnectionString $ConnectionString -FQDN "tenantpublicapi.windowsazurepack.fr" -Port 443

clip_image012

Tout comme pour le module TenantAPI, il faut corriger le paramètre DisableSSLCertvalidation. Comme l'indique le mode Verbose de la commande Get-MgmtsvcSetting, l'opération consiste à ajouter un paramètre dans le fichier Web.Config du site web.

Get-MgmtSvcSetting -namespace "TenantPublicAPI" | Format-Table

Set-MgmtSvcSetting -namespace "TenantPublicAPI" -Name "DisableSslCertValidation" -Value False -Verbose

clip_image013

 

Si tout se passe bien, l'API publique des locataires est accessible via l'url 'https://tenantpublicapi.windowsazurepack.fr'. Le dire c'est bien mais le prouver c'est mieux. On avait déjà abordé le sujet dans le billet "Windows Azure Pack–Les APIs publiques des locataires".

Cependant, on doit interrompre la séance de torture. Dans cette installation, nous n'avons pas encore abordé le sujet des "Resources providers". Or sans eux, pas de ressources à proposer dans un “plan” auquel le locataire pourrait souscrire. Pour valider que cela fonctionne bien, il faudra mettre en œuvre un premier Resource Provider". Ça tombe bien, ce sera le sujet de notre prochaine séance de torture.

 

Vous pensiez sérieusement en avoir fini? Mais c’était que l’échauffement.

 

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

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

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

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

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

 

Quelle AC pour mes certificats?

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

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

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

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

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

 

FQDN & certificats

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

clip_image001

 

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

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

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

Web Service

Ancienne URL

Adresse IP

Nouvelle URL

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

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

 

Cela amène quelques remarques :

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

 

Bourreau fait ton office!

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

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

clip_image002

 

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

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

clip_image003

 

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

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

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

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

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

clip_image004

 

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

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

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

clip_image005

 

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

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

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

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

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

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

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

clip_image006

 

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

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

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

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

clip_image007

 

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

clip_image008

 

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

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

clip_image009

 

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

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

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

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

clip_image010

 

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

clip_image011

 

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

$Cred = Get-Credential

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

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

clip_image012

 

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

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

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

clip_image013

 

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

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

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

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

clip_image014

 

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

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

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

clip_image015

 

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

 

Le bourreau entretien les braises en attendant la suite.

 

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

Installation du cœur de Windows Azure Pack

On a posé les bases de l'architecture, entrons dans la salle de torture. Il faut commencer par construire un cœur solide. La montée en charge n'est pas encore au programme de ce billet mais on va tenter de faire ça bien pour que le moment venu, ce ne soit qu'une formalité ou presque. On va commencer par les formalités administratives.

 

Formalités administratives

Circulez, y a rien à voir sinon une belle ligne de commande Powershell à se coltiner. Au passage, il y a bien le DVD d'installation de Windows Server 2012 R2 dans mon lecteur de DVD pour permettre l'installation du Framework 3.5 (Enable .NET Framework 3.5 by using the Add Roles and Features Wizard)

Add-WindowsFeature FileAndStorage-Services,Storage-Services,Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Basic-Auth,Web-Url-Auth,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Ftp-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Scripting-Tools,NET-Framework-Features,NET-Framework-Core,NET-Framework-45-Features,NET-Framework-45-Core,NET-Framework-45-ASPNET,NET-WCF-Services45,NET-WCF-HTTP-Activation45,NET-WCF-TCP-PortSharing45,ManagementOdata,FS-SMB1,User-Interfaces-Infra,Server-Gui-Mgmt-Infra,Server-Gui-Shell,PowerShellRoot,PowerShell,PowerShell-V2,PowerShell-ISE,WAS,WAS-Process-Model,WAS-Config-APIs,WoW64-Support -source "d:\source\sxs\"

clip_image001

 

Récupération des sources de Windows Azure Pack

Vu que ce sera le cœur de notre réseau, pas vraiment d'accès Internet ou alors le minimum vital. Pour cette raison, on va commencer par récupérer les sources d'installation avec le Web Plateform Installer. Dans le dernier cercle de l'enfer, on avait déjà expérimenté cette approche. Pour rappel, voilà ce que propose le WEBPICMD.EXE :

clip_image002

 

On a tout ce qu'il nous faut et on va lancer le téléchargement avec la ligne WEBPICMD-X64.EXE /Offline /products:"Wap_SingleMachineInstallation" /path:"c:\sources"

/xml:https://www.microsoft.com/web/webpi/5.0/WebproductList.xml

/log:"c:\temp\log.txt"

clip_image003

 

Pour rappel le fichier XML (dit Feed) sera utilisé ultérieurement pour réaliser les installations "offline". Après un peu de temps, on arrive enfin à la fin des téléchargements.

clip_image004

Source : Troubleshooting Installation of Windows Azure Pack

 

Installation du cœur de Windows Azure Pack

Le Web Plateform Installer a téléchargé les packages en relation avec Windows Azure Pack. On en a même une liste. C'est celle-ci que nous utilisons comme "primary feed" pour réaliser l'installation du cœur de Windows Azure Pack.

clip_image005

 

Tous les packages en relation avec Windows Azure Pack sont référencés dans la section "Products". L'interface nous indique bien que la liste des produits est issue de notre fichier XML offline.

clip_image006

 

C'est maintenant que nous faisons nos courses des modules à installer :

  • Windows Azure Pack Admin Site
  • Windows Azure Pack Authentication Site
  • Windows Azure Pack Admin API
  • Windows Azure Pack Tenant API
  • Windows Azure Pack PowerShell API
  • Windows Azure Pack Best Practice Analyzer

clip_image007

 

Nos modules sont en attente d'installation. l'interface ci-dessous permet de récupérer les éventuels modules complémentaires qui ont des dépendances avec nos modules. C'est par exemple le cas du portail d'administration de Cloud Cruiser (un bijoux).

clip_image008

 

Comme vu dans le billet Windows Azure Pack - Les updates de System Center, Windows Azure Pack est lié à la gamme System Center pour ses mises à jour. Au jour de l'écriture de ce billet, ce sera donc Update 4.

clip_image009

 

Note : Attention à bien désinstaller la KB2990942 avant d'installer le Rollup 4 for System Center 2012 R2 and Azure Pack (KB2992027). Il sera possible de réinstaller la KB2990942 après.

La mise en place initiale de nos modules est maintenant terminée.

clip_image010

 

A ce stade, notre cœur n'est pas encore vraiment opérationnel sans une configuration initiale.

clip_image011

 

Configuration initiale du cœur de Windows Azure Pack

La configuration initiale de Windows Azure Pack, c'est très simple : Qu'est-ce que tous ces composants vont bien avoir en commun? Une base de données SQL Server pour y stocker leurs informations respectives et au passage savoir comment localiser les autres modules. La seule particularité, c'est qu'on utilise une authentification SQL Server et non une authentification intégrée.

clip_image012

 

Pour être sûr que seuls des composants de Windows Azure Pack puisse accéder à la base de données SQL partagée, il y a une phrase secrète partagée par tous. Il faut la mettre de côté car sans elle, pas possible d'installer / réinstaller de nouveaux serveurs.

clip_image013

 

Une fois le cœur installé, on pourra constater que le portail d'administration est bien opérationnel.

clip_image014

 

Ca y est, ça pulse. Coté certificats, c'est moins pire qu'une installation mono-serveur avec tous les rôles installés sur un même serveur. On aura donc du travail. Heureusement on a déjà travaillé le sujet.

clip_image015

 

C'était juste une piqure de rappel. Pour l'instant on reste sur des choses accessibles. Il en sera de même pour le prochain billet. Mais ça pourra pas durer bien longtemps.

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

Identifier les GPO préparées pour ADMPWD

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

 

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

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

$allGPOs | ForEach-Object {

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

    {

        $content = $_.Properties.gpcmachineextensionnames

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

{

            $_.Properties.displayname

        }

    }

}

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

Installation des modules public de Windows Azure Pack

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

 

Formalités administratives

Comme pour le cœur de réseau, il y a quelques formalités administratives à respecter. Un peu de PowerShell et on en parle plus. Pour rappel, il y a bien le DVD d'installation de Windows Server 2012 R2 dans mon lecteur de DVD pour permettre l'installation du Framework 3.5 (Enable .NET Framework 3.5 by using the Add Roles and Features Wizard)

Add-WindowsFeature FileAndStorage-Services,Storage-Services,Web-Server,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Static-Content,Web-Health,Web-Http-Logging,Web-Request-Monitor,Web-Http-Tracing,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Basic-Auth,Web-Url-Auth,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Ftp-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Scripting-Tools,NET-Framework-Features,NET-Framework-Core,NET-Framework-45-Features,NET-Framework-45-Core,NET-Framework-45-ASPNET,NET-WCF-Services45,NET-WCF-HTTP-Activation45,NET-WCF-TCP-PortSharing45,ManagementOdata,FS-SMB1,User-Interfaces-Infra,Server-Gui-Mgmt-Infra,Server-Gui-Shell,PowerShellRoot,PowerShell,PowerShell-V2,PowerShell-ISE,WAS,WAS-Process-Model,WAS-Config-APIs,WoW64-Support -source "d:\source\sxs\"

clip_image001

 

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

clip_image002

 

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

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

clip_image003

 

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

clip_image004

 

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

clip_image005

 

Note : Attention à bien désinstaller la KB2990942 avant d'installer le Rollup 4 for System Center 2012 R2 and Azure Pack (KB2992027). Il sera possible de re-installer la KB2990942 après.

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

clip_image006

 

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

clip_image007

 

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

clip_image008

 

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

 

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

Installation distribuée de Windows Azure Pack - Inauguration

J'inaugure un nouveau tag : Dungeon keeper. Comme déjà dit, Windows Azure Pack, c'est un peu une salle de torture tellement c’est disruptif avec que qu’on avait l’habitude de voir chez les produits Microsoft.

Ça correspond tout à fait à Dungeons keeper. On est nombreux à avoir joué à ce jeux sur PC et on est encore nombreux à y jouer sur tablettesTire la langue.

Cette série de billet a pour objectif de documenter la mise en place d'une installation distribuée de Windows Azure Pack dans un environnement aussi réaliste que possible. Je dis bien aussi réaliste que possible, dans la mesure des moyens de ma maquette.

Pour ce premier billet, on va déjà poser les bases de notre maquette avec un beau Visio. Attention, c'est une série sans fin, je sais pas encore quand je vais m'arrêter. D’où le Tag "Dungeon Keeper (Windows Azure Pack)". Aller on se lance.

clip_image001

Partons des bas-fonds du donjon avec la zone sécurité pour notre annuaire Active Directory "technique" nommé "Windowsazurepack.lan" et l'ADFS qui y sera associé. Je dis bien annuaire technique car je sais déjà qu'il n'aura aucune vocation à fournir les services d'authentification et d'autorisation pour mes futurs locataires. Dans le meilleur des cas ils authentifiera les exploitants de ma future plateforme, et encore, …

La zone Backend contiendra tous les services techniques mutualisés de la plateforme. Il faut comprendre les produits de la gamme System Center avec toutes les instances SQL server dédiées qui me seront nécessaires. Donc cela contiendra :

  • Un beau cluster SQL Server 2012 R2 en mode Always-On avec quelques instances
  • SCVMM 2012 R2
  • SCOM 2012 R2
  • SCORCH 2012 R2
  • Service Management Automation
  • Service Provider Foundation

La zone des PA/CA, c'est pour faire un détour pour parler un peu des Cluster Hyper-V que l'on va utiliser pour héberger les ressources mises à disposition de nos futurs locataires. Cette zone est sous-divisée en deux :

  • La Provider Address Space
  • La Customer Address space

C'est un domaine que je ne vais pas développer de tout de suite. De toute façon certains frenchies de DPE ont très bien traité le sujet au Teched 2014 à Barcelone dans la session: Deploying Hyper-V Network Virtualization, et en VO en plusClignement d'œil.

Nous en arrivons au cœur de Windows Azure Pack. La zone privilégiée avec les modules suivants :

  • Admin Site
  • Admin Authentication Site
  • Admin API
  • Tenant API
  • PowerShell API
  • Best Practice Analyzer

Enfin, il nous reste la zone publique, celle au plus proche de nos futurs locataires (donc sur Internet). A la surface des nuages, on va trouver les modules publics de Windows Azure Pack :

  • Tenant Site
  • Tenant Authentication Site
  • Tenant Public API

Au passage, c'est aussi dans cette zone que l'on va trouver la Gateway NVGRE mais ça c'est une autre histoire qui nécessitera une très grosse extension de mon lab.

 

Prêt à vous faire torturer à la demande?

 

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

Azure virtual Network pour plan d’adressage non compliant RFC1918

La RFC1918, défini clairement les réseaux IPv4 utilisables pour les réseau privés. Jusqu’à maintenant, Microsoft Azure ne permettait pas à des locataires de créer des réseaux usurpant des plages d’adresses publiques. D’un certain coté, c’est logique. Par contre pour un certain nombre de clients français, c’est un point bloquant car leur réseau “On-Premise” est lui même non-compliant avec la RFC1918. Lorsqu’on veut vendre du cloud Azure pour ce type de client, cette contrainte est un frein bloquant puisqu’il ne sera pas possible de mettre en place de tunnel site-to-site, ni même de déclarer des Address spaces non-compliant avec la RFC1918. Quelle ne fut pas ma surprise ce matin en découvrant cette annonce datant de la veille :

image

 

Surpris que j’étais, je me suis demandé si par le plus grand des hasard cette fonctionnalité n’était pas encore disponible pour la région européenne. Et oh surprise, c’est bien le cas. j’ai pu usurper l’adresse de base du sous-réseau dédié à Microsoft Tire la langue.

image

On peut donc tout à fait continuer à usurper les adresses Internet publiques tout en faisant du cloud. C’est moche d’un point de vue réseau mais c’est une bonne nouvelle pour les entreprises qui sont concernées par ces problématiques.

 

Si même Microsoft Azure devient disruptif, mais ou va t’on?

 

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

Posted: 11-18-2014 14:12 by Benoît SAUTIERE | with no comments
Filed under:
Windows Azure Pack– Authentification ADFS Admin-Side : Les cercles de l’enfer (7/7)

Donner accès au portail d'administration Windows Azure Pack aux exploitants du service c'est bien. Le faire en ADFS, c'est déjà pas mal. Problème, depuis le début, on ne parle que de portail. Quid de la bonne vielle invite de commande PowerShell. Comment nos exploitants vont-ils pouvoir s'authentifier en ADFS et exploiter à distance. Bienvenu dans le dernier cercle de l'enfer. Si on reprend la cinématique de connexion, tout part d'un navigateur qui va se faire rediriger vers notre serveur 'adfs.windowsazurepack.lan'. Comment expliquer à PowerShell ce concept?

clip_image001

Problème intéressant non? Avant-cela, il faut résoudre un autre problème. Comment installer les modules PowerShell en relation avec Windows Azure Pack. Ne cherchez pas, ce n'est pas inclus avec le module PowerShell de Microsoft Azure.

 

Un peu d'installation

Le Web Plateform Installer est prévu pour fonctionner avec une connexion Internet. On télécharge un élément de ‘bootstrap’ et nous présente le contenu téléchargeable. Problème, il ne nous proposera de télécharger des composants de Windows Azure Pack que si nous sommes sur un système d'exploitation compatible, donc Windows Server 2012 R2. Or ma station d'administration est un système d'exploitation client (Windows 7 pour l'occasion). Il faut donc tricher un peu et utiliser le mode d'installation "Offline". Au passage, c'est prévu par Microsoft puisque documenté ici.

On va donc commencer par télécharger et installer le package MSI du Web Plateform Installer :

De là, on va utiliser le Web Plateform Installer mais en ligne de commande WEBPICMD.EXE.

clip_image002

Bonne nouvelle, il y a des options intéressantes tel que /List et Offline. Commençons avec /List en précisant qu'on veut tout.

clip_image003

Avec un peu de patience, il finit par nous afficher la liste de tout ce qui est disponible chez Microsoft pour le Web Plateform Installer.

clip_image004

Mais d’où vient cette liste? Réponse : https://www.microsoft.com/web/webpi/5.0/webproductlist.xml. On peut donc attaquer le téléchargement avec l'option "/Offline". Pour la source, on sait quoi renseigner.

clip_image005

Dans la liste, on va forcément avoir des modules en relation avec Windows Azure Pack.

clip_image006

Deux choses à noter à la fin. Premièrement, il conserve l'historique des sources, c'est pratique.

clip_image007

Deuxièmement, il nous a généré un fichier XML. C'est la source que nous pouvons utiliser pour le Web Platreform Installer au lieu de le télécharger sur Internet.

clip_image008

Vu que je sais ce dont j'ai besoin, je vais aller direct à l'essentiel. Dans mon répertoire de téléchargement, j'ai un sous-répertoire pour les binaires d'installation. Il y en a qu'un qui m'intéresse : ‘WAP_PowershellAPI’.

clip_image009

A l'intérieur, on trouvera un simple package Windows Installer qu'il suffit d'installer.

clip_image010

Une fois installé, on peut constater qu'on dispose bien des modules d'administration et de configuration de Windows Azure Pack.

clip_image011

Quelques mise à jour à installer et on en a fini avec l'installation des prérequis. On va pouvoir revenir au nœud du problème.

 

Vous reprendrez bien un token pour la route?

Comment faire comprendre à PowerShell qu'il faudra utiliser ADFS comme fournisseur d'authentification. La réponse se trouve dans le module 'Windows Azure Pack Administration' et plus précisément dans la commande Get-MgmtsvcToken.

clip_image012

Pour en savoir plus, on va commencer par mettre à jour l'aide (update-help) avant de voir ce qu'on peut appendre sur cette commande.

clip_image013

Plusieurs choses ont retenu mon attention. Premièrement, cela permet bien de générer un token JSON consommable par Windows Azure Pack. Deuxièmement, il est bien prévu d'utiliser ADFS comme fournisseur d'identité. Bref, ça commence pas mal. C'est maintenant que cela se complique. J'ai eu beau chercher dans tous les sens, la commande fonctionnait bien lorsqu'exécutée depuis mon serveur Windows Azure Pack mais pas depuis mon poste d'administration. Après beaucoup de recherches, je suis tombé sur cette page de troubleshooting sécurité de Windows Azure Pack.

clip_image014

 

J’ai pas encore trouvé le pourquoi de la chose. Dès que j’ai trouvé, l’article sera updaté. En attendant, on va utiliser le workaround proposé par Microsoft. Le script a juste besoin d'être personnalisé avec quelques informations :

  • L'URL du serveur ADFS
  • Mon compte
  • Mon mot de passe

clip_image015

Si tout se passe bien, le script nous retourne un contenu tel que celui illustré ci-dessous :

clip_image016

Oui, j'ai caché quelques caractères Tire la langue. Il nous manque juste une chose :  à qui va-t-on s'adresser pour soumettre nos commandes PowerShell? réponse : au module AdminAPI de Windows Azure Pack.

Sur ma maquette actuelle, je n'ai pas encore personnalisé cette URL (c'est une erreur regrettableFou furieux). Cela veut dire que c'est toujours le certificat auto-signé qui est en place avec le nom de mon serveur Windows Azure Pack (Tiens un sujet prochain billet très fun). C'est un point dont il faudra prendre compte pour appeler nos commandes PowerShell. Commençons par quelque chose de simple, afficher la liste de nos locataires avec Get-MgmtSvcUser. Le truc, c'est de bien spécifier les paramètres -"AdminURI" et "Token" et de ne pas oublier qu’on à un certificat autosigné qui traine. Donc le paramètre ‘-DisableCertificateValidation’ est obligatoire.

clip_image017

Vu qu'on peut afficher la liste de nos locataires, on devrait aussi pouvoir en créer un nouveau avec la commande Add-MgmtSvcUser. Ça fonctionne toujours sur le même principe.

clip_image018

Pour vérifier, on peut aller faire un tour dans le portail et effectivement, on a bien notre nouveau locataire.

clip_image019

 

Pour ce dernier, j'ai eu beaucoup d'aide :

 

C’est la fin de cette série d’article sur la configuration d’ADFS pour les administrateurs de Windows Azure Pack. j’ai volontairement écourté cette série mais il reste tant à faire :

  • Configuration du module AdminAPI avec un véritable certificat
  • Mise en place d’un mécanisme d’authentification forte
  • Publication d’ l’ADFS avec un Web Application Proxy (l’autre WAP)

 

Plein de sujets pour de prochains articles. Alors Windows Azure Pack est il assez disruptif pour vous? Aller oust, les survivants sont libérés!

 

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (6/7)

En soit, authentifier un utilisateur c'est pas un exploit mais ce serait plus simple de gérer des groupes et l'appartenance à un groupe. A première vue, on pourrait penser que ce sera très simple. Pourtant, il m'a fallu du temps pour comprendre mes erreurs. C'est suffisant pour moi pour y dédier un billet.

Si on se souvient bien du second cercle de l'enfer, on avait dit que le claims allait aussi contenir l'appartenance de l'utilisateur à tous les groupes dont il est membre. Donc on devrait pouvoir exploiter cette information pour autoriser l'accès au portail d'administration de Windows Azure Pack. Voyons ce que l'aide de la commande "Add-MgmgSvcAdminUser" peut nous apprendre sur ce sujet.

clip_image001

Visiblement, on est sur la bonne voie. A la vue des paramètres, on aura la même chaine de connexion à construire que dans le cinquième cercle de l'enfer. C'est donc du réchauffé jusque-là.

clip_image002

Mon groupe, c'est le 'WAP Admins' qui a pour seul et unique membre le compte 'WindowsAzurepack.lan\WApAdministrators'. Au passage, ce groupe n’est membre d’aucun groupe de domaine ou groupe local.

clip_image003

C'est un rappel mais le claims va contenir l'UPN de l'utilisateur. Il faut faire attention à ce détail car pour les groupes ça a toute son importance. On y reviendra bientôt. Voyons déjà ce qu'il y a dans les utilisateurs / groupes autorisés à accéder au portail d'administration de Windows Azure Pack.

clip_image004

Il n'y a que mon utilisateur nouvellement accrédité ainsi que le contenu historique. Ajoutons notre groupe avec la commande "Add-MgmgSvcAdminUser" en prenant soin d'utiliser la notation FQDN et non NETBIOS pour désigner le domaine.

clip_image005

Normalement, à ce stade, ça plante. Le groupe est bien référencé mais Windows Azure Pack refuse l'accès à mon utilisateur ‘WapAdministrator@WindowsAzurepack.lan’.

 

C'est en mettant en place les logs comme expliqué dans le billet précédent cinquième cercle de l'enfer que j'ai compris d’où venait mon erreur. La configuration du claims tel que documentée dans le billet second cercle de l'enfer indique bien d'inclure les groupes. Voyons ce qu'elle précisait.

clip_image006

Dans le billet, je précisais de mapper l'attribut "Token-groups – Qualified by Domain Name" dans le claims pour les groupes. C'était une erreur de ma part. Cet attribut désigne bien le groupe mais avec une notation NETBIOS pour le domaine. Pour utiliser une notation FQDN, il faut utiliser l'attribut "Token groups - Qualified by Long Domain name" Agressif. Comment perdre deux heures.

clip_image007

Une fois la contenu du claims change, ça fonctionne tout de suite mieux.

clip_image008

Si on voulait pouvoir utiliser les deux notations (DNS et FQDN), il aurait fallu écrire des règles de transformations pour peupler l'attribut 'group' pour réécrire la partie domaine. C'est faisable mais ça complique déjà pas mal les choses. On va essayer de rester simple, surtout qu'il reste encore le dernier cercle de l'enfer à explorer après.

Les observateurs assidus ont dû remarquer que notre utilisateur est membre d'un seul groupe Active Directory et que celui-ci donne uniquement le privilège d'administrer le service Windows Azure Pack et non la plateforme sous-jacente. Cela signifie que les membres de ce groupe n'ont absolument aucun privilège sur les serveurs de notre plateforme. Encore un point qui fait que Windows Azure Pack est disruptif dans son approche : Dissocier l'administration du service de la plateforme.

Vous êtes toujours là. Bien, il reste juste une salle de torture.

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (2/7)

Dans le premier cercle de l'enfer, nous avons mis en œuvre une infrastructure ADFS pour notre plateforme Windows Azure Pack. A ce stade, Windows Azure Pack ne sait pas encore qu'il peut lui déléguer l'authentification. Pour cela, il faut établir une cadre de confiance entre les deux partenaires. Dans le second cercle de l'enfer, nous allons nous attarder sur la mise en place de ce cadre de confiance du point de vue d'ADFS. Lorsque ADFS aura authentifié notre utilisateur, il devra générer un token avec des claims correctement formatées, de manière à ce que Windows Azure Pack puisse les comprendre. Du point de vue ADFS, Windows Azure Pack sera un Security Token Service (STS). Par défaut, il y a déjà un partenariat de confiance établit entre le module "Admin portal" et le module "Admin Authentication Site". Nous allons juste le remplacer.

Du point de vue ADFS, le module "Admin portal" sera considéré comme un partenaire de confiance, donc référencé comme un "Relying Party trust".

clip_image001

Le truc, c'est de savoir à qui s'adresser coté Windows Azure Pack. Si le portail d'administration de Windows Azure Pack doit faire confiance à ADFS, il est logique qu'ADFS renvoie le claims à l'envoyeur. On a donc l'URL de base : https://wapadmin.windowsazurepack.lan à laquelle on va ajouter "FederationMetadata/2007-06/FederationMetadata.xml". Ne cherchez pas ce répertoire virtuel dans IIS, toute trace de dépendance avec IIS a été retirée. On commence donc par désigner l'emplacement du fichier XML de notre partenaire de confiance : le portail d'administration Windows Azure Pack.

clip_image002

Si votre module "Admin portal site" est bien joignable, alors notre ADFS va être capable de récupérer les informations nécessaires. Ne restent qu'à traiter que quelques points de configuration. Nous allons commencer par nommer ce partenariat.

clip_image003

Nous sommes sur une plateforme Windows Server 2012 R2, donc ADFS 3.0, prenant en charge la fonctionnalité "Multi-Factor Authentication", c'est sexy. Pour l'instant on va s'en passer. On reviendra sur ce point lors d'un prochain billet. Mais ça n'empêche pas qu'on va préparer le terrain.

clip_image004

Notre infrastructure ADFS peut être en mesure d'authentifier un utilisateur mais doit-elle délivrer un jeton d'accès? La réponse est bien entendu oui. Par contre, comme indiqué, cela ne veut pas dire que l'utilisateur sera autorisé à accéder au portail d'administration de Windows Azure Pack. Tout dépendra des claims présentées et des autorisations accordées dans Windows Azure Pack.

clip_image005

Avant de finaliser, voyons un peu les informations que l'assistant a été capable de récupérer de notre partenaire de confiance. ADFS va se charger de maintenir la confiance avec le STS (module Admin portal site). Pour cela il va périodiquement récupérer la configuration dans le fichier de metadata.xml. C'est aussi lors de cette opération qu'il va découvrir le nouveau certificat à reconnaitre pour la signature des tokens.

clip_image006

Le module "Admin portal site" n'a qu'une seule exigence, c'est que le claims généré par ADFS intègre un UPN. Il peut contenir plus mais le minimum, c'est l'UPN de l'utilisateur. Dans notre cas, nous allons inclure plus d'informations dans notre claims. On verra cela un peu plus tard.

clip_image007

On en a fini avec la configuration du nouveau partenaire de confiance d'ADFS, reste à se mettre d'accord sur le détail des données échangées dans les claims générés par ADFS. Comme on vient de le voir, le module "Admin portal site" attend un claims contenant l'UPN de son utilisateur. C'est son exigence. Charge à ADFS de construire le jeton avec les bonnes informations. Pour cela, il faut des règles très strictes. Pour construire ces claims on peut :

  • Utiliser le contenu d'un attribut du fournisseur d'identité (ADDS/ADLDS) et l'utiliser tel que
  • Transformer le contenu d'un attribut du fournisseur d'identité (ADDS/ADLDS) pour l'enrichir
  • Peupler le claims avec un flag si l'utilisateur est membre d'un groupe particulier
  • Utiliser une source extérieur pour enrichir le claims

Le troisième cas est intéressant car il permet de renforcer l'authentification des utilisateurs. On peut par exemple rechercher si l'utilisateur est membre du groupe spécial "NT AUTHORITY\Certificate from this organization" prouvant une authentification avec double facteur de type Smartcard / Virtual smartcard. C'est intéressant à conserver pour authentifier les exploitants de notre plateforme Windows Azure Pack.

Dans notre contexte, on fera au plus simple. Nos exploitants sont des utilisateurs déclarés de l'annuaire Active Directory utilisée par l'infrastructure windowsazurepack.lan. On pourra donc se contenter de règles se contentant d'exploiter le contenu brut des attributs contenus dans l'annuaire Active Directory.

clip_image008

A ce stade, il y a aucune règle, donc le claims sera vide. Il faut donc un peu de travail.

clip_image009

La première règle du Claims Club, c'est de donner ton UPN. C'est une information qu'ADFS va extraire de l'annuaire Active Directory.

clip_image010

Et plus précisément de l'attribut "User-Principal-Name" de l'annuaire Active Directory que l'on va présenter tel que dans le claims. C'est le minimum requis pour Windows Azure Pack.

clip_image011

Du point de vue de Windows Azure Pack, on pourrait se contenter de cette unique règle. Cependant, cela impliquera que l'autorisation de nos utilisateurs se fera uniquement sur son UPN. Chaque utilisateur devrait être autorisé individuellement. On va donc introduire une seconde règle pour que le claims contienne la liste des groupes dont l'utilisateur est membre. C'est presque la même règle que la précédente, sauf que cette fois ce n'est pas l'UPN que nous allons passer mais le "Token-groups - Qualidied by Domain Name" “Token groups - Qualified by Long Domain name” que nous allons positionner dans le claims "Group". C'est la seconde règle du Claims club.

FIXADFSCLAIMS

On en a fini avec les règles du Claims Club.

clip_image013

Si on creuse un peu, on peut exprimer beaucoup de choses dans ces claims :

  • Le device utilisé est-il enregistré (Workplace Join)?
  • La version du système d'exploitation?
  • L'utilisateur est-il connecté depuis un réseau interne?

A gauche la liste des attributs dont je dispose dans mon fournisseur d'identité (mon annuaire Active Directory) et à droite la liste des attributs que l'on peut peupler dans le token qui sera généré. On a de quoi faire pour exprimer nos règles.

LISTE0 LISTE1

 

Ce côté du partenariat c’est presque prêt. C'est la fin du second cercle de l'enfer. La prochaine étape, ce sera de descendre dans les entrailles d'ADFS, en PowerShell s’il vous plait.

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (5/7)

C'est comme pour le poker, c'est l'heure du showdown. Show me your claims! C'est la séquence : ça tombe en marche ou pas. Si on essaie tout de suite de se connecter à mon portail d'administration (https://wapadmin.windowsazurepack.lan/) , ça commence bien, nous sommes redirigés vers ADFS qui va nous demander de nous authentifier et fournir un token. Dans l'illustration ci-dessous, on constate bien que c'est ADFS qui sollicite que nous nous authentifions.

clip_image001

Selon la configuration d'ADFS, l'expérience utilisateur peut être différente de celle illustrée ci-dessus. Dans mon cas, mon client est localisé sur le réseau interne (Donc Local Intranet du point de vue Internet Explorer). J'ai juste fait en sorte que mon navigateur ne soumette pas automatiquement mes credentials pour la démonstration. Du point de vue ADFS, c'est personnalisable.

clip_image002

Pourtant au final, ça n'a pas l'air de fonctionner. Dans la cinématique on aura constaté la redirection vers notre serveur "adfs.windowsazurepack.lan" puis le retour vers le portail. Il y a bien eu authentification mais il est clairement indiqué que nous ne sommes pas autorisés.

clip_image003

Etrange, pourtant si on demande à WAP la liste des administrateurs de la plateforme, mon compte apparait bien dans la liste des utilisateurs accrédités à administrer la plateforme Windows Azure Pack.

clip_image004

Ce qu'il faut comprendre, c'est que par défaut, aucun utilisateur n'a accès au portail d'administration de Windows Azure Pack. ADFS a authentifié mon utilisateur, il ne l'a pas autorisé. Là, c'est Windows Azure Pack qui décide. C'est donc tout simplement que mon UPN n'est pas référencé. Corrigeons ce problème avec la commande "Add-MgmgSvcAdminUser"

clip_image005

Si on redemande la liste des exploitants de la plateforme, on constate bien une différence.

clip_image006

Maintenant ca se passe tout de suite mieux.

clip_image007

Note pour les buses intergalactiques comme moi

De temps en temps, on échoue à la dernière étape. Ça a été mon cas à ce stade. J'ai buté jusqu'à me souvenir que par défaut mon compte administrateur n'a pas d'UPN de configuré. Ceci corrigé, cela fonctionne tout de suite mieux. Ouvrir une session avec un UPN, c'est pas un exploit, à moins de prouver qu'il y a bien eu authentification via ADFS.

 

Un coup de bluff?

On pourrait penser à un coup de bluff. Pour cela, on va revenir en arrière au niveau ADFS. Nous avions bien prévu de journaliser les évènements en relation avec notre serveur ADFS.

clip_image008

Il y a juste que si on prend le temps de lire la petite note en bas de l'interface, il faut encore faut-il pouvoir suivre l'activité générée par notre serveur ADFS du point de vue du système d'exploitation. Pour rappel, ADFS fonctionne dans le contexte dans un compte de service de type Group Managed Service Accounts (GMSA). Dans une installation par défaut d'ADFS, il est bien prévu que le compte de service d'ADFS puisse générer des évènements de sécurité.

clip_image009

C'est bien mais encore faut-il que la journalisation des évènements générés par des applications ait été activée. Un petit tour de magie avec "AuditPol.Exe" et le tour est joué.

clip_image010

Après un "GPUPDATE / Force", on est prêt pour le showdown des claims. Dans le journal de sécurité de mon serveur ADFS, on commence par un évènement 403 indiquant qu'il y a bien eu réception d'une requête au niveau ADFS.

clip_image011

Après qu'ADFS ait authentifié la demande, il a émis un jeton. On notera l'information 'Instance ID', ça va être notre fil d'Ariane.

clip_image012

Cet évènement nous mène à un évènement 501. On peut faire le lien entre les deux évènements avec l'information 'Instance ID'. Cet évènement nous révèle le contenu du claims : Showdown.

clip_image013

On trouvera plusieurs instances de l'évènement, car le claims contient beaucoup d'informations, dont la liste des groupes dont mon utilisateur est membre. C'est normal, nous l'avions demandé lors du second cercle de l'enfer.

Si vous avez bien suivi, on est au cinquième cercle de l'enfer. Ça veut dire qu'il nous en reste deux salles de tortures à traverser.

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

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (4/7)

Dans le cercle précédent, on a traité la partie ADFS. Il nous reste à voir la partie Windows Azure Pack. Pour cela, un peu exploration avec un petit peu de PowerShell. La commande Get-MgmtsvcEndpoint permet de se rendre compte que tous les modules de Windows Azure Pack utilisent des Web Services pour communiquer entre eux. C'est pas nouveau. Par contre, si on se penche sur le cas du module "WindowsAuthSite", on voir bien qu'il cause "ADFS".

clip_image001

En fait, c'est un peu plus compliqué que cela. Nativement sans avoir mis en œuvre ADFS, Windows Azure Pack utilise déjà des tokens JSON. Pour le module WindowsAuthSite, il va exploiter l'annuaire Active Directory. Voyons si d'autres modules ne seraient pas en mesure d'utiliser des tokens JSON.

clip_image002

On retrouve notre portail d'administration de Windows Azure Pack. C'est logique, il doit être en mesure de rediriger les demandes d'accès non authentifiées ou dont le token n'est pas conforme à ce qu'il attend. A ce stade, il fait confiance au module WindowsAuthSite. Ils nous faut donc le reconfigurer pour soumettre les authentifications à notre ADFS. Si Windows Azure pack est un partenaire de confiance d'ADFS, encore faut-il que Windows Azure Pack sollicite ADFS les services d'ADFS. Pour cela nous devons reconfigurer le RelyingPartySettings pour que celui-ci ne sollicite plus le module WindowsAuthSite mais bien ADFS. En cherchant un peu dans le module PowerShell, on trouve la commande “Set-MgmtsvcrelyingPartySettings”. C'est maintenant que cela se complique et pas qu'un peu. Il nous faut construire une chaine de connexion. Toutes les informations de configuration de Windows Azure Pack sont stockées dans la base de données, allons voir ce qu'on peut y trouver avec la commande Get-MgmtsvcDefaultDatabase.

clip_image003

Y en a un qui nous intéresse tout de suite, c'est le "Microsoft.MgmtSvc.PortalConfigStore". Allons voir dans le SQL Server ce qu'on trouve dans cette base de données. Je suis allé direct à l'essentiel à savoir à quel fournisseur d'identité notre portail des exploitants de Windows Azure Pack doit faire confiance.

clip_image004

Dans la capture ci-dessus, mon ADFS est déjà en place. Maintenant qu'on sait où réaliser le changement, on pourrait penser qu'il n'y a qu'à référencer mon ADFS et bingo le tour est joué. Il suffit de regarder attentivement le contenu du paramètre pour s'apercevoir qu'on nous parle d'un peu plus qu'un simple FQDN. On cause Realm, Endpoint et certificat associé. Bref, c'est plutôt risqué de changer cela directement dans la base SQL. Par contre, il y a une nouvelle notion qui nous intéresse : le Endpoint. C'est lui qui désigne le fournisseur d'identité de Windows Azure Pack. Pour réaliser le changement, explorons de nouveau le module MgmtSvcConfig.

clip_image005

C'est la commande Set-MgmtSvcRelyingPartySettings qui va nous intéresser. Nous avons besoin des informations suivantes. Voyons un peu ce que l'aide PowerShell de cette commande peut nous apprendre (après avoir fait un Update-help).

clip_image006

C'est presque notre cas. Nous, c'est le portail d'administration de Windows Azure Pack. Donc pour le paramètre "Target", on sait que c'est "Admin". Le paramètre "MetaDataEndpoint", c'est lui qui désigne le partenaire de confiance. Il faut construire une chaine de caractère comprenant à la fois le FQDN de notre serveur ADFS mais aussi l'URL menant au fichier MetadataEndPoint.XML. Allons voir dans la console ADFS où se trouve ce fichier.

clip_image007

On peut donc déduire que le contenu du paramètre MetadataEndpoint sera https://adfs.Windowsazurepack.lan/FederationMetadata/2007-06/FederationMetadata.XML. Il ne nous reste plus qu'un paramètre à construire, le "ConnectionString". En regardant un peu l'aide de la commande Set-MgmtSvcRelyingPartySettings, on découvre que cela désigne une chaine de connexion SQL. L'aide nous donne même un exemple de construction. Pour la construire, j'ai besoin des éléments suivants :

  • Data Source : C'est le serveur SQL auquel on va se connecter. Pour moi, c'est “SQL.Windows AzurePack.Lan”
  • Initial Catalog : C'est la base de données dans laquelle on va réaliser les modifications : “Microsoft.MgmtSvc.PortalConfigStore”
  • User : Le compte SQL avec lequel on va se connecter pour réaliser la mise à jour (je rappelle que notre SQL est configuré pour supporter l'authentification SQL et l'authentification Windows)
  • Password : Vous pensez quand même pas que j'allais révéler cette information.

On a tout ce qu'il nous faut. Je vais commencer par poser quelques variables avant de construire le chaine de connexion.

clip_image008

Maintenant, c'est David Coperfield ou Garcimore. Si tout se passe bien la commande Set-MgmtSvcRelyingPartySettings doit retourner un résultat tel qu'illustré ci-dessous :

clip_image009

Note : Ne pas oublier de redémarrer le site web du portail d'administration de Windows Azure Pack pour le forcer à prendre en compte le changement opéré. Pour ceux qui m'ont suivi jusqu'ici respect, vous n'êtes pas nombreux. Dites-vous que le plus dur est passé, reste à voir si ça tombe en marche.

 

Non, je ne suis pas méchant. Sadique? peut-être.

 

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

Windows Azure Pack - Les updates de System Center

Même si Windows Azure Pack est un produit disruptif, il s'appuie quand même sur un certain nombre de composants de la gamme System Center pour la partie IAAS:

  • System Center Service Provider Foundation
  • System Center Virtual Machine Manager 2012 R2
  • System Center Operation Manager 2012 R2

 

Microsoft a mis à disposition le Rollup 4 pour System Center 2012 R2. Cela comprend donc les Rollup suivants :

  • System Center Data Protection Manager 2012 R2 (KB3009516)
  • System Center Operation Manager 2012 R2 (KB2992020)
  • System Center Service Manager 2012 R2 (KB2989601)
  • System Center Service Provider Foundation (KB2992021)
  • System Center Service Reporting (KB2992025)
  • System Center Virtual Machine Manager 2012 R2 (KB2992024)

 

Bref, que des produits qui ont ou peuvent entrer en relation avec Windows Azure Pack. Mais il y en a aussi spécifiquement pour Windows Azure Pack :

  • Rollup 4 for System Center 2012 R2 and Azure Pack (KB2992027)
  • Update Rollup 4 for Windows Azure Pack Web Sites Version 2 (KB2992029)

Le Rollup 4 de Windows Azure Pack intègre une correction pour un problème qui a eu le don de l'irriter. Il corrige un problème avec la KB 2990942, une mise à jour du mois d’Octobre 2014.

    clip_image001

Bref, il tombe à pic ce Rollup 4 pour Windows Azure Pack. Au passage bien lire la note.

 

BenoîtS – Simple and Secure by Design but Business compliant

Rollup 1 for Forefront Unified Access Gateway 2010 Service Pack 4

It’s UAG Patching day today. Microsoft just released update 1 for Service Pack 4 of Forefront UAG 2010 (KB2922171). many fixes but also some improvements for Exchange 2013 and SharePoint 2013. Here is the list of included fixes :

  • KB2997481 : FIX: You are not authorized to access applications published through Forefront Unified Access Gateway
  • KB2997483 : FIX: Source IP and user name missing from Event ID 14 in the Web Monitor log file
  • KB2997485 : FIX: "An unknown error occurred while processing the certificate" error when you access an application that is hosted on an Apache web server
  • KB2997486 : FIX: The Forefront Unified Access Gateway portal may be unavailable
  • KB2997487 : FIX: "You have attempted to access a restricted URL" error when you try to access OWA and are close to the idle session time-out period
  • KB2998352 : FIX: "Your client does not support opening this list with Windows Explorer" error when you try to open a SharePoint document library
  • KB2998733 : FIX: You cannot start a RemoteApp application when its name contains accented characters
  • KB2998739 : FIX: The VPN connection disconnects immediately when a Unified Access Gateway 2010 client uses SSTP
  • KB2998752 : FIX: "Authentication failed" error when you try to log on to Unified Access Gateway by using the UPN format
  • KB2998769 : FIX: Exception occurs when you use the Export2Tspub application to export the configuration to a .tspub file
  • KB3003977 : FIX: "Sign-in Error" errors for Internet Explorer 11 clients when they access a Unified Access Gateway portal trunk that has ADFS 2.0 authentication
  • KB3004023 : FIX: Client connections for Form-based SSO fail authentication in Forefront Unified Access Gateway 2010 SP4
  • KB3006827 : FIX: Forefront Unified Access Gateway 2010 template improvements for SharePoint Server 2013
  • KB3006828 : FIX: Forefront Unified Access Gateway 2010 template improvements for Exchange Server 2013
  • KB3006892 : FIX: Windows Firewall is detected as running after a third-party firewall is installed on a computer that is running Forefront Unified Access Gateway 2010
  • KB3006938 : FIX: Soft lockout does not apply if Outlook Anywhere uses KCD for SSO to Exchange Server
  • KB3006940 : FIX: Portal toolbar is not displayed in Forefront Unified Access Gateway 2010
  • KB3007519 : FIX: "Bind the source IP address to the session" option does not work correctly in Forefront Unified Access Gateway 2010
  • KB2997456 : FIX: French client access to Unified Access Gateway trunk by using two-factor authentication fails when user password nears expiration
  • KB2997493 : FIX: "Invalid URL path" error when an external user tries to connect to a shared calendar
  • KB3007842 : FIX: "The website cannot display the page" or "HTTP 500" error if the first user logon is unsuccessful
  • KB3009885 : FIX: Applications that use the Socket Forwarder component may stop responding in Forefront Unified Access Gateway 2010
  • KB3009904 : FIX: "You cannot access this site due to an internal error" error when you log on to Outlook Web App again

 

At last, if not already done, don’t forget to fix the SSLV3 flaw. My valuable MVP colleague Richard HICKS published an excellent article on this subject.

 

BenoîtS – Simple and Secure by Design but Business compliant

Windows Azure Pack – Authentification ADFS Admin-Side : Les cercles de l’enfer (3/7)

Depuis le début, je parle de token JSON. Le problème, c'est que jusqu'à maintenant, on en a pas encore vu la trace. Et pour cause, c'est pas activé par défaut et c'est pas configurable via l'interface graphique. Voyons un peu les commandes Powershell disponible pour le module ADFS.

clip_image001

Explorons la liste de nos partenaires de confiance.

clip_image002

Vu que nous sommes sur un serveur Windows Server 2012 R2, il est logique de trouver le Device Registration Service, module bien connu pour ceux qui ont joué avec Workplace Join. On retrouve aussi le partenaire que nous venons de configurer. Allons explorer sa configuration en détail.

clip_image003

On découvre deux choses. Premièrement, lors de l'importation du fichier de Metadata, il a bien importé le STS du module 'Portal Admin Site' identifiable par "http://azureservices/AdminSite". Deuxièmement, les tokens JSON ne sont pas activé. Or nous en avons besoins, c'est le formalisme utilisé par Windows Azure Pack et son grand frère Microsoft Azure. Ces tokens présentent l'avantage d'être assez simple pour tenir dans un entête HTTP. D'un point de vue structure, ils sont plus léger que le SAML traditionnel. On as assez d'information pour changer cela. Si on a un "Get", alors on doit avoir un "Set", faut juste être capable de bien désigner notre objet à actualiser.

clip_image004

Nous en avons fini avec la partie ADFS. c'était pas si difficile. Et si on s'attaquait au gros du morceau? Reconfigurer le portail "Admin portal site" pour utiliser notre ADFS tout prêt à générer des tokens JSON.

 

Jusqu’a maintenant, j’étais gentil.

 

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

More Posts Next page »