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

Personnalisation des URL de Windows Azure Pack
    shocking isn't it?

    La première chose qui choque, ce sont les URL en localhost, ports exotiques ainsi que la collection de certificats auto-signés. Ci-dessous ce qu'on peut constater à la première connexion au portail d'administration de Windows Azure Pack.

    clip_image001

    Pour le portail des tenants, c'est pareil, pas vraiment user-firendly pour offrir du service. En même temps, le processus d'installation de Windows Azure Pack est on ne peut plus direct. A part la configuration de la base SQL Server (en mode mixte obligatoirement) et la pass-phrase nécessaire pour accéder à la configuration de Windows Azure Pack, il n'y a aucune question sur les certificats ou URL à utiliser. Le sujet n'étant pas si simple, je me suis inspiré de l'excellent billet Windows Azure Pack - Reconfigure portal names, ports and use trusted certificates. Le seul défaut, c'est que ça va direct à l'essentiel, sans expliquer pourquoi on doit en passer par là, pourquoi c'est si compliqué.

    Si on relit mon billet Quelques notes sur Windows Azure Pack, Windows Azure Pack n'est qu'un assemblages de Web Services au-dessus desquels on trouve deux portails. Dans le contexte de ce billet, on va se focaliser sur les sites web & Web services suivants:

  • WAP Tenant Portal Service (MgmtSvc-TenantSite): Hosts the WAP Tenant Portal
  • WAP Tenant Authentication Service (MgmtSvc-AuthSite): Hosts the authentication for tenants
  • WAP Admin Portal Service (MgmtSvc-WindowsAdminSite): Hosts the Admin Portal
  • WAP Admin Authentication Service (MgmtSvc-WindowsAuthSite): Hosts the Admin Authentication
  • Donc on devine qu'à un moment ou un autre, il faudra traiter le cas de certificats auto-signés restant.

    Situation de départ

    Dans une installation par défaut, on utilise des certificats auto-signés et pas qu'un peu.

    clip_image002

    Bref, pas glop. On va revoir tout ça et commencer par utiliser les URL un peu plus parlantes. Dans le contexte de ce billet, on va mettre en place de véritables certificats et utiliser des ports moins exotiques que ceux utilisés à la fin de l'installation comme on peut le constater ci-dessous :

    clip_image003

    Mais pourquoi Microsoft a-t-il fait si compliqué?

    C'est simple pourtant. Windows Azure Pack est entièrement modulaire. On peut donc déployer :

  • Tous ses modules sur un même serveur (le cas de ce billet)
  • Les répartir sur plusieurs pour la haute disponibilité (ça chatouille)
  • Séparer les rôles pour assurer l'isolation (là ça commence à piquer)
  • Séparer les rôles pour assurer l'isolation et assurer la haute disponibilité (mode hardcore gamer)
  • Le processus d'installation par défaut configure tous les modules pour utiliser localhost et des certificats auto-signé (un par usage). D’où le nombre élevé de certificats sur la plateforme. Personnellement, je trouve l'approche excellente, reste à améliorer le processus d'installation pour configurer les différents modules pendant l'installation. Vu qu'on va personnaliser des modules, pas possible de faire cela depuis le site web d'administration (on va rapidement scier la branche sur laquelle on est assise), il faut donc tout faire en PowerShell.

    Plusieurs processus d'authentification

    On a deux populations (Admin & tenant) qui accèdent à des portails bien distincts. On part du principe que :

  • Les locataires doivent pouvoir accéder à leur portail depuis l'extérieur (internet)
  • Les administrateurs de la plateforme qui doivent pouvoir administrer depuis le réseau interne
  • Dans les deux cas, Microsoft a utilisé une approche modulaire et distingué :

  • Le portail en lui-même qui va exploiter une module d'authentification
  • Le module d'authentification lui-même qui peut utiliser plusieurs fournisseurs d'authentification
  • Un Web Service offrant les API propre à chaque usage
  • On ne peut pas segmenter plus. Quelque part, on peut comparer Windows Azure Pack avec Mindcraft. On va tous avoir les mêmes briques et pourtant en faire des univers totalement différents PAAS, IAAS, …

    Notre cible

    La cible, c'est d'avoir des URL plus user-friendly pour les portails d'administration et celui destiné aux locataires. C'est le minimum. Dans le tableau ci-dessous la configuration que nous allons mettre en place.

    Module WAP Nouvelle URL Port

    WAP Admin Portal

    wapadmin.WindowsAzurePack.Lan 443

    WAP Tenant Portal

    wapcloud.WindowsAzurePack.Lan 443

    WAP Tenant Auth

    wapcloud.WindowsAzurePack.Lan 444

    Là où cela se complique, c'est que chaque portail utilise son propre module d'authentification qui va lui-même rediriger vers le portail initial suite à une authentification validée. Ça peut sembler compliqué comme cela mais c'est la modularité de Windows Azure Pack qui veut ça et ça fait sa force car :

  • Les deux portails sont distincts, ce qui est une bonne chose du point de vue de la sécurité
  • Chaque portail peut avoir sa propre politique d'authentification (ADFS pour les locataires et ADFS +MFA pour les administrateurs)

 

    On a besoin de certificats y a un docteur dans la salle?

    Docteur PKI? Nous utiliserons une autorité de certification reconnue à la fois de l'infrastructure Windows Azure Pack et des locataires. Dans la vrai vie, le besoin de certificats publics (reconnus de tous) se limite aux modules exposés sur Internet. Cela concernerait donc les modules suivants:

  • Le WAP Tenant Portal
  • Le WAP Tenant Auth
  • Dans notre contexte, c'est simple, on a besoin de trois certificats pour les FQDN suivants :

  • WAPADMIN.WINDOWSAZUREPACK.LAN
  • WAPCLOUD.WINDOWSAZUREPACK.LAN
  • WAP01.WINDOWSAZUREPACK.LAN
  • La seule subtilité à prendre en compte à ce niveau, c'est la haute disponibilité (future?) de ces composants. Si vous prévoyez de faire évoluer votre plateforme vers la haute disponibilité, il faudra donc être capable d'exporter le certificat avec la clé privée. Une configuration à ne pas oublier dans le paramétrage du gabarit de certificat car c'est pas par défaut.

    Pour le certificat WAPADMIN.WINDOWSAZUREPACK.LAN, le docteur PKI utilise simplement la console IIS pour générer son ordonnance. C'est un certificat à usage interne, il peut donc être délivré par mon autorité de certification interne.

    clip_image004

    Le certificat WAP01.WINDOWSAZUREPACK.LAN correspond au nom de mon serveur WAP. C'est vers lui que seront redirigées les demandes d'authentification en provenance du portail des administrateurs de Windows Azure Pack. Il n'est pas nécessaire qu'il soit délivré par une autorité de certification reconnue par tous les navigateurs car nous partons du principe que ce portail n'a pas à être exposé sur Internet.

    clip_image005

    Enfin, le certificat WAPCLOUD.WINDOWSAZUREPACK.LAN sera utilisé à la fois par le portail d'authentification des locataires mais aussi par le web service chargé de leur authentification. Comme le portail des locataires et le web service d'authentification sont hébergés sur le même serveur, ils partageront le même certificat, restons simple.

    clip_image006

    Au final, voilà à quoi ressemble le magasin personnel de certificats de mon serveur WAP. Un vrai bordel. Va y avoir beaucoup de travail pour remettre cela au propre.

    clip_image007

    A ce stade, autant vous avertir, les deux portails vont vite devenir inutilisables, ce qui est logique vu qu'on modifie les noms et les ports pour lesquels ils répondent. Pour cette raison, toute cette configuration ne peut être réalisée qu'en PowerShell.

     

    Commençons par le portail des administrateurs de Windows Azure Pack

    C'est un site web dans IIS, donc simplement en changeant le binding, on devrait y arriver. Dans la console IIS, c'est le site web MgmtSvc-AdminSite. A ce stade, il répond en HTTPS avec un certificat auto-signé et en plus sur le port 30091. Plus moche c'est pas possible. On va donc s'assurer que ce portail réponde en utilisant une URL plus user-friendly : wapadmin.windowsazurepack.lan et utiliser le certificat que nous avons demandé.

    clip_image008

    Note : Ne pas oublier de redémarrer le site web. Immédiatement, on constatera que le portail n'est plus utilisable, on verra pourquoi un peu plus loin.

     

    Continuons avec le Web service d'authentification associé

    WAP? Ben oui, Windows Azure Pack est totalement modulaire, au point de séparer le portail des fonctions d'authentifications. On le approfondira ce point plus tard mais le portail sollicite le Web Service MgmtSvc-WindowsAuthSite dédié pour l'authentification des utilisateurs du portail d'administration de Windows Azure Pack. Etant donné que cela donne accès aux privilèges les plus élevés de la plateforme, c'est pas le portail accessible par monsieur tout le monde qui consomme du cloud. La recommandation serait même de ne pas l'exposer sur Internet. Pour cette raison, je n'ai pas personnalisé l'URL (cela aurait été nécessaire dans un scénario de HA), ni changé le port par défaut. De toute façon vu que c'est pas visible des utilisateurs consommateurs du service, ce n'est pas essentiel à mes yeux.

    clip_image009

    Note : Ici encore, il faut redémarrer le Web Service pour qu'il prenne en compte la nouvelle configuration.

     

    Fracassons maintenant le portail des locataires

    Maintenant qu'on a fracassé le portail des administrateurs de la plateforme, autant continuer avec le portail des locataires et foutre le bordel jusqu'au bout. C'est donc le site MgmtSvc-TenantSite dans la console IIS. Par défaut, il utilisait aussi un certificat auto-signé et un 30081 comme port exotique.

    clip_image010

    Note : On n'oublie pas de redémarrer le site web pour être sûr que le portail ne fonctionne plus.

     

    Achevons le dernier Web Service

    Pour le portail des locataires, la fonction est elle-aussi externalisée dans le Web Service MgmtSvc-AuthSite. D'un point de vue technique, c'est intéressant car on peut proposer deux politiques d'authentification distincts utilisant des technologies différentes. Ici, c'est le Web service vers lequel les locataires sont redirigés pour s'authentifier. Il sera donc exposé sur Internet (mais pas directement, on a le Web Application Proxy pour cela, un autre WAP). Initialement, le Web Service utilise un certificat auto-signé au nom du serveur sur lequel le module est installé et utilise le port 30071. Du point du vue des futurs consommateurs du service, c'est tout sauf user-friendly. On va donc utiliser la même URL (et donc le même certificat) que pour le portail et utiliser le port 444.

    clip_image011

    Note : On n'oublie pas de redémarrer le site web pour être sûr que le portail ne fonctionne plus. A ce stade, le commandant sylvestre a atteint son objectif.

    Now fun begins, Time to dive into Windows Azure Pack Admin API

    Bizarrement, à ce stade, plus rien ne fonctionne. Et pour cause, même si on a changé les bindings dans IIS, les différents composants n'en savent rien. La configuration stockées dans la base de données de Windows Azure pack doit aussi être actualisée. Passons donc du côté obscur de Windows Azure Pack avec le module PowerShell MgmtSvcConfig.

    clip_image012

    Rien qu'en parcourant la liste des commandes associées à ce module, on repère tout de suite que certaines vont occasionner de sérieux maux de tête, voire des "nervous breakdown" comme ils disaient dans les tontons flingueurs. C'est bien d'avoir la liste des commandes mais on veut reconfigurer des modules de Windows Azure Pack, plus précisément des Namespaces. Voyons la liste des namespaces que nous pouvons gérer avec la commande Get-MgmtsvcNamespace :

    clip_image013

    Ça commence à causer. Dans la liste des namespaces, on retrouve certaines notions que nous avons déjà vu et d'autres que nous ne connaissons pas encore. C'est normal, Windows Azure Pack est totalement modulaire. Lorsqu'on ajoute un nouveau module, on a donc un nouveau namespace. Ça commence à devenir intéressant car Microsoft propose une API unifiée pour gérer tous les namespaces même si ça concerne MySQL (What?).

    Avant de se lancer dans la reconfiguration à tout va, essayons de comprendre comment fonctionne le processus d'authentification du portail d'administration de Windows Azure Pack. Par défaut, le processus d'authentification utilisé par le Web Service dédié au portail d'administration utilisera l'authentification Windows intégrée. Certes nous avons uniquement changé les bindings dans IIS mais vu que tous les modules doivent communiquer entre eux, il faut bien que l'information soit stockée à un emplacement (La base SQL de Windows Azure Pack).

    La commande Powershell Get-MgmtSvcFQDN permet de connaitre les informations de configuration pour le namespace AdminSite. Si on compare avec ce que nous avons maintenant dans IIS, effectivement nous avons un problème.

    clip_image014

    L'AdminSite va devoir solliciter le web service d'authentification et ce dernier devra renvoyer l'utilisateur au portail une fois authentifié. Le problème, c'est que le Web Service va utiliser l'information dans la base SQL pour déterminer où renvoyer l'information. Une actualisation du namespace s'impose pour référencer la nouvelle URL ainsi que le port à utiliser. La commande PowerShell Set-MgmtSvcFqdn est faite pour cela.

    clip_image015

    Le portail, c'est ce qu'il y a de plus visible du point de vue des administrateurs de Windows Azure Pack. Pourtant, il y a aussi le Web service dédié à l'authentification. Lorsqu'ils vont tenter d'accéder au portail, la première chose que celui-ci va faire sera de les rediriger vers le Web Service. C'est un RelyingParty, on va causer gestion d'identité (sic). La commande Get-MgmtSvcRelyingPartySettings permet d'explorer le paramétrage du namespace Admin. Le web service est configuré pour utiliser un certificat auto-signé (correspondant au nom du serveur Windows Azure Pack sur lequel il est installé) et un port exotique : 30071.

    clip_image016

    Bref, ici encore c'est un peu bancal. On va donc l'aider un peu en reconfigurant le RelyingParty pour utiliser un nouveau port 30072 et au passage utiliser le nouveau certificat, le tout avec un petit Set-MgmtSvcRelyingPartySettings.

    clip_image017

    j'ai perdu personne? Donc l'administrateur s'est connecté au site d'administration, lequel l'a redirigé vers le web service d'authentification. Après authentification, il faut le renvoyer à l'envoyeur vers le portail d'administration de Windows Azure pack. Et vous croyez qu'il va renvoyer vers qui? Cette fois c'est au fournisseur d'identité que nous devons nous adresser avec la commande Get-MgmtSvcIdentityProviderSettings.

    clip_image018

    Il renvoie bien vers notre serveur mais notre portail d'administration ne répond plus à cette adresse. Maintenant c'est WAPADMIN.WINDOWSAZUREPACK.LAN. Bref, il faut lui aussi l'aider un peu pour lui indiquer la bonne URL et le bon port. A ce stade, il est essentiel de disposer d'un accès à la base de données de Windows Azure Pack et de la commande Set-MgmtSvcIdentityProviderSettings.

    clip_image019

    Pour une raison que j'ignore, la commande de fonctionne que si on lui adjoint le paramètre DisableCertificateValidation. Sans lui, la commande ne passe pas. Après une recherche rapide, le paramètre est nécessaire uniquement si on utilise des certificats auto-signés

    clip_image020

    A mon niveau, je ne suis pas encore capable de déterminer si c'est un problème de ma configuration ou un effet de bord des certificats auto-signés qui pullulent sur l'environnement. Mais, je prends quand même les paris pour un effet de bord du à la présence des certificats auto-signés.

    C'est clos pour le portail d'administration de Windows Azure Pack. Intéressons-nous maintenant au portail de locataires. Cela va suivre la même logique ou presque. La subtilité, c'est l'utilisateur. Pour les administrateurs, ce sont des comptes de l'annuaire Active Directory. Pour les locataires, c'est pas si évident que cela. Le portail des locataires va consommer des claims en provenance d'un fournisseur d'authentification qui peut être ADFS ou .Net. Ça ouvre des perspectives. C'est ce dernier qui est configuré par défaut. Plus précisément, c'est le ASP.NET Membership provider. On s'attaquera à celui-là en dernier. Commençons par la gestion des URL du namespace TenantSite. Voyons un peu la configuration par défaut avec la commande Get-MgmtSvcFQDN :

    clip_image021

    On va devoir personnaliser l'URL (WAPCLOUD.WINDOWSAZUREPACK.LAN) et reconfigurer le port par défaut car 30081, c'est tout sauf user-friendly. La commande Set-MgmtSvcFQDN va nous y aider.

    clip_image022

    Le portail, c'est bien mais on sait très bien qu'il y a un web service en charge de l'authentification qui doit être corrigé. C'est ne namespace AuthSite. La commande Get-MgmtSvcFQDN nous révèle la configuration de ce namespace :

    clip_image023

    L'URL et le port par défaut doivent être reconfigurés. Vu que dans ma configuration je n'ai pas séparé le portail et le Web Service d'administration, je peux réutiliser le même FQDN, on va juste utiliser un port différent 444. Un petit coup de Set-MgmtSvcFQDN va régler le problème.

    clip_image024

    Les URL sont normalisées, reste maintenant à traiter la redirection vers le site d'authentification et le retour. Voyons comment le portail gère la redirection vers son RelyingParty avec la commande Get-MgmtSvcrelyingPartySettings.

    clip_image025

    Nous allons donc rediriger vers wapcloud.WindowsAzurepack.lan (pourquoi 444? Tout simplement par ce qu'on a déjà le portail admin sur 443 et que tout est installé sur le même serveur IIS) avec la commande Set-MgmtSvcrelyingPartySettings.

    clip_image026

    Il ne nous reste plus que le fournisseur d'identité, c'est la petite surprise. Un peu plus tôt, j'avais indiqué que par défaut, le module d'authentification du portail des locataires utilisait le fournisseur ASP.NET Membership. C'est juste un nouveau namespace à manipuler : Membership. Voyons à quoi il ressemble avec la commande Get-MGMTSVCIdentityProviderSettings.

    clip_image027

    Reste plus qu'à rediriger vers la source, à savoir wapcloud.windowsazurepack.lan.

    clip_image028

    Ca y est, c’est fini.

     

    Sinon ça marche à la fin?

    Ben oui, on ne se donne pas autant d'effort pour que cela ne fonctionne pas. Ci-dessous le portail de locataires avec une URL nettement plus user-friendly :

    clip_image029

    Et le portail des administrateur de Windows Azure Pack :

    clip_image030

    Windows Azure Pack peut sembler un peu "brut de décoffrage” mais si vous regardez son grand frère Windows Microsoft, c'est exactement la même chose. Lorsque de nouvelles fonctionnalités sont annoncées, elles sont utilisables en premier lieu en PowerShell avant d'être disponible dans l'interface graphique et c’est lui aussi un produit hautement modulaire.

     

    Prochaine étape cortex?

    C'est de dominer le monde minus, offrir des services cloud et dominer le monde minus. Plus sérieusement, on va passer un peu de temps pour exposer le portail des locataires sur Internet et travailler un peu les mécaniques d'authentification.

     

    Que les API du Windows Azure Pack soient avec vous

     

    BenoîtS - Simple and secure by design but Business compliant

Petite KB pour les upgrade de domaine W2K3 vers W2K12 R2

Back to basics. C’est la saison des projets d’upgrade des infrastructures basées sur Windows 2003. l’OS a presque dix ans. Dans le cadre d’un projet de mise à niveau des infrastructure d’annuaire, nous aurons donc des contrôleurs de domaine Windows 2003 qui devront coexister avec des contrôleurs de domaine Windows Server 2012 R2. Selon le technet, cela ne devrait pas poser de problème.

Pourtant, l’équipe en charge du support Active Directory avait publié ce billet en Juillet 2014 : It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers. La coexistence entre les deux générations de contrôleurs de domaine posait problème au niveau de Kerberos. D’un coté Windows Server 2012 R2 ne supporte plus DES (par défaut) et Windows Server 2003 ignore les nouveaux algorithmes proposés par Windows Server 2012 R2. Bref, on avait une certaine cacophonie au niveau de Kerberos qui pouvait conduire à l’impossibilité de changer le mot de passe des systèmes raccordés au domaine. Pour adresser cette problématique, Microsoft proposait une méthode de contournement (en attendant de finaliser le démantèlement des contrôleurs de domaines Windows 2003).

Depuis fin Aout, la méthode de contournement proposé par Microsoft n’est plus d’actualité puisqu’un correctifs est enfin disponible : KB2989971 - Can't log on after changing machine account password in mixed Windows Server 2012 R2 and Windows Server 2003 environment. A installer sur tous vos contrôleurs de domaine Windows Server 2012 R2.

 

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

Quelques notes sur Windows Azure Pack

Depuis fin 2013, je suis tombé dans le monde de Windows Azure Pack. C'est un peu comme DirectAccess, un grand jeu de lego, sauf qu'il y a bien plus de briques, donc c'est plus amusant. Bref, c'était fait pour moi. Windows Azure Pack est un composant de la vision Cloud OS de Microsoft. J'y ai passé beaucoup de temps mais pas encore eu réellement le temps de tout synthétiser. Le but de ce premier billet est de synthétiser le contenu éparpillé dans mes nombreux OneNote sur su sujet.

The Cloud OS

clip_image001

L'idée est d'avoir une plateforme commune pour l'hébergement et le développement de services Cloud à base de Windows Microsoft Azure. Avec l'approche Private Cloud Fast track program, on utilisait les composants de la gamme System Center pour transformer le Datacenter en Cloud privé que l'on pouvait étendre par la suite à Windows Microsoft Azure. Cette approche du Cloud Hybride montrait à quel point Windows Microsoft Azure est différent des produits de la gamme System Center. Avec Windows Azure Pack, ce sont des composants Windows Microsoft Azure qui font le chemin inverse vers les entreprises et des hébergeurs pour mettre à disposition un certain nombre de fonctionnalités de Windows Microsoft Azure.

Cette approche permet aux clients de disposer d'une socle commun "Windows Microsoft Azure" que celui-ci soit :

  • Hébergé “on premise”
  • Hébergé chez un hébergeur
  • Hébergé dans Windows Microsoft Azure

 

Windows Azure Pack est une plateforme Cloud évolutive proposant plusieurs services directement inspirés de Windows Microsoft Azure :

  • Pour l'utilisateur final, Windows Azure Pack offre une interface utilisateur unifiée très proche du portail Windows Microsoft Azure, qui peut être étendu par ajout d'extensions. La localisation des ressources gérées importe peu.
  • Pour un DBA, il a la possibilité d'héberger ses bases de données SQL/MYSQL "on premise", chez un hébergeur ou même dans Windows Microsoft Azure avec la capacité de les déplacer librement. Ces ressources peuvent être mises à disposition d'utilisateur par simple souscription à un contrat. C'est un service dont l'usage est mesurable et donc facturable.
  • Pour un développeur web, c'est une plateforme PAAS hautement disponible pour de l'hébergement de sites web / Web Services.
  • C'est aussi une offre IAAS d'infrastructure proposant l'hébergement de machines virtuelles Windows ou Linux inspiré de ce que propose Windows Microsoft Azure.

 

Modularité extrême

Lors de l'installation, on comprend que Windows Azure Pack n'est pas un nouveau composant de la gamme System Center. Il vient bien d'un monde différent ou on assemble des Web Services. Cela ne l'empêche pas de coexister avec les composants de la gamme System Center.

clip_image002

 

Web Services & Json tu causeras

Windows Azure Pack est totalement modulaire et repose sur des Web Services qui communiquent entre eux. Certes tous ces Web services peuvent cohabiter sur une même machine mais dans le cadre d'un environnement de production on s'efforcera de les répartir dans différentes zones et d'assurer leur haute disponibilité avec du HLB.

clip_image003

 

Je vois des certificats partout

Qui dit Cloud & Web Services dit certificat et donc souffrance (ou fun, c'est selon). Plus on s'amusera (oui c'est fun) à isoler différents rôles et assurer la disponibilité, plus on aura de certificats à gérer. Dans l'illustration ci-dessous, la version simpliste avec tous les composants mutualisés sur un seul et unique serveur. Oui on dénombre bien quatorze certificats auto signés.

clip_image004

Cela veut dire qu'à un moment on va devoir les remplacer, et reconfigurer les web services et Windows Azure Pack pour les utiliser. C'est la partie la plus fun du setup de la plateforme.

 

On causera de bases de données

La modularité de Windows Azure Pack implique un certain nombre de bases de données. Certes beaucoup moins que le nombre de certificats ou de Web services mais cela impliquera une petite réflexion quant à la disponibilité et la localisation de ce service.

clip_image005

 

Un peu de découpage réseau

Même si tous les composants de Windows Azure Pack peuvent coexister sur un même serveur, ce n'est pas la configuration recommandée pour des raisons sécurité mais aussi haute performance. Tout comme Windows Microsoft Azure, tous les composants ne nous sont pas visibles de l'extérieur. L'infrastructure Windows Azure Pack doit être découpée en zones réseau. On peut déjà identifier les principales zones :

  • Public facing
  • Privilegied Services
  • Identity
  • Database

La zone réseau "public facing" est dédiée aux services en relation directe avec nos locataires (tenants). Windows Azure Pack offre :

  • Un portail utilisateur très proche du portail Windows Microsoft Azure
  • Un Web Service en charge de l'authentification des locataires (dont ADFS peut faire partie)
  • Un Web service fournissant toutes les API "publiques" nécessaires au bon fonctionnement de ces services

La zone réseau "Privilegied services" n'est pas censé être visible des utilisateurs du service mais de ses exploitants. On retrouvera donc :

  • Un portail Administrateurs lui aussi très proche du portail Windows Microsoft Azure
  • Un Web Services en charge de l'authentification de nos administrateurs
  • Un Web Service fournissant toutes les API nécessaires au bon fonctionnement de ces services (il fournira le support de PowerShell pour permettre à nos locataire de gérer leurs ressources)
  • Un Web service fournissant toutes les API "privé" nécessaires au bon fonctionnement de ces services

 

La zone réseau "Identity" va contenir deux services critiques : Active Directory et ADFSv3. Ce dernier sera utilisé depuis la zone "Public facing" pour chalenger l'authentification des locataires. Enfin, reste une dernière zone pour héberger nos bases de données. Tous nos composants du Windows Azure Pack, ADFS et d'autres ont besoin d'un service de base de données hautement disponible. Autant avoir une zone réseau dédié à cet usage pour consolider nos bases de données sur un cluster. En plus cela permettra de préparer l'introduction des composants de la gamme System Center 2012 R2.

 

Ton lab tu étendras

Si tous les composants de Windows Azure Pack peuvent être hébergés sur une même machine, ce n'est pas la configuration recommandé pour les environnements de Production. Pour commencer, voilà ci-dessous ce que serait un déploiement minimaliste avec la haute disponibilité (sic) :

clip_image006

On pourrait penser qu'il est simple de séparer tous ces composants mais ce n'est pas le cas, pour plusieurs raisons :

  • Le processus d'installation utilise "localhost" dans l'URL de tous les Web Services. Il faudra donc reconfigurer des URL : Windows Azure Pack changing the default URLs.
  • Si tous les composants sont installé sur un même hôte les certificats auto-signés ne sont pas un problème. Dès lors qu'on va séparer les rôles, il faudra reconfigurer les Web Services et Windows Azure Pack pour utiliser des certificats délivrés par une autorité de certification.
  • Enfin, c'est plus présentable pour l'utilisateur de présenter des URL propres, utilisant toutes le port 443 et non un port situé dans la plage de ports dynamique.

Ça commence à piquer les yeux. Pas de problème, on peut monter en charge et découper par rôle au sein de Windows Azure Pack. Maintenant on est presque au complet :

clip_image007

On notera au passage qu'à ce stade, on ne parle pas d'extensions additionnelles (Web Sites, Virtual machines) voire même des composants de la gamme System Center dont on aura besoin et pour lesquels il faudra assurer aussi la disponibilité. Avant de vous lancer dans la haute disponibilité, la lecture ci-dessous est vivement conseillée :

Windows Azure Pack High Availability – Lessons Learned.

 

Pour héberger des services clés en main

C'est la force de Windows Azure Pack. Beaucoup d'extensions sont déjà disponibles. On évite donc de réinventer la roue pour se focaliser sur le service à offrir aux utilisateurs :

  • Web sites : Un service de publication de site web très proche de celui disponible sur Azure
  • Services bus : Un service d'échange de message pour applications
  • MS SQL extension : Un service d'hébergement de bases SQL
  • MY SQL extension : Un service d'hébergement de bases My SQL
  • MY Cloud : Un service d'hébergement de machine virtuelle basé sur SCVMM
  • Cloud Cruiser : Un service tiers dédié au reporting & billing des services consommés par nos locataires
  • Grid-pro : Une passerelle vers Service Manager

Après, rien de vous empêche de développer vos propres extensions.

 

Service Management Automation

Le Cloud ne serait pas possible sans une bonne dose d'industrialisation. Avec Windows Azure Pack, Microsoft livre Service Management Automation, une solution d'orchestration totalement intégrée qui permet d'exploiter les évènements remontés par les différents composants (inscription d'un utilisateur, souscription à un plan, …) pour déclencher des actions reposant sur des Workflow PowerShell. Deux exemples parlants :

  • Créer automatiquement le VM Network ainsi que le contrôleur de domaine lors de la création d'un nouveau tenant. L'idée étant de lui pré-provisionner les briques minimales pour héberger son propre environnement. La première brique étant un annuaire Active Directory. Après, rien de nous empêche de provisionner automatiquement d'autres services.
  • Installer automatiquement un agent SCOM sur toute machine virtuelle nouvellement déployée par un locataire.

D'ailleurs, on notera que Windows Microsoft Azure propose désormais le même service sous la dénomination Microsoft Azure Automation.

 

ADFS et Windows Azure Pack

A un moment, il faudra bien parler d'authentification, que ce soit pour les locataires ou les administrateurs de la plateforme. Pour les locataires, l'usage d'ADFS s'impose de lui-même. Les lectures suivantes sont vivement conseillées ainsi que de prendre son temps :

Pour les administrateurs du service, on considère qu'ils utiliseront par défaut une authentification intégrée Windows. Or, un peu d'authentification forte, cela ferait pas de mal. Pour cela, on a Multi-Factor Authentication qu’il est possible d’intégrer à Windows Azure Pack :

 

Service Provider Foundation

Lorsqu'on voudra faire du IAAS, il faudra communiquer avec Virtual Machine Manager. Dans sa version actuelle (2012 R2), il n'est pas possible de consommer du SCVMM directement depuis Windows Azure Pack car le premier utilise uniquement des API Rest (oData), ce que le second ne comprend pas. De plus, pour consommer des ressources dans SCVMM, il faudra bien une identité au sens Active Directory pour séparer les usages entre les différents Clouds. Le Service Provider Foundation permet donc d'exposer les services de SCVMM (jusqu'à 5 instances de SCVMM) à Windows Azure Pack. De plus le SPF permettra de mesurer l'usage du service IAAS contribuant ainsi à rendre le service mesurable et facturable, comme tout bon service Cloud. Quelques lectures sur ce sujet :

 

Les extensions de Windows Azure Pack

Windows Azure Pack est modulaire. On peut donc simplement ajouter de nouvelles extensions pour proposer de nouveaux services :

 

Un peu de lecture

A ce stade, je suis resté volontairement très "high level". Le sujet étant très vaste, ci-dessous quelques lectures qui m'ont beaucoup aidé sur le sujet :

 

Quelques pointeurs pour commencer

Quelques session du TechEd America 2014

 

Quelques outils bien pratiques

Pour finir, quelques blogs de MVP bien utiles

 

Je retourne étendre mon lab.

 

BenoîtS - Simple and Secure by design but Business compliant

Solve W2K12R2 DirectAccess OTP activation problem with Powershell

I was working on a DirectAccess POC for a customer of mine a few months ago. Now it’s time to go in production and moving from Windows 2012 to Windows Server 2012 R2. I was rebuilding my lab and have a closer look at KB2883952 to avoid most of problems. This time, problem is not in the list. I was not able to configure OTP authentication for DirectAccess because no capable ADCS can be used to provide required certificates.

0

Not logic, my lab worked like a charm in Windows Server 2012, so ADCS role configuration was good. Because it’s only a prerequisite check, let’s try to configure OTP scenario using the Enable-DAOTPAuthentication PowerShell commandlet and surprised, it worked !

1

Even if it worked from the PowerShell commandlet, the console does not recognize ADCS as compatible but it’s no longer blocking in the configuration process.

2

PowerShell rules!

 

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

August 2014 update rollup for Windows 8.1 what’s new for DirectAccess

There is nothing to do in august, except being in vacation. It’s not the case for Microsoft folks who just released the August rollup for Windows 8.1/RT/Windows Server 2012 R2.

If we take a look at the related KB2975719, we will discover that’s it include improvements but also bug fix, one two of them is are related to DirectAccess :

  • KB2966087 : You intermittently cannot connect to the DirectAccess server by using the IP-HTTPS adapter in Windows 8.1 and Windows Server 2012 R2.
  • KB2984374 : Connect to incorrect entry point when Windows 8.1 or Windows Server 2012 R2-based computer wakes from sleep or hibernate (Thank you Jason, I missed it)

So we have something to deploy in august. Don’t wait and update your DirectAccess clients

 

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

Windows Remote Assistance between DirectAccess clients made easy and simple

Remote Management is one of the top feature provided by DirectAccess. By default a DirectAccess client is able to reach internal resources such as SCCM server but the contrary is much more difficult as it require an IPv6 connectivity from end to end. Initiating a remote assistance (MSRA) from a helpdesk station located on LAN is much more complicated. Microsoft recommendation about ISATAP is to do not deploy it at enterprise scale level but limit it to only required hosts. I strongly recommend the Limiting ISATAP Services to DirectAccess Manage Out Clients from Jason Jones to understand initial configuration. If someday you wish to become a DirectAccess Jedi master have a look at my series of blog post to establish secure communication for Windows Remote Assistance :

 

Core of the problem

It's cool to have Windows Remote Assistance for DirectAccess clients but it works because we have a built-in ISATAP router included with our DirectAccess Gateway. In some scenarios, feature will no longer be available. Have a look at the result of an HLB deployment scenario.

clip_image001

According to this excellent article we have two choices :

  • Place an external load balancer that supports ISATAP on the internal network and enable ISATAP on either DirectAccess servers
  • Disable ISATAP completely which then disables the “manage-out” functionality of DirectAccess.

Note that ISATAP routing capability is also unavailable in multi-site scenario.

Let's analyze these options :

  • Option 1 : Having a load balancer that support ISATAP is not unrealistic at all but enabling ISATAP router on only one node is not. If that DirectAccess gateway happened to fail, ISATAP routing would stop too (SPOF Hunter)
  • Option 2 : If you are here, you're looking for a solution to this problem, so abandon is not an option

 

We need a third option. I tried multiple options. Even a complete season of Doctor who did not provide me inspiration. If even the Doctor does not have the solution who will?

clip_image002

Two seasons of Doctor who were required to see the beginning of the solution.

 

What my blog say?

I used so sign my blog post by "Simple and Secure by Design but Business compliant". Too complicated does not means impossible. Let's see the problem from another point of view. Until now we considered remote management as a IPv6 flow from an internal IPv6 capable client connecting to a DirectAccess client connected on Internet. That solution provide end to end IPv6 connectivity. That's right but that's not the only case. Just consider two DirectAccess clients connected on Internet. They both have IPv6 addresses. Would it be impossible to have two DirectAccess clients communicating together? Doctor, an advice? A screw-driver?

 

Are DirectAccess clients able to communicate each other?

If we just test with Resolve-DNSName PowerShell commandlet, a DirectAccess client is able to resolve DirectAccess names of other DirectAccess clients.

clip_image003

So if required network flow are correctly configured (never forget your NAT-Transversal configuration for incoming network flow), it should be OK. But each time we try to establish communication between DirectAccess clients it seems to fail. Why would two IPv6 hosts that seems to be located on the same network would be unable to communicate? Can we get the IPv6 prefix used to generate IPHTTPS addresses to check?

clip_image004

Correct, they depend on the same subnet (logic). So why two IPv6 hosts located on the same IPv6 network would be unable to communicate using global unicast addresses?

clip_image005

 

Two hosts located on the same IPv6 Subnet should be using Link local addresses to communicate? Because we have a DNS response with a Global Unicast Address, DirectAccess tunnels try to route our traffic to the internal network. What would happen if we try to communicate with the Link-local address. Here is the Link-local address of the interface of W82.DirectAccessLab.Lan :

clip_image006

And here is the result from W81.DirectAccesslab.Lan

clip_image007

 

You're skeptical, need more evidence? OK, let's go deep dive into the IPv6 routing

clip_image008

TRACERT.EXE reveal a direct communication without usage of the gateway, and the Get-NetRoute Powershell command validate that any FE80 prefix have the same destination (same subnet). We got it.

 

Wait a minute, What append to Security?

Good question. Have a look in the connection security rules node in your Windows Firewall console of a DirectAccess client :

clip_image009

Now you understand. Communication between DirectAccess clients are not protected by IPSEC rules. But you're a Jedi master now, you were well trained with the DirectAccess remote management, from Padawan to Jedi Knight blog post series.

 

Show me your skill Jedi

If we can secure communication from internal IPv6 host to DirectAccess clients connected on Internet, it would not be difficult do to the same with two DirectAccess clients. All start with an isolation rule to create an IPSEC transport.

clip_image010

 

That will request authentication for any inbound/outbound communication (same rule for all DirectAccess clients whatever which one will initiate communication)

clip_image011

 

This rule will require some advanced authentication (just like DirectAccess IPSEC tunnels rules).

clip_image012

 

To make it simple, we will request dual authentication based on Kerberos protocol.

clip_image013

 

And this rule will only apply to public and private firewall profiles, we don't need this extra-level of security on internal network.

clip_image014

 

At last we finally put a name on it.

clip_image015

 

Because you're a Jedi master seating at the Jedi council, you filter the remote scope to only link local scope. We have here an extra-layer of isolation.

clip_image016

 

We have an IPSEC transport. Next point is to selected protocols to be configured for secure communication. Let's have a look at protocol definition of the Remote Assistance feature. So inbound rules, outbound rules, but some of them are more interesting as they only apply to DirectAccess (public profile). If you remember an old blog post we can enhance user experience of DirectAccess by forcing the public profile for the Windows firewall for any newly identified network. This is helpful to be sure that users cannot consider a new network as private.

clip_image017

 

So we only need to secure communication for incoming protocol related to the public firewall profile. So two inbound rules to reconfigure. Don't forget to enable Remote assistance and enable the required incoming firewall rules, especially the public rules.

clip_image018

 

Secure communication will mean authenticated and encrypted. Because connection must be secure, it will use our tunnel so only limit IPv6 for Windows Remote Assistance.

clip_image019

 

And we will be limiting our public incoming firewall rules to only a limited population represented by an Active Directory Security group. Only support team will be able to respond to a Windows Remote Assistance initiated by a DirectAccess client.

clip_image020

Now Windows Remote assistance between DirectAccess clients should be operational. Just try to send invitation. Network traffic between DirectAccess clients will be protected by an IPSEC transport. A simple Get-NetIPSECMainModeSA Powershell command will reveal an IPSEC transport between the two DirectAccess clients.

clip_image021

 

Need more proof? OK, let's have a look at established communication, one is interesting. Let's see witch process use it.

clip_image022

 

Now some additional tricks to make it works :

  • KB2665206 : Slow performance when you enable IPsec encryption on a specific TCP port number in Windows 7 or in Windows Server 2008 R2
  • KB2912883 : Remote Assistance connection to a Windows Direct Access client computer fails (Windows 7 & Windows 8)

 

Like a other Doctor use to say. Use it :

useit

 

Now you can call the psychiatrist. I deserve my straitjacket.

 

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

Pack de mises à jour Orchestrator 2012

C’est la livraison de l’été. Microsoft a mis à disposition les updates rollup pour la gamme System Center. Pour Orchestrator, on est donc maintenant avec :

 

Subtilité, pour Orchestrator 2012 R2, cela comprend aussi Service Management Automation (SMA) qui est livré sur le même média.

 

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

DirectAccess OTP Mystery case solved

Each month, Microsoft provide a bunch of updates for it’s operating systems and this month, the rollup contain an interesting fix for DirectAccess infrastructure. If we have a closer look at updates included we will find this one :

image

As your DirectAccess infrastructure must include a strong authentication mechanism, you will be happy to discover that Microsoft solved the  “0x80040001 OTP mystery case”. At first logon OTP works like a charm but later it stopped working. If we have a look at KB2973071 details, we will discover that the One-Time Password Certificate Enrollment (OTPCE) continued to use the expired certificate for authentication instead of the new one. As I was able to reproduce this with Windows 8.1 and Windows 7, maybe Microsoft provide an Hotfix for the “Legacy Windows 7 operating system”? Bingo : KB2939489.

 

If you want to know more about OTPCE, have a look at the protocol specifications available on MSDN.

 

So don’t forget to add these KB to your DirectAccess KB List.

 

Simple and Secure by design but Business compliant.

Le POC SCSM en prod, pas glop comme idée

Faire un POC en prod, voila une fausse bonne idée. On se dit qu’avec la version d’évaluation et ses 180 jours, on a tout le temps. Si le POC se transforme en production, faudra juste saisir le numéro de licence. Mais que se passe t’il si on dépasse la période d’évaluation avec SCSM?

Coté console SCSM, c’est pas très parlant.

0

 

Même la vue avancée ne nous avance pas plus “Unknow exception”.

1

 

La il faut parcourir le log “Operation Manager” pour découvrir la raison :

2

 

Cela semble clair. Petite recherche rapide chez Microsoft et on trouve l’information ci-dessous :

image

 

Conclusion, le POC en prod pour SCSM, est une véritable fausse bonne idée. Paie ta licence.

 

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

Multisite DirectAccess scenario in Powershell

Multisite is a very interesting scenario that was complicated to deploy with Windows 7 and Forefront UAG. If this challenging scenario does not scared you, have a look at this Edge Man post. Technically speaking, it was also possible to achieve a “similar” configuration with a Global Server Load Balancing configuration using F5 Big-IP for example. With Forefront UAG 2010, we had load-balancing capabilities with Network Load Balancing and Hardware Load Balancing but it was long to setup. Have a look at my high-availability blog post series if you want to compare to this blog post!

 

In Windows server 2012, multisite will become (this post is written with the Consumer Preview released in February 2012!) a much more easier deployment. What an interesting challenge to deploy it with PowerShell only. First, let’s see my configuration  :

MULTISITEVISIO 

We have two sites having their own Windows 2012 server. The challenge is to setup the DA1 server as a DirectAccess server, convert it to multisite and and add DA2 as a new Entry Point for my Multisite configuration. Now let’s switch to PowerShell!

 

Initial DirectAccess configuration

Let’s start with my first DirectAccess server setup. It’s name is DA1.DirectAccessLab.Lan we start with the role installation :

Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools

ADDFEATURE0

 

In order to be sure that everything is operational, let’s check it with a single PowerShell command : Install-RemoteAccess –Prerequisite

ADDFEATURE1

 

I will need an IPHTTPS certificate on DA1.DirectAccessLab.Lan. Public name record in my certificate will be DA1.DirectAccessLab.Lan. Let’s check that my certificate is present in the computer store with the following command :

$IPHTTPS = (Get-ChildItem Cert:\\LocalMachine\My | Where {$_.Subject -like "CN=DA1.DirectAccessLab.Fr*"})

Write-Host $IPHTTPS

IPHTTPS1

 

Now, it’s time to configure our first DirectAccess server with a single PowerShell command :

Install-RemoteAccess -DAInstallType FullInstall -ConnectToAddress DA1.DIRECTACCESSLAB.FR -ClientGPOName "DirectAccesslab.Lan\DirectAccess Clients GPO" -ServerGPOName "DirectAccesslab.Lan\DirectAccess Servers GPO"-InternalInterface LAN-InternetInterface INTERNET -NLSURL https://nls.directaccesslab.lan –Force –PassThru

INSTALLREMOTEACCESS0

 

Server-side configuration is almost terminated. We need to configure Certification Authority to be used for IPSEC tunnels authentication. It is mandatory for multisite deployments, just like having a real IPHTTPS certificate for each entry point. The following PowerShell command will configure this :

$CA = (Get-ChildItem Cert:\\LocalMachine\Root | Where {$_.Subject -like "CN=INET*"})

Write-Host $CA

Set-Daserver -IPSecRootCertificate $CA -PassThru

FINALIZESERVER1

 

Now let’s switch to the client-side configuration with the Following PowerShell commands :

Add-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\DA Clients”

Remove-DAClient –SecurityGroupNameList “DirectAccesslab.Lan\Domain Computers”

Set-DAClient –OnlyRemoteComputers Disabled

Get-DAClient

CLIENTSIDE

 

Client-side configuration is almost complete, we just need to configure some settings for end-user experience for the Network Connectivity Assistant. PowerShell commands bellow will configure it with an HTTP type probe located on a domain controller : 

Set-DAClientExperienceConfiguration -PolicyStore "DIRECTACCESSLAB.LAN\DirectAccess Clients GPO" -UserInterface $True -SupportEmail HelpDesk@DirectAccesslab.fr -CorporateResources {HTTP:http:dc.directaccesslab.lan} -PreferLocalNamesAllowed $True -FriendlyName "DirectAccess Connection" -PassThru

SETDACLIENTEXPERIENCE

 

Our first DirectAccess server is now operational. Let’s check that with a Get-RemoteAccessHealth command :

GET-REMOTEACCESSHEALTH0

 

If you need more explanations on this part, have a look at my DirectAccess in Powershell blog post.  Now we are ready for Multisite!

 

 

Enabling Multisite

We have a standalone server that must be converted as the first entry point of a Multi-site DirectAccess configuration. Each DirectAccess Server (or High-available group of DirectAccess servers) is considered as a DirectAccess Entry point. Let’s convert to Multi-Site :

Enable-DAMultiSite -EntryPointName "EMEA Headquarter" -ComputerName DA1.DirectAccesslab.Lan -ManualEntryPointSelectionAllowed Enabled -Name "DirectAccesslab Multi-Site Infrastructure" -PassThru – Force

ENABLEMULTISITE

 

Multi-site configuration is enabled with a single entry point named “EMEA Headquarter”. The  Get-DAEntryPoint command will provide some details on this entry point  :

GETDAENTRYPOINT1

 

Not many information. This entry point is not GSLB enabled and include a single server. Let’s have a look at this entry point with the Get-DAServer PowerShell command :

Get-DAServer -EntryPoint "EMEA Headquarter"

GETDAENTRYPOINT2

 

We have the same information as in standalone configuration. From a server point of view, there is not much more difference. At this point our only requirements are :

  • Do not use self-signed certificate for IPHTTPS
  • Enable computer certificates

 

By now we have operational Multisite DirectAccess infrastructure And that's all for Multisite activation!

 

Adding a new entry point

Now come the most interesting part of this blog post : How to add a second entry point remotely. At the beginning of this step, my DA2.DirectAccessLab.Lan server is :

  • Joined to the DirectAccessLab.Lan Domain with a LAN named interface
  • Configured with a public interface named INTERNET with a public IP address
  • Having a public IPHTTPS certificate with DA2.DirectAccessLab.fr as subject name

 

Here are the only prerequisites that wont be performed remotely! Just like our first DirectAccess server, we need to install roles. Let’s use PowerShell remoting capabilities : Add-WindowsFeature –Name DirectAccess-VPN –IncludeManagementTools -ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE2

 

And check it remotely : Install-RemoteAccess –Prerequisite –ComputerName DA2.DirectAccesslab.Lan

ADDFEATURE3

 

Before performing the magic trick, we must be sure that’s my IPHTTPS certificate for DA2.DirectAccessLab.Fr is present on my remote server :

$IPHTTPS = Invoke-Command –ComputerName DA2.DirectAccessLab.Lan –ScriptBlock {(Get-ChildItem Cert:\LocalMachine\My | Where {$_.Subject –Like “CN=DA2.DirectAccessLab.Fr*”})}

Write-Host $IPHTTPS

IPHTTPS2

 

And now, the magic trick. How to add a new DirectAccess Entry Point in an exiting Multi-site configuration remotely. As long as all prerequisites are already present, it’s a simple PowerShell Command :

Add-DAEntryPoint -Name "Backup Site" -ConnectToAddress DA2.DIRECTACCESSLAB.FR -InternalInterface LAN -InternetInterface INTERNET -ServerGPOName "DirectAccessLab.Lan\DirectAccess Backup Servers GPO" -RemoteAccessServer DA2.DirectAccessLab.Lan –PassThru -Force

ADDDAENTRYPOINT2

 

One thing we can notice is that we need an additional GPO to configure our new server. Each Entry point must have it’s own dedicated GPO. By now, our DirectAccess multi-site infrastructure have two entry point. The Get-DAMultiSite also report that users will be able to select the entry point they want to use. Windows 8 is able to connect to the first available entry point, but it’s not capable to really detect witch one is the closest from the client. Global Server Load Balancing feature was designed for that!

GETDAMULTISITE

 

If we take a look at our new entry point configuration with a Get-DAServer –EntryPoint “Backup Site” PowerShell command we can notice that there a much less information than for the first entry point. Information such as Internal Interface, InternetInterface or SSLCertificate are not provided. That’s must be a bug in the Consumer Preview version because these information are available if you run the same command on the remote server! That’s not a bug, it’s by design. Theses information will be available if you use the same Powershell CommandLet querying the server name and not the entry point.

GETDASERVERBACKUP

 

Let check everything

Everything seems to be operational on my first entry point. Some services are disabled but it’s normal (no 6to4 or Teredo support, no management server declared, no more OTP, …).

Get-RemoteAccessHealth –EntryPoint “EMEA Headquarter”

REMOTEACCESSHEALTH1

 

But on my second entry point we can notice one minor difference with ISATAP. My DA2.DirectAccessLab.Lan is not considered as an ISATAP router. It’s only an ISATAP client from my DA1.DirectAccessLab.Lan server.

Get-RemoteAccessHealth –EntryPoint “Backup Site”

REMOTEACCESSHEALTH2

 

In my opinion, it’s a bug on my lab. During DA2.DirectAccessLab.Lan configuration, my server already had an ISATAP interface properly configured. That’s must be why there is no ISATAP router on my server. This should not append in production environment (My lab need to be fixed on this point!)

 

And now from the client-side perspective

From a Windows 8 point of view, a DirectAccess Multi-site infrastructure is just two URL, one for each Entry point. So Multi-site only rely on IPHTTPS transition protocol. That’s why Teredo support is not active on my infrastructure (and because each entry point have only one IPv4 public address!). Windows 7 only support one URL for IPHTTPS interface, that’s why legacy operating systems cant use Multi-site.

Get-NetIPHTTPSConfiguration

GETNETIPHTTPSCONFIGURATION

 

It’s cool to have two entry point, but witch one is currently used? Simple : Get-NetIPHTTPSState

GETNETIPHTTPSSTATE

 

Back to server-side

Multi-site infrastructure is now operational. We need more than an active IPHTTPS interface to validate that point. We need to be able to track IPSEC sessions :

Get-RemoteAccessStatistics | Format-List

Get-RemoteAccessStatisticsSummary | Format-List

FINALSTATS

 

At last, the console view

Now we have an operational DirectAccess infrastructure with Multi-site capabilities. From the console point of view, here what’s it look like :

CONSOLEVIEW

 

Conclusion

I’m sure this deployment process can be fully automated (With PowerShell jobs). If you compare with my high-availability blog post series on Forefront UAG 2012, it will be now more easier to deploy DirectAccess in a high availability scenario and avoiding complex networking issues with Windows Server 2012. Infrastructure described in this post is not compatible with legacy clients (yes Windows 7 is a legacy client!) but there only few changes to allow these clients to connect to an entry point.

 

BenoîtS – Simple and Secure by Design but Windows 8 compliant!

MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege

Les GPO de préférences sont une évolution intéressante des GPO introduite avec Windows 2008. Cependant, il y a une petite faiblesse que Microsoft a enfin corrigé. Les GPO de préférences peuvent être utilisées pour créer/ mettre à jour des comptes de services sur les systèmes gérés. Problème, il faut bien stocker le mot de passe dans la GPO. Avec un peu de recherche dans le répertoire SYSVOL d’une GPO utilisant la fonctionnalité incriminée, on trouve le fichier GROUPS.XML :

INITIALDISCLOSE

Déjà en 2009, l’équipe Group Policy reconnaissait que les mots de passe manipulés par les GPO de préférence étaient plus “masqués” que “chiffrés” et qu’il fallait bien évaluer le risque. A la vue de l’illustration ci-dessus, on pourrait penser que le mot de passe est bien chiffré. Vrai, il est chiffré en AES 256 et faux car la clé est disponible sur le MSDNGêné. Pour vous en convaincre, exécutez le script Get-SettingsWithCPassword.ps1 mis à disposition avec la KB2962486 (il faut toujours lire un KB jusqu’au bout).

DISCLOSE1

Dans l’illustration ci-dessus le script a identifié une GPO avec un mot de passe masqué. Il a juste été nécessaire d’accéder à mon répertoire SYSVOL ou a une sauvegarde des GPO. Pour rappel toute GPO est librement accessible en lecture par défaut. 

Installer la KB2962486 ne fait que bloquer l’usage de la fonctionnalité, cela ne fait pas le ménage à votre place (d’ou l’intérêt de lire une KB jusqu’au bout). Le problème, c’est qu’il y a des développeurs Powershell talentueux qui ont développé des scripts plus complet, voire même trop  :

FINALDISCLOSE

Dans l’exemple ci-dessus, le script va jusqu’à révéler le mot de passe associé au compte “SECOURS_ADM”. Pour rappel, cette information est en libre accès (sauf si on retire le droit “read” sur la GPO pour les utilisateurs).

Que fait la KB alors? Ben elle corrige l’interface d’édition des stratégies de groupe de préférence pour nous empêcher d’utiliser la fonctionnalité.

NEW

C’est bien mais pour cela, il faut s’assurer de patcher tous les systèmes sur lesquels un administrateur utilisera l’éditeur de stratégies de groupes pour manipuler son contenu. Cela implique donc de patcher :

  • Les contrôleurs de domaine (GPMC est nativement installé)
  • Les serveurs membres (GPMC est potentiellement installé)
  • Les stations de travail (GPMC peut être installé si les RSAT sont installés)

 

En conclusion :

  • Abandonnez immédiatement l’utilisation des GPO de préférence pour manipuler les comptes & mots de passe
  • Faites la chasse aux stratégies de groupe utilisant cette fonctionnalité
  • Installez le correctifs sur tous les systèmes ou GPMC est potentiellement installé (pour éviter qu’un Administrateur ne recréé une GPO de préférence avec un mot de passe)
  • Formez vos Admins pour ne plus utiliser cette fonctionnalité!

 

Enfin, si c’est pour gérer le mot de passe Administrateur local de vos stations de travail, la solution ADMPWD est faite pour cela.

 

BenoitS – Simple and Secure by Design but Business compliant

Un peu de process d'ADMPWD dans ce monde de cloud (5/5)

Je sais très bien qu'au fur et à mesure de cette série de billet, j'ai perdu beaucoup de lecteurs à chaque étape, je m'en excuse. Pour les survivants, c'est la meilleure partie, à savoir comment appeler notre Runbook Orchestrator d'interface avec SCSM depuis SCSM. Pour les autres un petit interlude est nécessaire avant de reprendre et de se dire que je suis loin d'atteindre son niveau pour écrire des tutos pareils!

clip_image002

Vous êtes convaincus maintenant? Doumé, allons-y.

Commençons par les bas-fonds. Si on doit manipuler des objets extérieurs à Service Manager, il faut les référencer dans la CMDB. Orchestrator étant un produit de la gamme System Center, il y a donc un connecteur dans Service Manager. Il faut juste s'assurer que celui-ci a bien importé nos Runbook. Par défaut, il réalise cette opération selon un cycle de 24 heures et importe les Runbook qui ont été "Check-in". Histoire de ne pas attendre, on va lui forcer la main avec un peu de Powershell et quelques Commandlet issus du module de Service Manager.

clip_image004

Cette fois, c'était les dernières commandes Powershell dans ce monde de cloud. Le lien entre Orchestrator et Service Manager se fait au travers de la classe d'objets "Runbook Automation Activity" de la CMDB. On peut constater que tous les Runbook développés sont visibles. Celui qui nous intéresse, c'est celui en charge de l'interface avec SCSM (la seconde version).

clip_image005

Pour ce Runbook, j'ai créé un objet de classe "Runbook Automation Activity" dans la CMDB.

clip_image006

La caractéristique la plus importante pour un "Runbook Automation Activity", c'est la case d'option "Is ready for Automation" qui doit obligatoirement être cochée si on veut voir le Runbook être exécuté.

clip_image008

Lors du processus d'import, SCSM a clairement identifié les paramètres en entrée et en sortie. Dans notre cas, un seul paramètre en entrée nommé "ActivityID". Il faut juste faire le mapping entre un attribut de la CMDB et ce que nous allons passer en paramètre d'entrée à notre Runbook.

clip_image010

J'ai retenu de passer l'identifiant unique (le SC Object GUID) de l'objet "Runbook Automation Activity" qui sera créé lors de l'exécution de la "Service Request".

clip_image012

L'interface avec le Runbook est maintenant terminée. Il faut juste un appelant. Cet appel sera réalisé au travers d'une "Service Request" que nous allons créer sous forme de template.

clip_image013

Un objet "Service Request" est un ensemble d'activité qui sera réalisée. Cela peut contenir des activités de type "Runbook automation Activity", "Review Activity" (validation) ou même "Manual activity"). L'interface principale ne nous apprend pas grand-chose.

clip_image015

Par contre dans l'onglet "Activity", on retrouve bien notre template d'objet "Runbook Automation Activity" qui sera créé lors de l'exécution de la "Service Request".

clip_image017

Dernier étage, les interfaces. Par soucis de simplification, nous ne parlerons que de "Request Offering".

clip_image018

Une "Request Offering" est l'objet que nous voyons dans le portail. Il fait référence à une "Service Request" mais aussi aux paramètres à passer et l'interface utilisateur à mettre en place.

clip_image020

Passons justement aux saisies demandées par l'utilisateur. Pour notre requête, nous avons juste besoin d'un compte ordinateur que nous allons proposer parmi une liste d'objets issus de la CMDB.

clip_image022

Là je vais perdre du monde (Doumé, …). Qu'est-ce que c'est que la classe Cloud Services Extended Virtual machine (Advanced)? OK, cela aurait été plus simple de choisir la classe "Windows computers" ou "Windows Computers (Advanced)" qui référence les objets ordinateurs du domaine importés dans la CMDB. Oui mais je voulais ne filtrer que les objets déployés avec le Cloud Services Process Pack. En plus, je voulais pouvoir identifier le propriétaire de ces machines virtuelles.

clip_image024

Pour mon filtre, j'ai retenu de n'afficher que les systèmes qui :

  • Ont été installé à l'aide du Cloud Services process Pack (donc provisionnés via une requête et associé à un contrat lui-même lié à un tenant pour pouvoir facturer)
  • Sont référencés comme actifs (donc non archivés dans la library de SCVMM)
  • Et dont l'utilisateur propriétaire correspond à celui qui exécute la requête dans le portail

C'est là qu'on découvre la magie du token. Merci à l'équipe produit SCSM pour ce billet qui a éclairé beaucoup de choses.

clip_image026

Le filtre est en place, ne reste plus qu'à définir les informations qui seront affichées à l'utilisateur dans le portail SCSM concernant cette classe d'objets, le nom de cet objet sera amplement suffisant.

clip_image028

On comprend l'intérêt des deux premières options, par contre, c'est un peu plus complexe pour les deux autres. C'est un peu plus subtil. Attention, c'est uniquement si vous voulez comprendre tous les mécanismes. Pour faire plus court, voilà les parties intéressantes:

  • Add user-selected objects to template object as related items: If this field is checked, the portal will create System.WorkItemRelatesToConfigItem or System.WorkItemRelatesToWorkItem relationship instances to link each of the objects selected by the user to the target instance specified in the drop-down immediately beneath the check box. The appropriate relationship is selected based on the type of object being displayed in the Query Results control. The instances available in the drop-down include the target template instance selected for the Request Offering and any of its embedded activities.
  • Add user-selected objects to template object as affected configuration items: This field is enabled only if the objects being displayed in the Query Results control inherit from Configuration Item (System.ConfigItem). If this field is checked, the portal will create System.WorkItemAboutConfigItem relationship instances to link each of the objects selected by the user to the target instance selected in the drop-down. The instances available in the drop-down include the target instance and any of its embedded activities.

clip_image030

Félicitations à ceux qui sont arrivés jusque-là. Je sais parfaitement que vous n'êtes pas si nombreux que cela. Maintenant que vous avez un exemple concret de ce qu'on peut faire avec Service Manager, il se peut que vous en vouliez encore plus, voire même tenter d'étendre à d'autres briques du système d'information. Si c'est le cas, c'est normal, vous commencez à penser industrialisation du SI. Vous vous rapprochez des nuages.

BenoîtS - Simple and Secure by design but business compliant

Un peu de process d'ADMPWD dans ce monde de cloud (4/5)

C'est l'heure des sujets qui piquent mais juste un peu. Mais pourquoi donc ne pas tout faire dans un seul et unique Runbook? C'est une bonne question. Ça m'a pris comme ça. Plus sérieusement, c'est un choix personnel de toujours séparer :

  • Les Runbook d'interfaces avec SCSM
  • Les Runbook au cœur de l'activité
  • Les Runbook "Sub-routines" que j'utilise

De cette manière on évite le Runbook monstrueux impossible à maintenir. Dans le cas présent, nous avons un Runbook d'interface avec SCSM. Il a pour objectif de :

  • Récupérer les informations en provenance de la CMDB
  • Appeler un ou plusieurs Runbook "Sub-Routines"
  • Appeler le Runbook au cœur de l'activité
  • D'appeler un Runbook d'interface avec SCSM permettant de remonter des informations dans la Service Request

Mon Runbook d'interface doit récupérer les paramètres dont a besoin le Runbook que l'on va appeler et retourner un statut suite à l'exécution. Plongeons dans ce Runbook qui finalement n'est pas si compliqué qu'il n'y parait :

clip_image002

Pour ceux qui avaient esquivé la série A la surface d'un service dans System Center Service Manager, petit rappel. D'un point de vue technique, Service Manager va créer un objet "Runbook Automation Activity" qui va référencer les paramètres à passer sous forme de liaisons. Nous allons passer l'identifiant unique de cet objet en paramètre du Runbook ("SC Object Guid" le bien nommé). Ce choix me permettra d'utiliser l'IDP SCSM d'Orchestrator pour illustrer quelques manipulations de base de la CMDB. Donc revenons à notre Runbook d'interface. Il commence par une activité qui référence notre seul et unique paramètre.

clip_image004

Pour les plus curieux, voilà un objet "Runbook Automation Activity" ainsi que l'identifiant unique de l'objet RBA qui est passé en paramètre. Le Fameux "SC Object Guid" que nous allons revoir souvent.

clip_image006

Justement cet identifiant, nous allons l'utiliser immédiatement pour identifier notre paramètre, à savoir la machine virtuelle pour laquelle nous allons demander de révéler le mot de passe Administrateur. On va exploiter le potentiel de la CMDB. Au lieu de simplement coder le nom de la VM "en dur" dans l'objet "Runbook Automation Activity", on exploite les relations entre les objets et c'est plus classe. Dans le cas présent, lors de la création de l'objet "Runbook Automation Activity", une relation a été créée avec le paramètre qui n'est autre qu'un objet de la classe "Virtual Machine".

clip_image008

A noter que je suis parti du principe qu'il n'y avait qu'une seule relation, donc un seul paramètre. Si on autorisait la sélection multiple dans la "Request Offering" de SCSM, il faudrait en tenir compte pour traiter chaque cas. Dans le cas qui nous occupe, j'exploite un attribut de la relation pour déterminer qu'il n'y a qu'un seul objet en sortie de cette activité. Si ce n'est pas le cas, le Runbook sort en erreur.

A ce stade, nous avons la référence d'un objet de la classe "Virtual Machine", allons chercher des informations sur cet objet dans la CMDB avec l'activité "Get Object". <Mode Astuce SCSM ON> Nous faisons référence à un paramètre en relation avec une autre classe. Donc l'identifiant unique que nous cherchons (le "SC Object GUID") est référencé dans l'attribut Related Objet GUID" <Mode Astuce SCSM Off>.

clip_image010

Nous avons tous les paramètres ou presque. Au final, on doit dévoiler le mot de passe administrateur de la machine virtuelle que nous venons d'identifier. Encore faut-il savoir à qui envoyer un mail. Facile me direz-vous, dans la "Service Request", on a nécessairement cette information dans l'attribut "Created by user". C'est vrai, nous y reviendrons. Pour l'instant, nous allons appeler un Runbook qui va se charger pour nous de retrouver cette information à l'aide de l'identifiant de l'objet "Runbook Automation Activity" passé en paramètre.

clip_image012

Si on arrive ici, c'est qu'on a toutes les informations pour appeler le Runbook que nous avons développé dans le billet précédent. En retour, le Runbook nous retournera une variable indiquant le bon déroulement de l'exécution (OK, NOK).

clip_image014

Cette variable est importante car à ce stade de notre Runbook nous devons prendre une décision. Si le service a été correctement rendu, alors nous pouvons poursuivre dans une branche (OK). Si ce n'est pas le cas, c'est l'autre branche (NOK). Dans les deux cas, on appelle un Runbook qui va se charger de remonter un statut dans la "Service Request" avant de terminer le Runbook d'interface avec SCSM.

clip_image016

Maintenant que les grandes lignes sont tracées, penchons-nous sur les petits détails pour comprendre deux tours de magie utilisés. Commençons par comprendre comment on retrouve l'utilisateur initiateur de la "Service Request" dans SCSM. La méthode la plus basique aurait été de passer l'information en paramètre (d’où la V1 de la "Request Offering"). Or, cette information est présente dans la CMDB, encore faut-il faire son chemin pour y accéder. J'ai volontairement créé un Runbook dédié pour cela (Runbook "Sub-routine"). Ici encore, c'est une histoire de relation mais avec un objet de la classe "Service Request", lequel a lui-même une relation avec un objet de la classe "User" que nous allons identifier pour enfin en extraire son adresse de messagerie.

clip_image018

Je ne détaille plus le pourquoi mais nous repartons de notre identifiant unique de l'objet "Runbook Automation Activity", c'est notre point d'entrée dans la CMDB.

clip_image020

Cette fois, la relation concerne un objet de la classe "Service Request". Sauf que sur ma maquette qui a déjà beaucoup vécu, j'ai intégré quelques personnalisations de CMDB. J'utilise donc mon extension de la classe "Service Request" que j'ai nommé "My Service Request".

clip_image022

On remarquera que j'ai volontairement fait l'impasse sur la gestion d'erreur. Il y a forcément un objet de la classe "My Service Request" que nous allons identifier à l'aide de son identifiant "SC Object Guid" référencé dans l'attribut" Related Object Guid". Ça commence à rentrer maintenant?

clip_image024

Etage "Service Request", direction "Created user". Ici encore, c'est une relation avec un objet de la classe "Active Directory User". Jusqu'ici, rien de bien compliqué.

clip_image026

C'est en sortie de cette activité que cela se complique (Ce n’est pas la faute à Powershell). En retour, nous n'avons pas un objet en relation mais deux. On s'en rend compte lors qu'on regarde le détail de l'exécution de l'activité. Problème, comment identifier l'un ou l'autre.

clip_image028

C'est une bonne piste, maintenant, faut faire le tri. Pour cela, il a été nécessaire d'utiliser le débogueur pour clairement identifier les différents "Related Object Guid" en question. Avec un peu de persévérance, on finit par comprendre la différence :

clip_image030

Nous avons deux relations :

  • La première pour l'utilisateur qui a créé la requête
  • La seconde pour l'utilisateur à qui on a affecté la requête (notion d'analyste dans SCSM)

