System Center Update Rollup 9

C’est tombé la même semaine que la Technical Preview 1 de Windows Azure Stack mais Windows Azure Pack a lui aussi son actualité avec la mise à disposition de l’Update Rollup 9. Ca couvre pas tous les composants mais ça va occuper dans la mise à niveau du Fabric Management :

  • Update Rollup 9 for Windows Azure Pack (KB3129786)
  • Update Rollup 9 for Windows Azure Pack Web Sites version 2 (KB3129789)
  • Update Rollup 9 pour SCOM 2012 R2 (KB3129774)
  • Update Rollup 9 pour Service Manager 2012 R2 (KB3129780)
  • Update pour System Center 2012 R2 Service Manager Self-Service Portal (KB3134286)
  • Update Rollup 9 pour System Center 2012 R2 Data Protection Manager (KB3112306)
  • Update Rollup 9 pour System Center 2012 R2 Orchestrator – Service Provider Foundation is now available (KB3133705)

La principale nouveauté pour Windows Azure Pack permet maintenant de changer l’administrateur de la souscription d’un tenant. Une subtilité, le Rollup 9 pour SCSM 2012 R2 a été retiré temporairement après sa publication. Il devrait revenir bientôt.

­

Prochaine étape, le bestiau ; Windows Azure Stack. 

 

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

Architecture WAP–Design infrastructure Windows Azure Pack

Let the fun begin! Windows Azure Pack est de loin la partie la plus intéressante. Avouez, c’est uniquement la partie qui vous intéresse. J’ai déjà développé le sujet ici et la, mais sans vraiment rentrer dans le détail des explications. Pour rappel, Windows Azure Pack, c’est un ensemble de Web Services que l’on peut organiser en deux catégories, selon qu’ils ciblent les locataires ou les administrateurs de la plateforme. Le tableau-ci-dessous résume les rôles et les populations ciblées :

Rôle

Cible

Windows Azure Pack PowerShell API Administrateurs / Tenant
Windows Azure Pack Tenant API Administrateurs
Windows Azure Pack Admin Portal Administrateurs
Windows Azure Pack Tenant Portal Tenant
Windows Azure Pack Tenant Authentication Site Tenant
Windows Azure Pack Tenant Public API Tenant
Windows Azure Pack Admin API Administrateurs
Windows Azure Pack Admin Authentication Site Administrateurs
Windows Azure Pack Best Practice Analyzer Administrateurs

 

Tous ces Web Services peuvent cohabiter sur un même serveur ou être répartis sur plusieurs. Séparer en fonction des cibles est une bonne approche du point de vue de la sécurité. Un premier niveau de découpage logique donc le suivant comme illustré ci-dessous :

  • Un serveur pour héberger les rôles destinés aux Administrateurs (WAPPRIV)
  • Un serveur pour héberger les rôles destinés aux locataires (WAPPUB)

clip_image001

Le premier intérêt de cette séparation est de pouvoir placer chaque serveur dans une zone réseau distincte. Ca plaira aux barons de la sécurité. Pour eux, la Co-localisation des rôles sur un même serveur est problématique d’un point de vue sécurité. Exposer le portail d’administration ou l’API associée directement sur Internet est plutôt risqué. Si une faille impacte le serveur, il serait possible pour un utilisateur externe d’accéder aux rôles privilégiés de Windows Azure Pack. Après, il faut relativiser. Nos serveurs ne seront pas exposés directement sur Internet. Dans notre contexte Cloud privé, nous avons besoin que ces services soient hautement disponible et dans les deux datacenters. Pour le déploiement, que nous en ayons deux ou dix, c’est la même chose, tout ce que nous avons besoin, c’est d’un moyen d’industrialiser le déploiement : Powershell Deployment Toolkit.

clip_image002

 

Si on voulait pousser le vice jusqu’au bout en isoler les fonctions portail et authentification des autres. Techniquement, c’est possible mais cela complexifie l’architecture pour pas grand-chose. D’un point de vue sécurité, nos rôles destinés aux locataires ne seront pas exposés en directe mais via des mécanismes de reverse proxy (vous avez dit Web Application proxy?), l’idée étant de pré-authentifier les locataires. Justement, parlons authentification.

Authentification

Maintenant que l’infrastructure Windows Azure Pack est en place, on va passer un peu de temps sur la partie authentification. j’ai déjà évoqué ce sujet ici et . Au final, le choix est assez simple. Pour les administrateurs, le choix d’ADFS s’impose de lui-même. Cela permet de centraliser l’authentification et l’autorisation de nos administrateurs en un point unique, au sein de la zone réseau privilégiée, voire même de les pré-authentifier lorsqu’ils arrivent depuis une autre zone réseau. Dans le contexte de notre cloud Privé, cela implique qu’on disposera d’une ferme ADFS dédié à cet usage, avec haute disponibilité. Pour renforcer la sécurité, l’utilisation de Web Application Proxy est recommandé, rien que pour sa fonction External Extranet Lockout. Le bonus, c’est la possibilité d’imposer l’authentification forte à ce niveau avec Azure Multi-Factor Authentication.

clip_image003

 

Pour les locataires ADFS s’impose aussi mais pour une autre raison. Pour Microsoft, le fournisseur d’authentification par défaut ne doit pas être utilisé en environnement de production et recommande l’utilisation d’ADFS. Lorsque l’utilisateur est capable de se présenter avec sa propre identité, cela ne pose pas de problème. Ce sera par exemple le cas de certains de nos futurs clients pour lesquels on sera capable de mettre en place un Federation Trust comme documenté dans cette série de billets : Authentification des locataires de Windows Azure Pack avec ADFS.

clip_image004

 

Avec cette architecture, le client vient avec sa propre identité, charge à lui de s’assurer de sa disponibilité et sa sécurité. Par contre, cela nous coupe d’un certain nombre de nos clients qui n’ont pas encore d’infrastructure de fédération d’annuaire. Il faut bien être en mesure de leur proposer le service, sinon, on va se couper du business des TPE/PME. La question, c’est doit-on héberger ce service (et donc en être responsable) ou peut-on l’externaliser (Chez Microsoft Azure par exemple)? Le premier choix, cela signifie qu’on va :

  • Lui fournir les moyens de gérer son identité (réinitialisation mot de passe, …)
  • Garantir la sécurité de l’identité de nos utilisateurs

Le premier choix implique de mettre en place une infrastructure ADFS dédiée, sécurisée et hautement disponible. Techniquement, c’est donc une évolution de l’architecture ci-dessus dans laquelle on va ajouter une nouvelle infrastructure ADFS pour proposer notre service d’identité à nos clients. C’est facile mais ça nous rend responsable du bon fonctionnement du service et sa sécurité. Le second choix est lui plus sexy. Depuis peu, il est possible de consommer un tenant Windows Azure Active Directory sous forme ADFS. OK, la fonctionnalité est disponible uniquement pour l’édition Premium mais :

  • Microsoft nous fournit un service d’authentification sécurisé et hautement disponible
  • Microsoft nous fournit à nos futurs locataire le moyen de gérer / sécuriser leur identité

Du point de vue architecture, cela ne change strictement rien, ils sont toujours authentifiés et autorisés à accéder à leurs ressources.

 

Resources Providers

Windows Azure Pack ne serait rien d’autre qu’un portail sans ses Resources Providers. Pour ceux qui ont oublié, j’avais écrit ce billet : Introduction aux Resources Providers de Windows Azure Pack. Techniquement, ce sont des Web Services exposés de manière normalisée pour Windows Azure Pack. Avant même d’en ajouter d’autres, le billet s’attachait à configurer les premiers :

  • Monitoring
  • MarketPlace
  • Usage Service

Ils sont tous les trois livrés avec Windows Azure Pack et présents sur le serveur WAPPRIV, ou plutôt toutes les instances de nos WAPPRIV. Par contre dans la configuration par défaut, rien n’est prévu pour la haute disponibilité. Avec un peu de PowerShell, on peut aller revoir la configuration de ces Ressources providers avant configuration.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String « ******** » -AsPlainText -Force

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

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

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

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

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

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

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

$Allrp | select name, DisplayName, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}} | Format-Table -AutoSize

