Archives mensuelles : novembre 2014

Identifier les GPO préparées pour ADMPWD

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

 

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

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

$allGPOs | ForEach-Object {

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

    {

        $content = $_.Properties.gpcmachineextensionnames

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

{

            $_.Properties.displayname

        }

    }

}

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

Installation des modules public de Windows Azure Pack

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

 

Formalités administratives

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

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

clip_image001

 

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

clip_image002

 

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

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

clip_image003

 

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

clip_image004

 

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

clip_image005

 

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

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

clip_image006

 

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

clip_image007

 

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

clip_image008

 

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

 

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

Installation distribuée de Windows Azure Pack – Inauguration

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

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

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

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

clip_image001

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

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

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

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

  • La Provider Address Space
  • La Customer Address space

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

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

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

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

  • Tenant Site
  • Tenant Authentication Site
  • Tenant Public API

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

 

Prêt à vous faire torturer à la demande?

 

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

Azure virtual Network pour plan d’adressage non compliant RFC1918

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

image

 

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

image

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

 

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

 

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

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

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

clip_image001

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

Un peu d’installation

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

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

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

clip_image002

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

clip_image003

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

clip_image004

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

clip_image005

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

clip_image006

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

clip_image007

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

clip_image008

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

clip_image009

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

clip_image010

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

clip_image011

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

Vous reprendrez bien un token pour la route?

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

clip_image012

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

clip_image013

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

clip_image014

 

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

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

clip_image015

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

clip_image016

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

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

clip_image017

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

clip_image018

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

clip_image019

 

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

 

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

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

 

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

 

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

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

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

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

clip_image001

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

clip_image002

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

clip_image003

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

clip_image004

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

clip_image005

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

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

clip_image006

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

clip_image007

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

clip_image008

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

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

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

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

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

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

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

clip_image001

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

clip_image002

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

clip_image003

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

clip_image004

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

clip_image005

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

clip_image006

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

clip_image007

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

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

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

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

clip_image008

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

clip_image009

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

clip_image010

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

clip_image011

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

FIXADFSCLAIMS

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

clip_image013

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

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

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

LISTE0 LISTE1

 

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

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

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

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

clip_image001

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

clip_image002

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

clip_image003

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

clip_image004

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

clip_image005

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

clip_image006

Maintenant ca se passe tout de suite mieux.

clip_image007

Note pour les buses intergalactiques comme moi

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

 

Un coup de bluff?

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

clip_image008

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

clip_image009

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

clip_image010

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

clip_image011

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

clip_image012

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

clip_image013

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

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

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

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

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

clip_image001

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

clip_image002

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

clip_image003

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

clip_image004

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

clip_image005

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

clip_image006

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

clip_image007

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

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

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

clip_image008

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

clip_image009

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

 

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

 

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