Ce qui nous intéresse, c'est le premier. Pour filtrer uniquement celui-ci, nous allons jouer sur les propriétés "Include" et Exclude" de la relation. Même les liaisons entre les activités ont des propriétés que l'on peut configurer (sic). J'ai donc indiqué que nous ne retenons les objets que si l'activité "Get-Relation" s'est déroulée avec succès ou que celle-ci nous désigne bien un attribut dont la valeur est "Created By user".

clip_image032

Au contraire, je veux exclure, tout objet pour lequel la valeur de ce même attribut n'est pas celle attendue.

clip_image034

La gestion des propriétés "include" et "exclude" est importante dans Orchestrator car c'est grâce à elles que l'on va introduire la gestion d'erreur au sein de nos Runbooks. Il faut donc s'assurer de bien les configurer. Dès lors qu'on est assuré d'avoir la référence au bon objet, allons rechercher ses caractéristiques avec une activité "Get-Object".

clip_image036

Nous avons maintenant toutes les informations pour retourner l'adresse mail de l'utilisateur créateur de la "Service Request" en résultat de Runbook. On notera que si cette information est dans la CMDB, c'est que le connecteur Active Directory en a importé l'objet et la majeure partie de ses propriétés.

Second tour de magie, utilisé : La mise à jour de la "Service Request" en fonction du résultat du Runbook. C'est ce qui permettra d'informer l'utilisateur que sa requête a été traitée avec succès. Le cas échéant d'indiquer l'erreur rencontrée. Vous reprendrez bien un petit Runbook pour la route? Sans Powershell ajouté!