clip_image005

 

Dans le billet Introduction aux Resources Providers de Windows Azure Pack, nous commencions par corriger ce point en introduisant une URL générique pour nos premiers Resources Providers. Derrière cette URL générique se cache une adresse IP portée par un boitier HLB qui se charge de rediriger les requêtes entres toutes les instances déclarées. Une fois corrigé, on obtenait le résultat ci-dessous :

clip_image006

 

Ces ressources Providers sont un peu particulier (ils sont « System Resource Provider ») car c’est autour d’eux que les autres Resources providers vont venir d’intégrer. Nos futurs ressources providers vont :

  • Proposer des ressources à nos locataires qui sera exposées via le Resource Provider Marketplace
  • Suivre l’état des ressources mises à disposition qui sera exposé via le Resource Provider Monitoring
  • Suivre la consommation des ressources mises à disposition de nos locataires Resource Provider UsageService

 

On peut maintenant s’attaquer aux autres Resources Providers :

  • MySQLServers
  • SQLServers
  • Automation
  • SystemCenter
  • CloudServices
  • Gallery
  • WebSites

Tous ces Resources Providers sont apportés par les composants additionnels que nous allons installer. Pour certains, leur existence est déjà référencée dans les portails de Windows Azure Pack (pour les plus connus d’entre eux), ne manque que la configuration nécessaire pour les exploiter. Windows Azure Pack impose son modèle avec un ensemble de Web Services :

  • AdminEndPoint (Partie visible du Resource Providers dans le portail des administrateurs)
  • TenantEndPoint (Partie visible du Resource Provider dans le portail des locataires)
  • UsageEndPoint (pour remonter le suivi des usages du Resource Provider pour chaque souscription)
  • NotificationEndPoint (pour notifier dans les portails sur l’avancement des opérations)
  • HealthCheckEndpoint (pour le monitoring du ressource provider)

 

Voilà pour l’essentiel. Maintenant, dans un contexte avec plusieurs Datacenters avec objectif de haute disponibilité, il faudra disposer d’au moins une instance de chaque serveur dans chaque Datacenter avec un mécanisme de répartition de charge réseau (F5/Kemp). Windows Azure Pack nous simplifie grandement la tâche. Ce ne sont que des Web Services pour lesquels on peut disposer d’autant instances que l’on veut. Tout ce qu’on doit faire c’est de placer un équipement d’équilibrage de charge réseau devant. En back-end, notre seule contrainte, c’est de disposer d’une infrastructure SQL Server hautement disponible en Always On, donc opérant en actif/actif. Avec deux Datacenters, cela ressemble déjà à cela :

clip_image007

 

Chaque Resource Provider est un sujet à part entière. C’est simple pour certains, compliqué pour d’autres. Vu que le plus intéressant pour beaucoup d’entre vous est le IAAS, on va commencer par lui dans le prochain billet.

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

Architecture WAP–Design SCVMM

On parle enfin virtualisation, SCVMM et Hyper-V. Si on connait un peu son SCVMM, on connait ses limites de sizing :

  • Nombre de hosts Hyper-V : 1000
  • Nombre de machines virtuelles : 25000
  • Nombre de User Roles : 1000

Source : Overview of System Center 2012 – Virtual Machine Manager

 

Après, il y aura les limites d’Hyper-V (2012 R2) à prendre en considération :

  • Nombre maximum de nœuds dans un cluster : 64
  • Nombre de machines virtuelles maximum dans un cluster : 8000

Source : Hyper-V scalability in Windows Server 2012 and Windows Server 2012 R2

 

Première conclusion, la véritable limitation viendra de SCVMM mais pas ou on pourrait l’attendre, ce sera celle du nombre de user-roles dans SCVMM, donc le nombre maximum de locataires que l’on pourra avoir sur une seule infrastructure SCVMM. Est-ce un problème de n’avoir que mille locataires? Le Business répondra invariablement oui. Il faut pouvoir outre passer cette limite technique ? Les grands fournisseurs de services Cloud se sont déjà heurtés à ce type de problème. Si leurs infrastructures n’étaient pas assez scalable, on le saurait depuis longtemps. Leur astuce c’est que l’infrastructure présentée au client n’est qu’une partie de l’infrastructure globale. Derrière Azure, il y a certes des services globalisés tel que le portail mais après, les services sont localisés et même découpés en instances de plus petite tailles, plus faciles à manager. A l’échelle de Windows Azure Pack, on peut faire la même chose avec SCVMM. Individuellement chacun de nos locataires à peu de chances de nous faire atteindre les limites d’une seule instance de SCVMM. Rien n’empêche alors d’avoir plusieurs instances de SCVMM présentées à Windows Azure Pack via le Service provider Foundation. De son point de vue, on publie effectivement plusieurs Clouds SCVMM. Pour nos locataires, ce ne sont que des offres d’abonnement différents. Pour commencer, une seule instance suffira.

Haute disponibilité avec SCVMM

Le nombre d’instances étant réglé, passons à sa disponibilité. Avec SCVMM, on est limité car on ne peut avoir qu’une seule instance du rôle que l’on peut seulement configurer pour opérer au sein d’un cluster. Si le cluster ne fait pas partie de vos choix, l’utilisation d’Hyper-V Replica est vivement recommandée. Personnellement, j’essaie de limiter le nombre d’instances de SCVMM. Même si Windows Azure Pack permet de référencer autant de Service provider Foundation pour lesquelles on peut référencer jusqu’à cinq instances SCVMM distinctes, il n’en reste pas moins que cela reste des instances distinctes du point de vue Gallery et VM Roles. Donc nos choix se limitent à :

  1. Rester dans les limites de support de SCVMM pour n’avoir qu’une seule instance indépendamment du nombre de Datacenters
  2. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en conséquence
  3. Placer une instance SCVMM par Datacenter et raccorder les hôtes de virtualisation en répartissant entre les Management group

 

Le choix numéro n°1 est le choix le plus rationnel pour commencer. Du point de vue architecture rien n’empêche d’ajouter d’autres instances en cours de route pour faire face aux besoins / contraintes. La seule limitation concerne la fonctionnalité Gallery de Windows Azure Pack qui est liée à la librairie SCVMM. Le contenu de la Gallery présenté à l’utilisateur référence toutes les VM Roles disponibles, indépendamment des SCVMM. Pour éviter de présenter plusieurs fois la même ressource à nos futurs locataires, il faut reconfigurer les VM Roles avant importation pour les rendre unique. Dans le contexte que nous allons développer, nous resterons sur le scénario n°1. Ci-dessous l’architecture pressentie pour SCVMM.

clip_image001

 

On reste donc dans le simple avec pourtant une subtilité. J’ai bien de l’Hyper-V Replica mais entre deux clusters qui sont dédiés au Fabric Management. On reviendra sur ce point plus tard. Pour finir avec le design d’infrastructure, un petit rappel : Par Défaut, SCVMM est un produit qui vous veut du bien. Pensez donc à sauvegarder les clés dans l’Active Directory ?

clip_image002

 

Haute disponibilité des librairies

Avec SCVMM, il ne faut pas oublier de penser à la librairie SCVMM, ou plutôt aux librairies SCVMM. C’est un peu plus qu’un agent installé sur un serveur qui joue le rôle de serveurs de fichiers. Il en faut au moins une par Datacenter, histoire d’éviter de déployer des VDHX via le WAN. Pour répliquer le contenu, DFS-R peut paraitre le candidat idéal, mais attention à la taille du Staging Folder qui va nécessiter beaucoup d’espace disque pour préparer la réplication. Rien qu’un VHDX pour un système d’exploitation de type Windows Server 2012 R2, il faudra compter entre 15 et 17Go (en disque dynamique). Selon les guidelines de sizing DFS-R, chaque partenaire de réplication doit être en mesure de traiter la réplication de 16 fichiers entrants et 16 fichier sortants. La volumétrie disque nécessaire pour le Staging Folder peut donc être évaluée à l’aide de la taille cumulée des 32 plus gros fichiers à répliquer. A ce niveau, les fonctionnalités de réplication de stockage sont certainement plus économes. Et encore, nous ne parlons que d’une seule instance SCVMM. Une bonne raison pour continuer à se limiter à une seule instance SCVMM.

