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

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

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

Windows Azure Pack - IaaS : Introduction
Introduction

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

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

 

Service Provider Foundation, un viaduc entre deux mondes

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

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

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

clip_image001

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

  • Monitoring
  • MarketPlace
  • UsageService
  • SQLServers

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

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

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

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

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

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

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-List

clip_image002

 

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

 

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

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

  • SystemCenter
  • CloudServices
  • Gallery

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

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

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

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

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

image

 

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

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

 

La suite des réjouissances

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

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

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

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

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

clip_image001

 

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

clip_image002

 

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

clip_image003

 

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

clip_image004

 

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

clip_image005

 

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

clip_image006

 

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

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

clip_image007

 

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

clip_image008

 

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

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL.WindowsAzurePack.lan

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

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

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

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

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminUri -Token $Token

$AllRPs | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}}, @{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-table -AutoSize

clip_image009

 

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

  • System Center
  • CloudServices
  • Gallery

 

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

 

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

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

Windows Azure Pack - IaaS : Installation du Service Provider Foundation

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

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

 

Compte AD de service

Groupe de sécurité local

Pool applicatif IIS

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

 

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

clip_image001

 

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

Nombre de VM

CPU

RAM

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

 

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

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

clip_image002

 

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

clip_image003

 

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

clip_image004

 

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

clip_image005

 

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

clip_image006

 

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

clip_image007

 

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

clip_image008

 

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

clip_image009

 

Y a plus qu'à installer le tout.

clip_image010

 

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

clip_image011

 

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

clip_image012

 

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

 

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

clip_image013

 

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

clip_image014

 

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

 

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

 

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

Certification Microsoft infrastructure

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

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

 

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

 

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

 

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

ADCS, quick and dirty et conséquences.

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

clip_image001

 

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

 

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

 

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

clip_image002

 

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

clip_image003

A ce stade, notre PKI utilise cet algorithme pour :

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

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

CERTUTIL.EXE -SetReg CA\CSP\CNGHashAlgorithm SHA256

NET STOP CERTSVC

NET START CERTVC

clip_image004

 

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

clip_image005

 

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

clip_image006

 

Ce qui implique un arrêt du service.

clip_image007

 

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

clip_image008

 

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

 

Maintenant, c'est beaucoup mieux.

clip_image009

 

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

clip_image010

 

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

 

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

 

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

 

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

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

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

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

clip_image001

 

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

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

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

Import-Module ADFS

Get-AdfsClaimsproviderTrust -Name adfs.tenant.fr

clip_image002

 

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

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

clip_image003

 

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

clip_image004

 

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

clip_image005

 

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

clip_image006

 

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

clip_image007

 

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

clip_image008

 

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

 

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

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

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

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

 

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

clip_image001

 

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

clip_image002

 

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

clip_image003

 

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

clip_image004

 

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

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

clip_image005

 

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

clip_image006

 

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

clip_image007

 

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

 

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

clip_image008

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

 

Et ça fonctionne.

clip_image009

 

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

clip_image010

 

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

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

clip_image011

 

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

clip_image012

 

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

clip_image013

 

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

clip_image014

 

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

clip_image015

 

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

  • Azure
  • Azure en chine

clip_image016

 

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

clip_image017

 

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

clip_image018

 

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

clip_image019

 

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

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

clip_image020

 

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

 

Conclusion

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

clip_image021

 

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

 

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

 

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

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)

More Posts Next page »