clip_image038

Notre Runbook attend deux paramètres en entrée, à savoir l'identifiant du Runbook Automation Activity qui sera notre point de départ pour remonter vers la "Service Request" ainsi que l'information que nous allons inscrire comme résultat de la "Service Request".

clip_image040

On ne change pas une méthode qui gagne en recherchant l'objet "Service Request" en relation avec notre objet "Runbook Automation Activity".

clip_image042

Je sais qu'il y a nécessairement qu'une seule relation, donc pas la peine de tester, allons à l'essentiel en mettant à jour objet "Service Request" dans la CMDB. La mécanique est maintenant rodée, on va juste passer un peu de temps sur les attributs que l'on met à jour.

clip_image044

Pour le second, rien de bien sorcier, c'est du texte qui est issu d'un retour du Runbook qui a révélé le mot de passe Administrateur de notre serveur. Pour le premier par contre, c'est un peu plus subtile. Dans la "Service Request", cet attribut n'accepte que des valeurs définies dans une liste SCSM (encore un objet dans la CMDB) nommée "Service Request Implementation results".

clip_image046

C'est ce contenu qu'Orchestrator nous propose. J'ai donc deux Runbooks. Le premier pour indiquer que tout s'est déroulé avec succès et le second pour indiquer qu'une erreur est survenu lors de l'exécution. Au passage deux piqures de rappel sur le sujet pour éviter les déconvenues suite à une installation malencontreuse d'Orchestrator sur un système autre qu’US :