Du point de vue architecture, on va quand même utiliser DFS-R en mettant en place un groupe de réplication comprenant deux nœuds répartis entre nos deux datacenters. Après, il faut comprendre une chose, nous nous sommes assurés de la disponibilité du contenu avec DFS-R, rien de plus. DFS-N ne peut rien faire pour nous puis que c’est une communication de type BITS entre la librairie SCVMM et l’hôte Hyper-V, il n’y a aucun accès en SMB avec un chemin UNC. Donc en cas d’indisponibilité d’une librairie, tous les objets y faisant référence sont inutilisables depuis SCVMM. Travailler avec plusieurs librairies implique de travailler avec les objets équivalents. C’est un processus qui permet de déclarer manuellement des associations entre plusieurs objets que l’on va déclarer comme équivalent. Là où ça coince, c’est que c’est une fonctionnalité qui ne semble accessible que depuis la console d’administration de SCVMM, fonctionnalité pour laquelle on a pas de commande PowerShell. A ma connaissance, il n’y a qu’un seul cas ou les objets sont automatiquement déclarés comme équivalents, s’ils sont tous tagués avec les mêmes familles, versions et namespaces.

clip_image003

 

Design des Clouds SCVMM

L’infrastructure posé, rentrons dans SCVMM. Sous la notion de cloud, on va pouvoir regrouper plusieurs types de ressources (Host Groups, Logical Networks, accessoirement des Load Balancers et des VIP, du stockage, des librairies SCVMM, des politiques de capacités, …). Commençons avec les Host groups. La première chose à faire est d’isoler les ressources utilisées par le Fabric Management de celles qui seront utilisées par nos futurs locataires. Dédier un Cloud SCVMM pour le Fabric Management n’est pas sans conséquences. Certes, plusieurs Clouds SCVMM peuvent partager des ressources comme les librairies mais pour d’autres, cela pose des problèmes pour les hosts groups

Dédier un host group pour la Fabric Management est obligatoire. C’est un peu un sanctuaire. Sans lui, plus de Windows Azure Pack, donc aucun moyen pour nos locataires de consommer les ressources mises à leur disposition. Il faudra donc associer un Cluster à ce Host-group. Le problème, c’est que cette association est exclusive. Le ou les clusters Hyper-V deviendront donc réservé uniquement pour le Fabric Management. Pour ces clusters, pas la peine d’essayer de le sizer au plus court. Son indisponibilité serait bloquante pour les exploitants mais aussi pour les locataires. Pas la peine de mégoter sur le nœud de cluster pour la réserve. En plus, il faudra bien les patcher un jour ces clusters. S’il n’y a pas les ressources nécessaires pour basculer les workloads du Fabric Management, il faudra donc interrompre le service. C’est moche, surtout quand on vend qu’un cloud est censé être plus disponible que les bonnes vieilles implémentations « On-Premises ».

Plusieurs Cloud SCVMM peuvent partager les mêmes librairies sans problème. Techniquement, c’est vrai. Imaginons que vous voulions proposer à nos locataires la possibilité de faire des checkspoints de leurs machines virtuelles, ou ce contenu serait-il stocké ? Notre locataire est en droit d’attendre que les exploitants de la plateforme Cloud qu’il a retenu ne puissent pas accéder à ce contenu. Pour répondre à cette problématique, il est donc obligatoire de disposer de librairies SCVMM qui seront dédiées au Cloud SCVMM réservé à nos locataires. Si on sépare les librairies en fonction des usages (service et locataires), il faudra donc plusieurs groupes de réplication DFS-R et dédier des serveurs de fichiers pour chaque usage.

Enfin, introduire plusieurs Clouds SCVMM pour nos locataires n’est pas dénué de sens. D’une part cela contribue à proposer plusieurs niveaux de service à nos locataires (Gold, Bronze, Silver, …). Le plus intéressant ici n’est pas la technique mais bien les services proposés à nos locataires. En montant en gamme, on peut proposer de nouveaux services à nos futurs locataires :

  • Le niveau Silver pourrait ne contenir que des host groups référençant des Hyper-V, donc sans haute disponibilité
  • Le niveau Bronze introduirait la haute disponibilité en utilisant des hosts groups contenant des clusters Hyper-V
  • Le niveau Gold lui proposerait carrément la virtualisation réseau avec la NVGRE Gateway ?

 

L’approche est aussi applicable au stockage en proposant une gamme de stockage en fonction :

  • Le niveau Silver ne proposerait que du stockage local de type DAS
  • Le niveau Bronze proposerait du stockage basé sur du Scale-Out File Server
  • Enfin le niveau Gold proposerait lui du stockage géo-répliqué entre les datacenters (par exemple basé sur Storage Replica, inclus dans l’édition Datacenter de Windows Server 2016)

 

Cette approche a cependant une limitation dans Windows Azure Pack. Lorsqu’un utilisateur souscrit à un abonnement IaaS dans son portail, il lui est associé le Cloud SCVMM dans lequel il pourra consommer son service. Si demain cet utilisateur veut bénéficier du niveau de service supérieur, nous devrons migrer la souscription de l’utilisateur vers l’abonnement de niveau supérieur. Le problème, c’est que cela ne migre pas les machines virtuelles entre les clusters.

Synthétisons un peu tout cela dans un diagramme. Donc deux Cloud au sens SCVMM pour distinguer les usages et une organisation des hosts-groups en fonction des Datacenters. Pour commencer, je considère que des clusters Cross-datacenters ne sont pas à l’ordre du jour pour commencer. Il y a beaucoup d’autres choses à monter avant cela. Le modèle a l’avantage d’être simple, avec pour seule réelle limite la scalabilité de SCVMM. Du point de vue de nos locataires, j’ai retenu un seul Cloud, donc un seul niveau de service proposé.

clip_image004

 

Maintenant qu’on l’outil de management en place, peuplons-le avec des clusters Hyper-V.

 

Design des clusters

Coté cluster, on sait déjà qu’il nous faudra au moins deux clusters Hyper-V pour le Fabric Management et d’autres pour les locataires. Il reste dépendant quelques questions en suspens :

  • Combien de clusters pour le Fabric Management ?
  • Doit-on avoir des clusters inter-sites ?
  • Doit-on privilégier les grands clusters ?

 

Combien de clusters pour le Fabric Management ? Facile, tout le monde dans le même cluster ? OK mais s’il tombe, on perd tout. En plus, on est dépendant du stockage. Si on veut pouvoir survivre à la perte d’un Datacenter, c’est du stockage Geo-répliqué qu’il nous faut alors. Difficile de vendre au Business que nous allons claquer un maximum d’argent pour un service qui au final n’est pas consommé par le client final. Il en est dépendant certes mais s’il ne fonctionne pas, le fournisseur reste coupable. C’est entre autre pour cette raison que le diagramme au-dessus référence deux host-group pour le Cloud du Fabric Management. Dans cette configuration, l’impact de la perte du Datacenter n’a aucun impact sur ces clusters. Ce qui manque, c’est d’assurer la haute disponibilité des ressources hébergées. Hyper-V Replica est tout désigné pour cela. En plus, cela simplifiera grandement les opérations de patching.

Doit-on avoir des clusters inter-sites ? Le cluster Hyper-v Inter-site, donc inter-Datacenter implique de disposer d’un stockage partagé entre les datacenters. Technologiquement, c’est possible. Par contre, cela implique d’abandonner l’approche Scale-Out FileServer de Microsoft (génération Windows Server 2012 R2) pour revenir aux baies de disques avec réplication de LUN. D’un point de vue service proposés aux futurs locataires, cela avait un sens pour proposer un mécanisme de failover en cas d’indisponibilité de Datacenter. Le problème, c’est que depuis Hyper-V 2012, on dispose de la fonctionnalité Hyper-V Replica qui permet de maintenir une copie de machine virtuelle sur un autre hôte hyper-V, voire même sur un autre cluster. Au final, on a donc plus besoin de clusters inter-sites.

