Archives mensuelles : février 2015

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 :

  • Windows Azure Pack: Active Directory Authentication – Part 1
  • Windows Azure Pack: Active Directory Authentication – Part 2
  • Windows Azure Pack: Active Directory Authentication – Part 3

 

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)

Les restricted groups sous stéroïdes

Pour une fois, pas de torture. Ce sera tout ce qu’il y a de plus simple pour traiter un problème complexe.

 

Les restricted groups (ou groupes restreints) sont une fonctionnalité natives des stratégies de groupe depuis Windows 2000. Le principal intérêt de cette fonctionnalité est de pouvoir contrôler les membres des groupes locaux de nos serveurs et stations de travail.

D’un point de vue sécurité, la fonctionnalité est intéressante pour les stations de travail. Par contre coté serveurs, cela devient très vite lourd à gérer car on a besoin d’une GPO pour chaque configuration à propager. C’est encore plus problématique. Multiplier le nombre de stratégie de groupes n’est pas la solution.

Dans le contexte d’un projet VDI, j’ai eu à élaborer la gestion des droits administrateurs accordés sur les machines virtuelles, c’est juste une usine à gaz à gérer, c’est pas si simple que de positionner un compte dans le groupe local administrateur, surtout à l’échelle de plusieurs milliers de postes. Je recherchais donc une nouvelle approche. Techniquement l’approche que j’avais était bien tout-terrain mais trop complexe à mettre en œuvre.

 

En discutant avec l’auteur d’ADMPWD, j’ai découvert sa nouvelle création : Dynamic Local Admin. Comme pour ADMPWD, cela fonctionne sous la forme d’une Client-Side Extension des GPO qui vient compléter les "Restricted groups" en utilisant comme source le contenu de l’attribut ManagedBy du compte ordinateur dans l’Active Directory. La solution est simple et élégante car :

  • Contrairement à ADMPWD, pas besoin d’extension de schéma
  • On peut individualiser la configuration pour chaque ordinateur (positionner un compte utilisateur ou un groupe)
  • On peut déléguer la gestion de l’attribut ManagedBy
  • Pour auditer, plus besoin d’interroger chaque système

 

Coté mise en œuvre, il n’y a rien de plus simple :

  1. Installer le package MSI sur les stations / serveurs membre du domaine
  2. Importer les fichier ADMX / ADML
  3. Configurer une stratégie de groupe pour activer l’unique paramètre

clip_image001

Plus simple, c’est pas possible. Après, il n’y a plus qu’à peupler le contenu des attributs ManagedBy dans l’annuaire Active Directory et laisser les stratégies de groupe opérer.

Dans le contexte d’un projet Poste de travail, cette simple solution simplifie pas mal de choses. Plus besoin de gérer l’appartenance aux groupes locaux à distance et de devoir gérer les différentes problématiques (firewall, latence, VM offline, …). Tout est centralisé dans l’annuaire Active Directory. Le seul problème que pose cette approche, c’est la gestion de la compliance. Nous sommes nombreux à utiliser Desired Configuration Management (DCM) pour vérifier que les membres du groupe local administrateurs de nos stations de travail est bien conforme à ce qu’impose la sécurité et y remédier si nécessaire. La, cela va se compliquer un peu.

Bref, un must to have dans un projet poste de travail. En plus, pour une fois, c’est simple.

 

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)