Vous lisez encore? Bien, reste plus maintenant qu'à mettre tout cela en musique dans Service Manager. Courage, plus qu'un seul billet à supporter.

BenoitS - Simple and Secure by Design but business compliant

Un peu de process d'ADMPWD dans ce monde de cloud (1/5)

ADMPWD, répond à une problématique bien connue. Maintenant qu'on a l'essentiel, passons à l'étape suivante : construire des processus autour. Historiquement, on ne voulait jamais donner le compte administrateur local de nos stations de travail/serveur car, il risquait d'être identique sur un grand nombre de serveurs. Avec ADMPWD, on a résolu ce problème. Voyons comment faire en sorte de pouvoir communiquer le mot de passe Administrateur local d'un système en s'assurant que cette information ne soit valable pour une durée limitée dans le temps (vous avez dit magie?).

Dans l'idée, c'est de faire appel à ADMPWD pour lui imposer de changer de mot de passe plus rapidement que ce qu'il a été prévu. De cette manière, même si on communique le mot de passe que nous avons extrait de l'annuaire Active Directory, sa durée de vie sera limitée. Dans le cadre de ce billet, j'ai volontairement retenu une durée de 24 heures. Le composant ADMPWD installé sur mes serveurs réévalue le besoin de changer le mot de passe du compte administrateur local selon les conditions suivantes :

  • Cycliquement toutes les 90/120 minutes
  • manuellement en exécutant Invoke-GPUPDATE / GPUPDATE.EXE
  • Au démarrage du système d'exploitation