Doit-on privilégier les grands clusters ? Comme vu précédemment, un cluster peut être composé de 64 nœuds et héberger jusqu’à 8000 machines virtuelles. Mais doit-on aller jusque-là ? Too big to fail ? Personnellement, je vois le cluster comme un domaine de panne. L’indisponibilité d’un nœud va nécessairement avoir des répercussions sur les autres, surtout si on se trouve en situation de surconsommation des ressources (plus de Cluster Reserve). Plus grand sera le cluster, plus important sera l’effet domino en cas de défaillance d’un ou plusieurs nœuds. Autre problème des grands clusters, la maintenance. Avec des grands clusters, le niveau de parallélisation des opérations de maintenance est moins important qu’avec des clusters de taille moins importantes. Cela a donc un impact sur la fenêtre de maintenance dont on disposera pour faire le maintien en condition opérationnel de la plateforme. Pour cette raison, je préfère limiter le nombre de nœuds au sein d’un cluster. Une limite à Seize nœuds me semble un compromis acceptable.

Maintenant, pour le design même des clusters Hyper-V, c’est très dépendant de votre architecture matérielle. D’un point de vue réseau, c’est fortement lié aux capacités d’offloading de vos cartes réseau et des capacités de votre cœur de réseau à accepter du 10Gb ou du 40Gb ou mieux. Du point de vue stockage, Microsoft propose son approche avec le Scale-Out file server mais c’est peut-être du stockage préexistant au sein de votre système d’information que vous voudriez utiliser (SAN). Ou alors êtes-vous prêt à l’hyper-convergence en regroupant compute, storage et network au sein d’une même appliance comme le propose Nutanix ou Windows Server 2016? Bref trop de variables pour proposer quelque chose de générique. Aujourd’hui, il y a une tendance vers l’hyper-convergence. C’est une approche technique intéressante mais elle impliquer de revoir aussi l’organisation. Ce ne sont plus trois équipes qui seront à la manœuvre (stockage, réseau et serveurs) mais bien une seule équipe « Cloud ». Sur ce sujet, quelques lectures intéressantes de collègues MVP qui ont déjà traités ces sujets bien mieux que moi :

 

Prochaine étape SCOM.

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

MS-OTPCE – One-Time Password Certificate Enrollment Protocol

I had many questions these days about DirectAccess OTP authentication mechanism. I already published multiple blog posts on the subject:

All these blog post are useful to understand and troubleshoot DirectAccess OTP scenario but on resource was missing : the Windows protocol definition for [MS-OTPCE]. Now you have all information to clearly understand the authentication process.

 

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

Architecture WAP – Design SQL Server

Alors, celui qui répond SQL Server 2014 en Always-On pour tout le monde, il sort, le bourreau l’attend à droite en sortant. Avant de répondre bêtement, il faut faire le tour du propriétaire, comprendre les applications que l’on va utiliser et comment on peut les rendre hautement disponible. Le tableau-ci-dessous résume tous les besoins en instances SQL Server et les quelques contraintes qu’on a besoin de connaitre.

Produit

Version SQL supportée

Support du Always On

Authentification

Windows Azure Pack 2008 / 2012 / 2014 depuis UR5 Oui Mixte
ADFS 3.0 2008 /2012/2014 Oui Windows Authentication
SCVMM 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SCOM 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SPF 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
Orchestrator 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
SMA 2012 R2 2012 et 2014 depuis UR5 Oui Windows Authentication
Service Reporting 2012 R2 2012 et 2014 depuis UR6 Oui Windows Authentication
Windows Azure Pack WebSites 2012 (pas d’info sur 2014) Attention le Always-On, c’est pas encore disponible.

Ce serait pour l’Update Rollup 9 en 2016.

Mixte
DPM 2012 R2 2012 et 2014 depuis UR6 Non Windows Authentication
Service manager 2012 R2 2012 et 2014 depuis UR6 Oui Windows Authentication
Windows Update Services 2012 et 2014 Pas de contre-indication connue Windows Authentication

Déjà première découverte, SCCM 2012 R2 n’est pas inclus dans la liste. Ce n’est pas une erreur, c’est un choix de ma part. Dans une infrastructure Windows Azure Pack, mon usage de SCCM 2012 R2 se serait limité à gérer le patching de mes hôtes Hyper-V et des machines virtuelles du Fabric Management. WSUS fait cela très bien. Après, SCCM 2012 R2 pourrait avoir d’autres usages mais SCVMM 2012 R2 sera tout à fait capable de :

  • Réaliser le déploiement des hôtes Hyper-V en Bare-Metal
  • Réaliser le déploiement des machines virtuelles

 

Ce choix n’est pas anodin. En retirant SCCM 2012 R2 de l’équation, on supprime au passage bon nombre de contraintes d’architecture. Si le sujet vous tente : Réflexions autour du Patch Management. Un peu d’Orchestrator, de PowerShell et d’huile de de coude et ça fonctionne. L’approche proposée utilisait SCCM mais WSUS sera faire tout aussi bien.

Certains peuvent se demander pourquoi SCSM est toujours présent. C’est que lui, il a quelque chose à offrir : Ses services Requests pour développer des services à destination de nos futurs locataires. Si le sujet vous intéresse, je vous renvoie à la série d’article : A la surface d’un service dans System Center Service Manager. En plus, avec une solution comme Grid-Pro, c’est directement intégré au portail de Windows Azure Pack. L’utilisateur final ne verra jamais Service Manager. Oui, je suis fan de SCSM. Et je m’en porte très bien !

Coté SQL Server, à part une exception avec Windows Azure Pack Web Sites, tous sont éligibles à SQL Server 2014. On a déjà identifié un premier boulet. Maintenant question subsidiaire, tous nos produits System Center pourraient-ils utiliser une même instance SQL Server ? En relisant ce tableau, on sait qu’on a quelques exceptions. Pour cause de mode d’authentification « exotique », la sécurité nous imposera une instance dédiée pour Windows Azure Pack et Windows Azure Pack Web Sites.

 

Maintenant, si on regarde du côté de la haute disponibilité, la liste des boulets va s’étoffer :

  • DPM 2012 R2 est allergique à la fonctionnalité « Always-On » de SQL Server
  • Windows Azure Pack Web Sites devra attendre jusqu’à l’update Rollup 9 pour supporter la fonctionnalité « Always-On » de SQL Server.
  • Windows Azure Pack Web Sites n’est pas encore supporté avec SQL 2014 (Update Rollup 9?)

 

Ce qui signifie que nos besoins peuvent maintenant s’exprimer ainsi :

  • Un Cluster SQL « Always-On « générique » pour tous produits de la gamme System Center sauf DPM
  • Un Failover Cluster SQL pour DPM 2012 R2
  • Un Cluster SQL Always-On pour Windows Azure Pack et son mode d’authentification exotique
  • Un Failover Cluster SQL pour Windows Azure Pack Web Sites (alias boulet en chef)

 