Donc en configurant une date d'expiration à 24 heures , nous sommes presque assurés qu'au bout de 24heures + 120 minutes le processus de rafraichissement des stratégie de groupe aura eu lieu et ADMPWD réalisé le changement de mot de passe. Et comme la sécurité n'est rien sans de bons processus pour l'encadrer, je n’ai pas résisté à la tentation de développer une “Request Offering” SCSM pour : 

  • Révéler le mot de passe administrateur local d'un serveur
  • En s'assurant que ce mot de passe ne soit utilisable que pendant une période de 24 heures
  • Que le mot de passe soit communiqué au demandeur par mail

Qui dit SCSM, dit obligatoirement Orchestrator et Powershell, le tiercé gagnant. Les bases sont posées voyons comment le mettre en musique. Pour simplifier l'approche et la lecture, c'est non pas un billet mais plusieurs qui seront nécessaires. Commençons par les fondations avec le Runbook chargé des opérations techniques :

Pour ceux qui ont suivi la série "A la surface d'un service dans System Center Service Manager", on est dans la même approche, peut-être un peu plus simple, mais ça c'est by designTire la langue. En plus, c’est toujours Secure”".

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

Un peu de process d'ADMPWD dans ce monde de cloud (3/5)

On a plongé tête baissée dans Orchestrator. Pourtant, avant de de se perdre dans les méandres d’Orchestrator et SCSM, ce serait bien de comprendre à quoi cela va ressembler à la fin. Au passage, cela permettra d'introduire quelques sujets de fonds. Donc billet un peu plus léger pour cette fois.

Pour cette série de billets, j'ai fait bien plus simple que pour la série "A la surface d'un service dans System Center Service Manager", pas de "Service Offering", donc toutes les Request Offering sont directement accessibles depuis la vue "List view" dans le portail SCSM (j'ai dit léger non?). J'ai nommé ma Request Offering "Disclose local Administrator Password (V2)". Le développement de mon service s'est fait par itération successive. On n'arrive que très rarement au résultat escompté du premier coup.

clip_image002

C'est une étape obligatoire dans le portail SCSM. L'idée générale est de pouvoir communiquer autour de la Request Offering avec les différents éléments qui peuvent s'y rapporter (articles de la bases de connaissance associés, autres “Request Offering” proposés dans le même Service Offering, …). Pour faire simple, la WebPart est tel que, on n'y changera rien.

clip_image004

Nous arrivons au cœur de la Request Offering. Pour quel serveur va-t-on demander de dévoiler le mot de passe administrateur local? On verra plus tard que cette liste de serveurs n'est pas construite par hasard. Ne sont affichés que les serveurs que j'ai commandé dans mon Cloud Services Process pack. Dans la construction de ma "Request Offering", j'ai retenu qu'on ne puisse sélectionner qu'un seul serveur. D'un point de vue technique il est bien entendu possible d'autoriser une sélection multiple, c'est juste coté Orchestrator que cela va se compliquer (billet simple).