Précisions quelques points pour ce Cluster SQL Always-On « Générique ». Oui, technologiquement c’est faisable mais ce sera une question de performance. Des produits comme SCOM et SCSM sont très consommateurs en I/O. Les ressources CPU et mémoire ne poseront pas de problème si elles sont correctement allouées. Pour SCOM et SCSM, si on peut leur dédier du stockage performant, ce ne sera pas du luxe. Pour approfondir ce sujet, je vous conseille cette lecture : System Center 2012–using a common SQL backend database (#SYSCTR, #SCOM, #SCSM) et Mutualiser des bases de données ConfigMgr et OpsMgr.

 

Pour finir, nos produits de la gamme System Center ont aussi des instances pour leurs usages de Reporting Services. Techniquement, pas de problème pour les héberger sur notre cluster « Always-On Generique ». Après, ce sera nécessairement des serveurs dédiés pour héberger les instances Analysis Reporting Services. Cela concerne SCSM et SCOM. La tentation serait grande de regrouper tous ces besoins. Pas de chance, c’est pas possible : Reporting Services instances cannot be shared between System Center components.

A quelques détails près, on a fait le tour. Mettons tout cela sur un Visio histoire de fixer les choses.

clip_image001

 

Donc on va monter des clusters avec deux nœuds. Le problème, c’est qu’avec un nombre de nœuds pairs, il n’y a pas de majorité en cas de défaillance d’un seul nœud. Il faut un troisième votant qui prendra la forme d’un partage de fichiers. Pour cela, on va configurer nos clusters en mode « Node and File Share Majority ». La seule faiblesse de cette configuration, c’est que si on perd le Datacenter hébergeant la majorité des votants, il n’y a plus la majorité sur l’autre Datacenter. Ce n’est clairement pas parfait mais avec un peu de d’industrialisation, il n’est pas compliqué de déclarer un nouveau votant dans les clusters en cas de défaillance d’un Datacenter. Tous ces clusters et ressources de clusters dépendront du même domaine Active Directory hosting.local.

 

Dernier sujet, le nombre de clusters. Même si techniquement plusieurs instances SQL server peuvent cohabiter au sein d’un même cluster, dans notre contexte, il y a tout de même une distinction à faire au niveau du stockage consommé. Les instances « Failover cluster » utiliseront des ressources disques pour lesquelles un seul nœud ne peut être propriétaire à la fois. Ce n’est pas le cas des instances « SQL Always-On » pour lesquelles chaque nœud du cluster disposera de ressources disques dédiées. Ce sont deux types de stockages bien distincts mais aussi deux usages du cluster différents. Pour cette raison, je recommande de séparer les deux usages en deux clusters distincts.

Prochaine étape SCVMM.

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

Split de listes dans Orchestrator

Orchestrator, c’est un peu le pain quotidien dans mon projet Cloud Privé. Avec le temps, on a appris à se connaitre, s’apprécier, se détester. De temps en temps, je tombe sur un sujet qui semble si simple mais qui devient si compliqué à mettre en œuvre. Généralement, c’est là qu’on aime détester le produit et il ne nous le rend bien. Le split de listes est un de ces cas.

Dans mon cas, je devais accepter une liste de serveurs en paramètre d’entrée pour déclencher des opérations en parallèle, genre déclencher des redémarrages de machines virtuelles. Au début, je pensais que cela allait être développé en cinq minutes. Problème, je me suis vite rendu compte que cela n’allait pas être aussi simple. Il fallait que le résultat de mon split de liste soit stocké dans un tableau. Le problème qui était si simple est devenu bien plus compliqué.

J’ai vite compris que la notion de collection Orchestrator allait être une partie de la solution. Je suis donc partie sur cette piste. En creusant un peu, on comprend que si on veut utiliser les collections, faudra en passer par du C#. Bon, attaquons le problème par la face nord. Ce qui me sauve, c’est qu’on peut faire du C# sans installer Visual Studio, juste avec l’activité .Net Script fournie par Orchestrator. On va commencer par récupérer les paramètres de l’activité « Initialize Data » et réaliser le split dans un tableau.

clip_image001[4]

Juste pour rire, le sujet traité en C#, le tout sans installer Visual Studio. Quand on n’a pas fait de C, C++ ou jamais fait de C#, ça prend un peu de temps.

clip_image002[4]

 

Pour que cela fonctionne, il faut deux choses :

  • Un ou plusieurs namespaces
  • Au moins un Assembly

Dès lors qu’on fait appel au framework .Net, il faut référencer ceux que nous allons utiliser. Ça évite de devoir les référencer à chaque fois dans notre code. Au minimum, on a besoin de la classe System. Dans notre contexte, on va même être plus précis avec la classe System.Collections.Generic. On va en avoir besoin.

clip_image003[4]

 

La notion d’Assembly, c’est juste la version de Framework que nous allons utiliser. Je vais la jouer Old school avec un bon vieux Framework Dot.Net 2.0 pour plateforme X86. Pourquoi ? Ben par ce qu’Orchestrator est aussi une application X86. ca a son importance?

clip_image004[4]

 

Pour préparer la suite, nous allons avoir besoin de configurer notre variable de sortie nommée VMlistO. Ce sera une variable de type « String » pour laquelle on aura activé la case d’option « Collection ».

clip_image005[4]

 

Une fois qu’on exécute cela dans le debugger Orchestrator, on obtient le résultat ci-dessous :

clip_image006[4]

 

Et magie, cela fonctionne puisque chaque serveur est bien considéré comme un élément distinct de la collection que l’activité suivante pourra récupérer pour traitement (redémarrer le serveur en question).

clip_image007[4]

 

C’était rigolo en C# mais ce n’est pas forcément votre langage de prédilection, ni le mien. On a beau dire, j’ai mal. Mal que ce soit aussi compliqué d’obtenir ce résultat aussi simple. Revenons donc à PowerShell. Dans le principe général, rien ne change.

clip_image008[4]

 

En PowerShell, le code est très ressemblant. Y a juste un grand secret. PowerShell ne vous impose pas de déclarer et typer vos variables. Et cette seule ligne va tout changer.

clip_image009[4]

 

Powershell reposant sur le Dot.Net Framework, il n’y a donc plus besoin de déclarer son usage. C’est beaucoup plus simple ainsi.

clip_image010[4]

 

Autre différence, dans la déclaration de variable de sortie, on constate qu’il n’est pas possible de déclarer que notre variable sera une collection. Par contre, c’est notre déclaration de variable qui va se charger de cela.

clip_image011[4]

 

Au final, dans le debugger Orchestrator, j’ai bien une variable VMListOutput.

clip_image012[4]

 

Dans le détail, on obtient bien le même résultat.

clip_image013[4]

 

Conclusion, tout est une histoire de rigueur dans la déclaration des variables. C’est ça qui fait toute la différence. Au passage, je recommande cet excellent article : Automation–Orchestrator Tip/Trick–Run .Net Script Activity + PowerShell + Published Data Arrays.

Après, il reste aussi possible de travailler autrement avec les workflows PowerShell. Un grand merci à Laurent DARDENNE pour ce tutorial qui a éclairé le sujet. Un workflow pour rebooter des serveurs, c’est effectivement une bonne idée, sauf que dans mon cas, c’est une fausse bonne idée, pour les raisons suivantes :

  • Les workflows PowerShell, ça veut dire une instance PowerShell X64. Or avec Orchestrator, on n’a que la version X86 avec Orchestrator. Ne présumez jamais de la version d’Orchestrator.
  • Les workflows permettent de reprendre leur activité au redémarrage du serveur, encore faut-il que ce soit dans le même contexte de sécurité. Dans mon cas, si je dois redémarrer, c’est que ma machine virtuelle vient de joindre le domaine et doit continuer son processus d’installation avec un compte de service

Donc maintenant, plus d’excuse, on déclare ses variables car Orchestrator sait en tenir compte.

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

Prise de tête avec la Terminal Server Gateway (re-publication)

Note à mes lecteurs assidus : Oui, ça ressemble à un vieux billet de 2008. Lors de la migration du blog vers la nouvelle plateforme, il y a eu du déchet que je corrige peu à peu. Selon l’importance des corrections, ça peut aller jusqu’à la republication du billet. A l’époque, il y avait encore de l’ISA/TMG au programme Clignement d'œil.

Voilà une fonctionnalité de Windows Server 2008 qui mérite qu’on creuse un peu plus le sujet. Avec Windows Server 2003, on pouvait déjà encapsuler le protocole RPC de Microsoft Outlook dans un flux HTTP. Avec Windows Server 2008, Microsoft a étendu l’utilisation de l’encapsulation au protocole RDP.

Cette approche permet de sécuriser l’utilisation du protocole RDP sur un réseau LAN ou depuis le réseau extérieur. Tous les flux HTTPS arrivent sur un serveur dit « passerelle » qui se charge de de décapsuler le flux HTTPS pour ressortir sous la forme du protocole RDP. Le principal avantage de cette approche est de pouvoir faire passer tous les flux RDP sous un même port (443) pour de multiples destinations. On évite donc les multiples ouvertures de port sur le pare-feu extérieur.

De l’extérieur, l’accès à la Terminal Server Gateway est contrôlé par les « Connection Authorization Polices (CAP) ». Après, l’accès aux serveurs Terminal Serveurs ou aux clients Remote Desktop s’effectue selon les conditions dictées par les « Ressource Authorization Policies (RAP) ».

En terme d’implémentation, on distingue trois scénarios :

  • Le Terminal Server Gateway sur le réseau interne
  • Le Terminal Server Gateway sur le réseau périmétrique
  • Le Terminal Server Gateway publié par un ISA Server

 

Le Terminal Server Gateway sur le réseau interne

clip_image001

Ce scénario peut être difficile à implémenter dans la mesure où cela nécessitera de mettre en œuvre un pare-feu sur le réseau interne qui non seulement laisse passer le flux 3389 sur le port TCP (tout à fait normal )mais aussi les flux liés à l’ annuaire Active Directory car la CAP impose de sélectionner au minimum un groupe d’ utilisateurs, idéalement, un groupe de domaine si on ne veut pas fournir deux authentifications distinctes (Compte local sur la TS Gateway puis compte Active Directory). Techniquement, c’est possible à condition d’utiliser ISA Server 2006 avec le filtrage de protocole RCP sur les UUID. C’est un peu long à mettre en œuvre mais c’est réalisable. Il est possible d’envisager une version allégée de ce scénario en supprimant le pare-feu sur le réseau interne même si ce n’est pas le meilleur choix.

Le Terminal Server Gateway sur le réseau périmétrique

clip_image002

 

Le second scénario pose le même problème. Là il est obligatoire d’utiliser ISA Server 2006 pour le mettre en œuvre. Reste tout de même à convaincre le client d’accepter ISA Server comme pare-feu même de bas niveau (au plus proche du LAN). Bon nombre de personnes y sont encore réticentes pour des raisons historiques qui n’ont plus vraiment lieu d’être aujourd’***…

Le Terminal Server Gateway publié par un ISA Server / TMG

clip_image003

 

Pour le troisième, c’est un scénario « full ISA Server/TMG », ce qui en matière de sécurité n’est pas une bonne pratique (ISA en DMZ et ISA comme pare-feu de bas niveau). On préfèrera différencier les fournisseurs à ce niveau.

Globalement, c’est le premier scénario qui sera le plus utilisé.

 

Le Nœud du problème

Maintenant rentrons dans le nœud du problème : les certificats. Ayant eu la chance de participer au Tech-Ed 2008 à Barcelone (Merci patron !). J’ai assisté à la conférence « Windows Server 2008 Terminal Services Deep Dive – Gateway Security and certificates » d’Alex Balcanquall, Senior Product Manager chez Microsoft de son état. Au terme de sa présentation, j’ai posé une question toute simple : La TS Gateway n’accepte qu’un seul certificat, donc qu’un seul nom (selon l’interface). Comment peut-on faire pour utiliser un nom pour la TS Gateway interne qui est différent de celui utilisé en externe ? D’un point de vue purement « paranoïaque » de la sécurité, cela se tiens. Techniquement, le plus simple consiste à utiliser ISA Server pour publier sous un autre nom. Mais c’est contourner le problème.

A cette question, il m’a été répondu que c’était une très bonne question mais sans avoir pour autant de réponse (ni le sac à dos promis pour les meilleures questions posées, …).

La réponse

La réponse, elle est normande, cela dépend. Selon les informations de Microsoft sur les caractéristiques du certificat à utiliser (http://technet.microsoft.com/en-us/library/cc731264.aspx) le certificat doit présenter les caractéristiques suivantes :

  • The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
  • The certificate is a computer certificate.
  • The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
  • The certificate has a corresponding private key.
  • The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
  • A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
  • The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer.
L’attribut SAN

C’est le premier point le plus important. Techniquement oui c’est possible, tout dépend de l’autorité de certification. Dès lors qu’on utilise une autorité de certification « Entreprise de Microsoft », c’est là que cela devient compliqué :

  • Le certificat doit être généré à l’aide du template « Computer », sinon la TS Gateway refusera le certificat
  • Les modèles de certificats de l’autorité de certification de Microsoft ne sont personnalisables que sur une autorité de certification de type « Entreprise »
  • Le modèle de certificat « Computer » utilise le FQDN de l’ordinateur pour renseigner le champ « Subject » du certificat. Cela signifie que si on désire utiliser un autre noms, l’autorité de certification ignorera le paramètre dans la demande.

 

Par défaut, l’ extension SAN, n’ est pas activée, qu’ à cela ne tienne on va l’ activer (http://support.microsoft.com/kb/931351/en-us):

clip_image004

 

Après un redémarrage, notre autorité de certification va accepter de traiter l’attribut Subject Alternative Name. Ou presque, …

 

Le modèle de certificat « Computers »

C’est la seconde étape. Oui l’autorité de certification accepte de traiter les demandes de certificats pour l’attribut Subject Alternative Name » mais elle continue obstinément à les refuser dès lors qu’on lui demande un certificat pour un ordinateur. La raison est toute simple, elle tient dans l’illustration ci-dessous :

clip_image005

 

Le modèle de certificat « Computer » prévoit de récupérer le « Subject Name » directement dans l’annuaire Active Directory, ignorant donc l’attribut SAN. La seule solution, c’est de dupliquer ce modèle de certificat. Le nouveau modèle de certificat « TS Gateway Certificate » integer:

  • La reconfiguration de l’attribut « Subject Name »

clip_image006

  • Le modèle soit « Superseeded » le modèle de certificat « Computers »

clip_image007

 

C’est très important, car la TS Gateway vérifie que le certificat qu’on lui soumet a été généré selon le modèle « Computers » ou dérivé de celui-ci.  Le modèle de certificat est alors prêt à être publié pour être utilisable immédiatement.

 

La demande de certificat en ligne (Cas Autorité de certification intégré à l’ AD)

Commençons par le cas le plus simple, une demande de certificat en ligne pour notre futur TS Gateway :

clip_image008

 

Jusque-là, je n’ai perdu personne.

clip_image009

 

Le modèle de certificat « TS Gateway certificate » est bien proposé mais pour être utilisable il est nécessaire de compléter un certain nombre d’informations en cliquant sur « More information is required to enroll for this Certificates ».

clip_image010

 

C’est là que se situe la subtilité. Il faut dans un premier temps spécifier un Subjet Name pour le compte ordinateur de notre TS Gateway mais aussi le ou les Subject Alternatives Names à utiliser. On remarquera que j’ai référencé un nom extérieur, un nom DMZ et un troisième correspondant au nom DNS sous lequel la TS Gateway sera accessible depuis le réseau LAN de l’entreprise.

Note : le dernier n’est utile que si l’on désire rendre accessible sa TS Gateway sur le réseau interne.

clip_image011

 

Pour finir, il est vivement conseillé d’utiliser l’attribut « Friendly Name » pour faciliter la suite de la demande de certificat.

clip_image012

 

La demande de certificat est maintenant complète, elle peut être soumise à l’autorité de certification intégrée à l’annuaire Active Directory et être approuvée

clip_image013

 

La demande de certificat offline (Cas autorité de certification tierce ou autonome)

C’est le même principe. Windows Server 2008 nous aide à formater la requête pour pouvoir la soumettre à une autorité de certification tierce

clip_image014

 

Je n’ai toujours jamais perdu quelqu’un à l’écran d’accueil !

clip_image015

 

On sélectionne note modèle de certificat « TS Gateway Certificate »

clip_image016

 

L’interface est quelque peu différente d’une demande en ligne mais le principe reste identique, à savoir qu’il faut compléter la demande avant de pouvoir la soumettre.

clip_image017

 

Toujours les mêmes informations, à savoir un Subject Nme représenté par le « Full DN » du compte ordinateur puis les « Subject Alternatives names » ajoutés sous formes de noms DNS.

clip_image018

 

La demande ainsi préparée peut-être soumise à une autorité de certification.

 

Le certificat dans la console « Terminal Server Gateway

Dès lors que le certificat a été installé sur le serveur de la TS Gateway et associé à celle-ci, l’interface d’administration indique uniquement le « Subject name » dans le champ « Issued To ».

clip_image019

 

Si on vérifie avec des clients, on peut valider que la TS Gateway répond bien à tous les noms positionnés SAN positionnés dans la demande de certificat.

Conclusion

En conclusion, oui, c’est possible, sauf que ce n’est pas le scénario le mieux documenté. L’interface d’administration n’a pas été prévu pour afficher l’éventuel attribut SAN. Une TS Gateway peut donc répondre à plusieurs noms (interne, externe, nom pour chaque partenaire, …). C’est juste un petit peu plus complexe à mettre en œuvre. Le premier avantage de ce scénario est de pouvoir utiliser la même TS Gateway pour plusieurs usages et non en dédier une par usage. Le second avantage et non des moindre est de pouvoir affiner les stratégies de filtrage CAP par défaut pour différencier les accès internes des accès Externes (aller faire un tour dans la console du NPS installé sur la TS Gateway dans le noeud « Network Policies »).

Note à certains lecteurs : Je mérite encore plus mon sac à dos pour avoir trouvé moi-même la solution au problème posé!

Architecture WAP – Design infrastructure Active Directory Certificates Services

Les adeptes de la PKI en mode Click-Next aussi nommé « Quick and Dirty » peuvent s’arrêter ici. Je ne prétends pas proposer une infrastructure « state of the art » en la matière mais au moins une architecture censée, répondre à nos besoins. Tous les produits que nous allons mettre en œuvre dans notre infrastructure Windows Azure Pack vont avoir besoins de certificats délivrés par une autorité de certification. Nous allons avoir deux cas d’usage pour ces certificats :

  • Privé : Utilisés uniquement en interne et donc délivrés par une autorité de certification privée
  • Public : Utilisés en interne et depuis Internet, nécessitant d’être délivrés par une autorité de certification publique

Pour la partie publique cela va aller très vite, il faut juste faire les bons choix :

  • Choix autorité de certification : S’assurer qu’elle et référencée comme « Trusted » par le Windows Root Certificate Program
  • ADFS : Inutile de vouloir utiliser le Cryptographic Next Generation (CNG) pour générer la clé privée du certificat, c’est pas supporté avec Windows Server 2012 R2. Il existe des workarounds publiés ici ou là mais ce n’est certainement pas supporté par Microsoft
  • Référencer des FQDN privés pour des certificats issus d’une AC publique, cela n’est plus possible : All publicly trusted SSL Certificates issued to internal names and reserved IP addresses will expire before November 1, 2015.
  • Certificat Wildcard : La fausse bonne idée. Oui, techniquement, cela fonctionne. Le problème est plus de l’ordre du process. Si on arrive bien à utiliser ce certificat sur l’ensemble de notre infrastructure, seront nous capable de le renouveler et de le remplacer partout où il a été utilisé. Mon avis est que ce sera très difficile d’opérer tous les changements sur une infrastructure en production en un minimum de temps sans perturber le service rendu aux utilisateurs.

 

Remarques :

 

La partie publique est close, passons maintenant à l’autorité de certification privée et commençons par le sommet de la hiérarchie avec l’autorité racine.

Design autorité de certification racine

Dans notre contexte, une seule hiérarchie sera nécessaire, cela limite donc le nombre d’autorité racine à une. Problème, nous savons que s’il n’y en a qu’une, sa défaillance peut avoir de fâcheuses conséquences (impossibilité de mettre à disposition une CRL récente, …). Quand on parle défaillance, il peut y avoir deux grandes causes :

  • Physique / Virtuelle : Problème matériel empêchant le démarrage du système d’exploitation
  • Logiciel : Problème lié au système d’exploitation en lui-même empêchant de rendre le service

Dans le contexte d’un projet Windows Azure Pack, déployer notre autorité de certification racine sur une machine virtuelle a du sens. Avec la fonctionnalité Hyper-V Réplica, nous sommes en mesure de répliquer le contenu de la machine virtuelle dans une nouvelle enveloppe située dans le second Datacenter. Pour la défaillance logicielle Hyper-V Réplica ne pourra pas grand-chose pour vous, la seule solution réside dans un bon plan de sauvegarde / restauration. Ceci posé, nous pouvons aborder les choix d’installation :

  • Domaine versus Workgroup : Pour une autorité racine hors ligne ce sera Workgroup.
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Standalone car j’ai l’intention de respecter les best-practices et de configurer notre autorité de certification racine en mode « Offline »
  • Cryptographie : c’est le moment de faire les bons choix en terme de cryptographie. Typiquement, voilà les mauvais choix à ne pas faire aujourd’hui :

clip_image001

  • Période de validité : Rappeler-vous qu’une autorité de certification ne peut pas délivrer de certificat au-delà de la date d’expiration inscrite dans son certificat. Disons que le choix par défaut de 5 ans est un peu court. 10 ce sera mieux.
  • Durée de vie des CRL : Pour une autorité de certification racine, disons que la CRL aura une durée de vie d’un an. Notre autorité de certification racine devra être remise en ligne au moins une fois par an pour publier de nouvelles CRL et CRL Delta.
  • Séparation des rôles : C’est présent depuis Windows 2003 et ce n’est toujours pas du luxe. Pensez un peu aux RSI & RSSI qui voient se monter une infrastructure de clés publique à usage uniquement techniques
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet.
  • Et pour finir la sauvegarde de la clé privée. La base de données ADCS ne sert à rien sans le certificat avec sa clé privée, rappel : ADCS CA private key location change (again).

Je suis allé volontairement à l’essentiel. Pour le reste :

Pour finir, un rappel, pour sécuriser cette autorité de certification, on voudra mettre en place Hyper-V Réplica. Dans la logique de vouloir sécuriser la copie entre le serveur Hyper-V primaire et son partenaire, on voudra utiliser l’authentification par certificat. C’est une excellente idée. La subtilité, c’est qu’il faudra attendre d’avoir une autorité de certification intermédiaire / émettrice de certificats pour cela. Passons maintenant aux autorités émettrices de certificats.

Design autorité de certification intermédiaire / émettrice

Le sujet autorité racine étant clos, passons à celui des autorités intermédiaires et émettrices de certificats. Dans le contexte d’un déploiement Windows Azure Pack, je n’ai pas de motif technique, sécurité, règlementaire ou même business nous forçant à avoir une hiérarchie de type trois tiers (racine, intermédiaire, émettrice). Vu que notre autorité racine est « hors ligne », on va logiquement allers vers une hiérarchie de type deux tiers (racine, intermédiaire & émettrice). Maintenant, posons-nous la question, pouvons-nous avoir une seule autorité intermédiaire / émettrice pour tous nos usages ? D’un point de vue purement technique oui. Par contre du point de vue de la sécurité, la logique voudrait que non car tous les certificats qui vont être délivrés n’ont pas la même valeur / criticité. Dans notre contexte, je vois deux usages :

  • Les certificats à usage technique
  • Les certificats à usage d’identité

Lorsqu’on va vouloir renforcer la sécurité du Fabric Management, on aura besoin de certificats permettant à nos exploitants de prouver leur identité. Apporter la preuve de son identité, c’est un process qui peut être plus ou moins complexe mais qui à la fin se finira par une action technique pour délivrer le certificat. Le problème, c’est que si on utilisait une seule autorité de certification pour les deux usages de certificats, il pourrait être assez facile pour un exploitant de se gérer des identités. Pour éviter cela, on va séparer les usages. Nous aurons donc deux autorités intermédiaires / émettrices de certificats. Côté technique, les choix seront quelque peu différents :

  • Domaine versus Workgroup : Pour une autorité intermédiaire / émettrice, elle sera raccordée au domaine
  • StandAlone versus Enterprise : la réponse va être rapide, ce sera Enterprise car cela autorise des scénarios intéressants tel que l’Auto-Enrôlement
  • Cryptographie : Plus possible de faire les mauvais choix, c’est l’autorité racine qui va nous imposer les bons choix
  • Période de validité : Logiquement, la durée de vie sera inférieure à celle de l’autorité racine
  • Durée de vie des CRL : Pour une autorité de certification intermédiaire
  • Séparation des rôles : C’est essentiel pour les autorités de certification intermédiaires
  • Multiples points de mise à disposition des CRL : Au moins un par Datacenter (chemin UNC). Si vous ne savez plus, allez lire un des best-off de la maison : Publier une PKI sur Internet. OCSP serait même un luxe à ne pas négliger

 

L’indisponibilité d’une autorité de certification émettrice de certificats pose aussi beaucoup de problèmes. On devra donc penser haute disponibilité. Immédiatement, on pense à deux fonctionnalités :

  • Hyper-V Réplica
  • Le cluster Hyper-V

Dans un contexte multi-Datacenter, le choix du cluster peut poser problème si on ne dispose pas d’un Geo-Cluster entre les deux Datacenter. Cela implique qu’on soit capable de répliquer le stockage via un réseau WAN très performant. Ce n’est pas forcément possible. Par contre, on peut très bien combiner les deux approches. C’est aussi valable pour notre autorité de certification racine. Toute notre hiérarchie sera hébergée sur un cluster dédié (on verra pourquoi plus tard). Les machines virtuelles seront donc des ressources du cluster en question. On installera le Rôle Hyper-V broker sur ce cluster afin de pouvoir mettre en place Hyper-V Réplica vers un autre cluster situé dans un autre Datacenter.

clip_image002

 

Pour la disponibilité des CRL, j’ai volontairement fait simple avec une double publication :

  • Dans des partages de fichiers hébergés sur des contrôleurs de domaine
  • Dans l’Active Directory

 

Ici encore, je suis allé volontairement à l’essentiel. Pour les détails, je vous renvoie vers d’excellents articles / billets :

 

Pour clore ce billet, cette implémentation n’a pas prétention à être parfaite, il reste encore beaucoup à faire mais cela sort du cadre d’une infrastructure Windows Azure Pack :

  • Pas de HSM pour permettre du Key Archival
  • Pas de support d’Online Responder Revocation Policy (OCSP) en plus des CRL
  • Pas de support de l’enrôlement de certificats par Web Services
  • Pas de gestion de l’auto-enrôlement

On est déjà bien loin du Quick and Dirty.  Prochaine étape SQL Server.

 

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

Architecture WAP : Introduction

Ca faisait quelques temps que nous avions pas fait un tour dans le donjon, le revoilà. On va continuer à parler de Windows Azure Pack. Non pas pour ajouter de nouveaux composants mais pour les revisiter et discuter architecture et répondre principales questions liées au design d’une infrastructure Windows Azure Pack hautement distribuée. Avant de parler de Windows Azure Pack, nous allons avoir beaucoup de sujets de discussions :

Cela va rester du haut niveau. L’idée est de répondre aux questions les plus importantes pour poser les fondations de votre future infrastructure Windows Azure Pack. Je fais l’impasse sur la conception même des Stamps que vous allez déployer, il y a trop de paramètres à prendre en compte, ça dépasse de loin le cadre de l’architecture d’une infrastructure Windows Azure Pack. On commence avec une page blanche, à savoir deux Datacenters interconnectés par un bon WAN :

clip_image001

Bonne lecture, on commence avec un sujet simple pour commencer : Design infrastructure Active Directory.

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

Architecture WAP – Design infrastructure Active Directory

Ça semble tellement simple qu’on se demande pourquoi il faudrait se poser la question. Si simple vous dites? Entrez, on va discuter, … On va effectivement commencer avec un AD pour le cœur de notre infrastructure. On va donc y raccorder :

  • L’infrastructure ADFS
  • Notre infrastructure Windows Azure Pack (partie privilégiée)
  • Notre infrastructure Windows Azure Pack (partie locataire)
  • L’infrastructure SCOM (management Server et Dataware House Server)
  • L’infrastructure Service Manager Automation / Orchestrator
  • L’infrastructure SCVMM avec son Service Provider Foundation

Etrange, je n’ai pas cité les clusters Hyper-V? C’est normal car on va faire les choses correctement. Tous les produits cités précédemment constituent le Fabric Management de notre infrastructure Windows Azure Pack. Une bonne pratique est d’isoler ces composants dans une forêt d’administration dont l’accès sera limité aux seuls exploitants de la plateforme. Maintenant, parlons des Clusters Hyper-V. On va distinguer :

  • Les clusters Hyper-V utilisés pour héberger le Fabric Management
  • Les Clusters hyper-V utilisés pour héberger les workloads de nos futurs locataires

 

Pour le Fabric Management, il est logique de les raccorder à la forêt d’administration. Au passage, c’est dans ce domaine que sera réalisé la préparation de domaine pour stocker les secrets de SCVMM. Pour rappel, lors de l’installation de SCVMM on doit décider si on veut stocker les clés de SCVMM localement ou dans l’Active Directory. C’est ce dernier choix qui sera le bon. Ces clés sont essentielles car sans elles on ne peut pas accéder à la base de données de SCVMM. Je vous laisse deviner ce qui se passerait si on avait retenu de les stocker localement et qu’on ait perdu le serveur physique ou virtuel. Comme une petite piqure de rappel ne fait jamais de mal, autant, quelques lectures saines :

clip_image001

Maintenant attaquons nous au problème des clusters Hyper-V prévus pour héberger les workloads de nos futurs locataires. Doit-on les raccorder à la forêt d’administration? La réponse est dans la question. Il faut une claire séparation entre les usages. On va donc avoir une second forêt que je nomme « hosting.local » qui disposera d’une relation d’approbation unidirectionnelle (sécurité oblige). On y placera les clusters Hyper-V qui hébergeront les workloads de nos locataires. Si tout était si simple ce serait bien. Nous n’avons pas encore parlé de l’infrastructure WebSites. Pour rappel, elle comprend les rôles suivants :

  • Management Server
  • Controller
  • Database
  • Publisher
  • File Server
  • Web Worker
  • Frond-End

L’infrastructure Azure Pack Web Sites présente l’avantage de pouvoir fonctionner indépendamment des domaines avec des machines en Workgroup. Sur le papier, c’est pas mal. Le problème, c’est que cela rend cette infrastructure plus compliquée à exploiter. Essayons de raisonner différemment. Quels sont les rôles qui assurent la gestion de l’infrastructure et quels sont ceux qui sont consommés par les locataires :

  • Management : Participe à la gestion de l’infrastructure
  • Controller : Participe à la gestion de l’infrastructure
  • Database : Participe à la gestion de l’infrastructure
  • Publisher : Participe à la gestion de l’infrastructure
  • File Server : Participe à l’usage par les locataires
  • Web Worker : Participe à l’usage par les locataires
  • Frond-End : Participe à la gestion de l’infrastructure

On comprend que bon nombre de rôles sont liés à la gestion de l’infrastructure. Les instances de ces rôles seront donc déployées sur des machines virtuelles raccordées au domaine d’administration. Il ne nous reste que File Server et Web Worker. Ces deux rôles sont directement liés aux locataires :

  • File Server : Stockage et dépôt des packages WebDeploy des locataires et donc repository des sources pour alimenter les instances Web Worker
  • Web Worker : Consommation des packages Web Deploy en mode cohabitation ou isolé

Pour ces deux rôles, la recommandation est effectivement de les raccorder au domaine « hosting.local ». Pour conclure, voilà les bases de notre infrastructure Active Directory posées :

clip_image002

Avec deux Datacenters, je commence par poser deux zones réseau distinctes pour bien séparer les deux forêt Active Directory qui vont être mises en place. Dans chaque Datacenter, les contrôleurs de domaine de chaque forêt seront hébergés sur des clusters Hyper-V distincts. Nous aurons donc :

  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine WindowsAzurePack.Local
  • Deux clusters Hyper-V distincts pour héberges les contrôleurs de domaine du domaine hosting.local

De cette manière, chaque Datacenter est indépendant de l’autre. La défaillance d’un Datacenter n’aura donc aucun impact sur le service Active Directory et ce pour les deux forêts.

Remarques :

  • J’ai volontairement exclus le choix Workgroup pour l’infrastructure Web Sites de Windows Azure Pack. Ce mode de fonctionnement nous interdit de proposer à nos locataires une authentification Windows intégrée dans leurs sites web. S’interdire de proposer du service à nos futurs locataires est un non-sens
  • Les contrôleurs de domaine sont nécessairement des serveurs physiques, Pas de concession sur ce point.
  • J’ai volontairement exclus de parler des RODC. Pour la forêt d’administration, il n’y a pas de besoin vu que c’est une forêt isolée. Pour la forêt dédiée aux locataires, ça peut avoir un sens mais uniquement pour le rôle Front-end

Alors, toujours un simple Active Directory posé sur un coin de table?

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