clip_image006

Par contre, on ne voit pas encore comment cette liste a été construite. Toutes ces machines virtuelles sont-elles les miennes? Allons voir les propriétés de l'objet sélectionné. Ce que nous allons voir est la vue consolidées des informations contenues dans la CMDB de Service Manager. Déjà premier constat, l'objet présente des informations en provenance de plusieurs classes d'objets, dont "VirtualMachines". L'objet sélectionné est bien un objet de la classe "virtualmachine" mais aussi un objet de la classe "Cloud Services Virtual Machine". Cette classe d'objets a été introduite par le Cloud Services Process Pack pour assurer la mise à disposition et gestion de machines virtuelles. L'intérêt est de pouvoir identifier le propriétaire de la machine virtuelle.

clip_image008

Ce qu'on peut aussi remarquer ici, ce sont les éléments de configuration issus de la CMDB qui sont en relation avec mon objet sélectionné.

clip_image010

Le premier désigne le contrat de souscription de ressources auquel est associé la machine virtuelle (Il faut bien être capable de tracer/facturer l'utilisation des ressources). C'est un élément apporté par le Cloud Services Process Pack.

clip_image012

Mais aussi le propriétaire associé à la ressource. C'est cette information que nous utiliserons lors de l'intégration avec SCSM.

clip_image014

En passant par la relation, je retrouve le propriétaire associé à l'objet. Pour finir, une étape obligatoire du portail SCSM pour rappeler les choix de l'utilisateur avant de commencer le traitement de la "Request Offering".

clip_image016

Maintenant, plus moyen de revenir en arrière, le traitement a commencé. Dans SCSM les choses sérieuses commencent. La "Request Offering" que nous avons appelé fait référence à une "Service Request" qui elle-même référence une ou plusieurs activités à traiter. Dans notre cas, il n'y en a qu'une seule et c'est même une activité de type "Runbook Automation Activity".

clip_image018

Le portail SCSM permet de suivre l'avancement de notre "Request Offering". Dans l'illustration ci-dessous, notre requête est indiquée comme étant en cours de traitement, et qu'elle ne fait appel qu'à une seule activité, plus précisément une "Runbook Automation Activity". Cette dernière indique un état "In Progress". Ce sont donc deux objets qui ont un statut bien distinct (Une "Service Request" peut faire appel à plusieurs "Activity").

clip_image020

Quelques temps plus tard, le "Runbook Automation Activity" indique un état "Completed", tout comme la "Request Offering". C'est un sujet que nous allons revoir plus tard.

clip_image022

Passons de l'autre côté pour voir ce que nous ne voyons pas depuis le portail. Lorsqu'on consulte le détail de la "Service Request" générée, on peut constater la présence de notes additionnelles indiquant la date de fin de validité du mot de passe que nous venons de relever. On verra dans le billet suivant que c'est le travail d'un de mes Runbook Orchestrator de remonter cette information au niveau de la "Service Request" ainsi que le bon déroulement ou non des activités réalisées.

clip_image024

Ma maquette étant quelque peu limitées en terme de capacités (32Go de mémoire, on fait plus rien avec ça mon bon monsieur), pas possible de présenter le mail reçu dans un beau client de messagerie. On se contentera de sa version brute de fonderie dans la file d'attente SMTP. Pour faire cela bien, il aurait été nécessaire de mettre en place le connecteur Exchange de SCSM 2012.

clip_image026

Pour les sceptiques, il reste possible d'aller voir ce qui se passe sous la moquette et plus précisément dans l'annuaire Active Directory. Avec le CommandLet Get-ADObject du module Active Directory on est capable de récupérer toutes les informations dont les deux attributs qui nous intéressent :

  • Ms-Mcs-AdmPwd
  • Ms-Mcs-AdmPwdExpirationTime

clip_image028

C'est ce dernier attribut qui va nous intéresser. Comme toutes les dates, elles sont exprimées au format UTC. Il aurait été possible de réaliser cette conversion directement, sans l'étape intermédiaire mais cela rend le code un peu plus complexe (Powershell oui mais simple, j'avais promis).

Jusque-là je ne dois avoir perdu personne. Pour le prochain billet, ça va se corser puisqu'on va aborder le sujet de l'intégration SCSM avec Orchestrator (sic). Courage, le pire est à venir.

BenoîtS - Simple and Secure by Design but Business compliant.

More Posts Next page »