Archives mensuelles : juillet 2015

Architecture Windows Azure Pack Web Sites – Etape n°6 : Mise à disposition des Web Sites aux locataires

Nous sommes définitivement de retour dans Windows Azure Pack. C’est l’heure des choix avec la création du plan. Que va-t-on proposer à nos locataires? Comme pour les autres Resources Providers, on a besoin d’un plan, de préférence sans accroc.

clip_image001

 

Plus précisément d’un Hosting Plan dans lequel on va proposer notre nouveau Resource Provider.

clip_image002

 

Ce nouveau plan / abonnement proposera aussi les autres ressources providers que nous avons sur la plateforme. Pour l’architecture Web Sites, ça a du sens.

clip_image003

 

Pour la subtilité (et un rappel à une séance de torture précédente), le Resource Provider lié aux machines virtuelles indique une configuration incomplète. C’est normal, il faut préciser quel serveur SCVMM le Service Provider Foundation doit solliciter et surtout quel Cloud (au sens SCVMM) on devait utiliser.

clip_image004

 

Revenons maintenant à notre architecture Web Sites. Celle-ci proposer de configurer chacun des trois niveaux qui seront proposés à nos futurs locataires :

  • Intro
  • Basic
  • Reserved

Pour faire simple, on a deux niveaux d’instances partagées et un niveau d’instance dédiée. Pour chaque niveau de service, on peut configurer dix-sept paramètres. Une première lecture rapide nous indique que dans le niveau (Intro), tout est mis en œuvre pour limiter l’utilisation des ressources et donc garantir la cohabitation d’un grand nombre d’instances de sites Web sur notre infrastructure. Dès lors qu’on arrive aux niveaux Basic et Reserved, certains paramètres n’ont plus de limite.

clip_image005

 

Le choix du niveau de service est sous la responsabilité du futur locataire. Ils peuvent migrer leur sites web d’un nouveau à un autre dynamiquement, après, c’est une question de cout. Ci-dessous un extrait de l’article Technet « Plan Authoring for Windows Azure Pack: Web Sites » décrivant tous les paramètres. Y a de quoi faire :

 

Quota name

Description

Subscription CPU Time

Represents, in minutes, the CPU time a subscription’s websites can consume across all instances over a specified enforcement period. You can specify a value or choose the Unlimited option. The default for each service level is Unlimited. There is an Enforcement Duration (Minutes) setting, for which the default is 1440 (=24 hours). The Exceed Action setting is available.

Subscription CPU Burst Time

Represents, in minutes, the CPU time a subscription’s websites can consume across all instances over a specified enforcement period. A shorter enforcement duration can help reduce CPU spikes. You can specify a value or choose the Unlimited option. The default for each service level is Unlimited. The default Enforcement Duration (Minutes) setting is 1440 (=24 hours). The Exceed Action setting is available.

Process CPU Burst %

Represents the CPU percentage a worker process can consume over a specified enforcement period. The default for each service level is 100 percent. The default Enforcement Duration (Minutes) setting is 10 minutes.

Subscription Memory – Maximum Working Set

Represents, in megabytes, the physical memory (RAM) a subscription’s websites can consume over a specified enforcement duration. You can specify a value in megabytes or choose the Unlimited option. The default for each service level is Unlimited. The default Enforcement Duration (Minutes) setting is 1440 (=24 hours). The Exceed Action setting is available.

Process Memory Limit

Represents the total memory a worker process can consume. The default for each service level is 1024 (=1 gigabyte).

Process Memory – Maximum Working Set

Represents, in megabytes, the physical memory (RAM) a worker process can consume. The default for each service level is 1024 (=1 gigabyte).

Subscription Bytes In

Represents, in megabytes, the incoming bandwidth a subscription’s websites can consume over a specified enforcement period. You can specify a value in megabytes or choose the Unlimited option. The default for each service level is Unlimited. The default Enforcement Duration (Minutes) setting is 1440 (=24 hours). The Exceed Action setting is available.

Subscription Bytes Out

Represents, in megabytes, the outgoing bandwidth a subscription’s websites can consume over a specified enforcement period. You can specify a value in megabytes or choose the Unlimited option. The default for each service level is Unlimited. The default Enforcement Duration (Minutes) setting is 1440 (=24 hours). The Exceed Action setting is available.

Subscription Storage Space

Represents, in megabytes, the storage space a subscription’s websites can consume. You can specify a value in megabytes or choose the Unlimited option. The Shared setting configures both the Intro (Shared) and Basic (Shared) service levels. There is a separate setting for Reserved. The default for each service level is 1024 (=1 gigabyte).

Subscription Site Count

Represents the number of websites in a subscription. You can specify a number or choose the Unlimited option. Unlimited is the default for each service level.

Subscription Web Worker Count

Represents the number of web workers a subscription’s websites can consume simultaneously. You can specify a number or choose the Unlimited option. Unlimited is the default for each service level.

Subscription Custom Domain Support

Enables or disables custom domain names. Off is the default setting for Intro (Shared). On is the default setting for Basic (Shared) and Reserved.

Subscription SSL Support

Enables or disables custom SSL certificates. Possible values are Off, SNI, SNI and IPv4, SNI and IPv6, and SNI, IPv4 and IPv6. The default for Intro (Shared) is Off. The default for Basic (Shared) is SNI. The default for Reserved is SNI and IPv4.

Subscription 64 bit Worker Process Support

Enables or disables 64 bit worker processes. Off is the default for Intro (Shared) and Basic (Shared). On is the default for Reserved.

Subscription WebSocket Support

Enables or disables the WebSocket protocol. Off is the default for Intro (Shared) and Basic (Shared). On is the default for Reserved.

Process Concurrent Request Limit

Represents the number of concurrent requests permitted per worker process. You can specify the number of connections. The default is 5000 for each service level.

Process Idle Timeout

Represents, in minutes, the amount of time that a worker process is allowed to remain idle before it is stopped. The default for Intro (Shared) is 20 minutes. The default for Basic (Shared) is 60 minutes. The default for Reserved is 10080 (=7 days).

 

Note : Toutes les fonctionnalités ne sont pas disponibles dans le niveau de service Intro  et Basic.

Notre plan est maintenant opérationnel, il ne nous reste plus qu’à le rendre public pour que nos locataires puissent y souscrire.

clip_image006

Le locataire n’a plus qu’à consommer le service mis à disposition. Ne vous méprenez pas, il y a beaucoup à voir coté expérience utilisateur et se qui se passe sous le capot.

 

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

Windows Azure Pack UR7, quoi de neuf?

Si vous n’avez rien à déployer cet été et que mes séances de tortures ne vous rebutent pas, il y a l’Update Rollup 7 de System Center à mettre en œuvre sur votre plateforme Windows Azure Pack. Pour rappel, Windows Azure Pack s’inscrit dans le cycle des Update Rollup de System Center. Pour cette livraison, la liste est plutôt intéressante, rien que quelques-uns ont attiré mon attention :

Windows Azure Pack (KB3069121)

  • Tenants cannot delete the checkpoints of their virtual machines

On évite ainsi le problème que l’on rencontre depuis l’apparition de cette fonctionnalité avec l’UR6. Le locataire pouvait demander la création d’un checkpoint. Mais pour la suppression c’était plus compliqué, comme expliqué dans ce billet de Kristian Nese. Maintenant, nos locataire peuvent eu même supprimer leurs checkpoints qui ne servent pas.

  • Support for tenant plan viewing and self-subscription permission based on security groups
    On touche au divin. Avant pour faire des « Beta privées », on était obligé de conserver le plan en « Private » et d’inviter les locataire sélectionnés. Avec l’UR7, on peut filtrer l’accès aux différents plans en fonction de groupes de sécurité. C’est super-intéressant lorsqu’on a plusieurs locataires et différentes offres à proposer sur une même infrastructure Windows Azure Pack. Cela fera l’objet d’un billet plus tard.

 

Windows Azure Pack Web Sites version 2 (KB3069358)

  • In new installations of Windows Azure Pack Web Sites, publishing through the SCM site is enabled by default.

C’est bien, je vais pouvoir actualiser ma série de billets sur l’architecture Web Sites.

  • Changes Web Deploy publishing from publish.domain.com to site.scm.domain.com.

 

System Center Virtual Machine Manager 2012 R2 (KB3066340)

  • Option to Reassociate Orphaned virtual machines to their Service or VM role

Merci car c’est un problème que j’ai rencontré avec les Services Templates avec SCVMM.

 

N’oubliez pas que l’équipe derrière Windows Azure Pack nous écoute et attend nos feedbacks pour les prochains Update Rollup.

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

Architecture Windows Azure Pack WebSites – Etape n°5 : Intégration avec Windows Azure Pack

C’est l’heure du retour de Windows Azure Pack. Les braises sont chaudes, prenez place sur le chevalet, la séance de torture va reprendre. Mais vous être là pour cela après tout?

On sait que le rôle Management assure la passerelle avec Windows Azure Pack et que ce dernier ne fonctionne qu’avec des Web Services communiquant entre eux. Logiquement, le Management Server héberge le Resource Provider attendu par Windows Azure Pack. Comme nous l’avons déjà vu, il y a beaucoup de certificats, trop souvent auto-signés. Le rôle Management n’échappe pas à cette règle. Lorsqu’on ouvre la console IIS sur ce serveur, on trouve un site Web nommé HostingManagementServices auquel est associé un certificat auto-signé. Beurk!

clip_image001

 

Nous allons le remplacer par un certificat délivré par notre autorité de certification interne.

clip_image002

 

Maintenant, on peut retourner dans Windows Azure Pack. Attention, ça va aller très vite. Dans le portail d’administration, on dispose d’un nœud « Web Site Clouds ». On peut référencer autant d’architectures Web Sites que l’on veut. On va commencer petit joueur, une seule suffira.

clip_image003

 

Référencer l’architecture Web Sites, c’est juste indiquer la localisation du Resource Provider que Windows Azure Pack devra prendre en compte et un contexte de sécurité. Attention, c’est le compte que nous avons déclaré lors de l’installation de l’architecture Web Sites pour accéder au Management Server.

clip_image004

 

Jusque-là, rien de bien compliqué. C’est trop simple me direz-vous? OK, corsons un peu la chose.

clip_image005

 

Avant d’aller plus loin, on va voir ce que cela a changé du point de vue de Windows Azure Pack avec une plongée dans le monde obscur des Resources Providers avec un peu de PowerShell. Je sais déjà qu’il se nomme Webspaces :

Import-Module MgmtSvcAdmin

$SecurePassword = ConvertTo-SecureString « ******** » -AsPlaintext -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList « Administrator@Windowsazurepack.lan »,$SecurePassword

$AdminAPIInfos = Get-MgmtsvcFQDN -NameSpace AdminAPI -Server SQL.WINDOWSAZUREPACK.LAN

$AdminURI = « https://$($AdminApiInfos.FullyQualifiedDomainName):$($AdminApiInfos.Port)« 

$WindowsAuthSite = Get-MgmtSvcFQDN -Namespace WindowsAuthSite -Server SQL.WindowsAzurepack.Lan

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

$Token = Get-MgmtsvcToken -type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm « http://azureservices/AdminSite » -User $Cred

$AllRps = Get-MgmtSvcresourceProvider -IncludeSystemresourceProviders -AdminUri $AdminUri -Token $Token

$AllRps | Where {$_.name -eq « webspaces »}

clip_image006

 

On découvre bien que nous avons bien un nouveau Resource Provider nommé « Webspaces ». Détaillons un peu sa configuration avec une petite commande PowerShell supplémentaire :

$AllRps | where {$_.name -eq « webspaces »} | Select Name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}},@{e={$_.NotificationEndpoint.ForwardingAddress}}

clip_image007

 

Si vous vous souvenez des autres Resources Providers, il y avait une même URL avec des ports distincts. Avec l’architecture Web Sites, c’est bien plus simple puisque qu’un seul Web Service gère tous les aspects (portail utilisateur, portail administration, mesure des usages, notification). Revenons dans le portail d’administration de notre Windows Azure Pack. On peut constater que via le rôle Management, nous sommes en mesure de piloter le contrôleur de l’architecture Web Sites, voire même de déclarer d’autres rôles.

clip_image008

 

Toutes les commandes dont nous disposions dans la console MMC sont ici aussi disponibles dans le portail d’administration de Windows Azure Pack. Par exemple, on peut ajouter un nouveau rôle Web-Worker.

clip_image009

 

Pour changer, on va mettre en œuvre une instance Reserved de taille Small.

clip_image010

 

Immédiatement, le déploiement commence. Par contre, comme nous l’avons déjà vu, il y a beaucoup de travail derrière.

clip_image011

 

Dans l’onglet Web Sites, on n’a pas grand-chose. C’est normal, nos locataire ne peuvent pas encore souscrire à ce service. Dans l’onglet Configure, on retrouve des éléments que nous avons déjà configuré lors de la mise en œuvre de l’architecture Web Sites. Cependant, il manque certains éléments. Le premier d’entre eux, c’est le certificat *.websites.windowsazurepack.fr utilisé par défaut par tous les sites web qui seront hébergés. Nous l’avons mise en œuvre sur les instances du rôle Font-End (il était exportable avec sa clé privée). Nous devons le déclarer au niveau de Windows Azure Pack.

clip_image012

 

C’est nécessaire car ce certificat sera mis en œuvre pour tous les sites web qui seront provisionnés par les locataires. Nous devons donc fournir le certificat au format PFX (avec la clé privée) ainsi que le mot de passe associé.

clip_image013

 

Nous devons faire de même pour le certificat mis en œuvre pour le rôle Web-Publisher.

clip_image014

 

Pour finaliser la configuration, on va reconfigurer l’URL de publication pour WebDeploy pour forcer l’usage de HTTPS. Pour la sécurité, c’est mieux. On n’oublie pas de cliquer sur le bouton « Save » pour enregistrer la nouvelle configuration.

clip_image015

 

Dans l’onglet Credentials, on retrouve les contextes de sécurité mis en œuvre dans l’architecture Web Sites, comme avec la console d’administration MMC.

clip_image016

 

L’intégration avec Windows Azure Pack n’était pas si compliquée que cela. On approche de la fin. Avant de pouvoir permettre à nos locataire d’utiliser l’architecture Web Sites, nous devons créer le plan quel le locataire pourra souscrire. C’est l’objet du prochain billet.

 

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

Software-Defined Storage Design Calculator

Avec la génération Windows Server 2012 / 2012 R2, Microsoft a introduit une nouvelle approche du stockage (qui se poursuivra dans Windows Server 2016) basé sur du JBOB et mis en avant avec les fonctionnalités suivantes :

  • Shared Cluster Volume
  • Scale-Out File Server
  • Storage Pool
  • Storage Spaces

Le tout avec une pointe de tiering SSD pour un stockage bien frappé. Cette nouvelle approche du stockage manquait d’information quant à son design. On dispose maintenant d’un Software-Defined Storage Design Calculator, un peu comme le Storage Calculator pour Exchange. Au moment où j’écris ce billet, c’est déjà la version 1.1 qui est disponible. Logiquement, il est très orienté pour les charges applicatives hébergées sous Hyper-V. Pour commencer, nous devons commencer par causer matériel. Cela implique de :

  • Choisir un template (Pour info le 4 nœuds * 4 châssis, c’est l’architecture stockage de CPS qui envoie du poney)
  • Estimer la consommation en pic de la charge applicative que l’on va héberger
  • Estimer la consommation moyenne de la charge applicative que l’on va héberger
  • Fournir les informations concernant le stockage (nombre de disques, capacité brute, nombre de tiroirs, contenu des tiroirs, …)

clip_image001

Note : Attention, avant de commencer, assurez-vous de disposer de la dernière version du fichier disponible à cette adresse.

Vous disposerez d’une première estimation qu’il faudra affiner avec votre fournisseur favori. A un moment, il faudra valider les hypothèses de calcul et se confronter à la réalité. Pour cela, une bonne adresse à conserver : Server and Storage I/O Benchmarking and Performance Resources. Y a tout ce qu’il faut pour casser du disque. Pour finir quelques conseils :

  • Attention à la taille des clusters pour le formatage
  • Attention aux optimisations matérielles réseau
  • Un antivirus sur un Hyper-V ca peut être fatal avec le SCV. Chaque nœud du cluster peut scanner le même fichier

 

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

Architecture Windows Azure Pack WebSites – Etape n°3 : Mise en place du rôle Web-Worker

Derrière le Font-End, se trouve le Web-Worker. Dans mon architecture, toutes les instances de ce rôle sont localisées dans une zone réseau dédiée. Aucun besoin qu’elles soient exposés sur Internet.

clip_image001

 

Dans une infrastructure Web Sites, nous savons déjà qu’il y a deux types de Web-Worker :

  • Dedicated
  • Shared

La différence tiens au niveau de l’isolation entre les locataires. Avec une instance Shared, plusieurs locataires se partagent une même instance du rôle Web-Worker. L’isolation est assurée par Internet Information Services en isolant chaque locataire dans un site web dédié. Avec une instance Dedicated, c’est beaucoup plus simple puisque le serveur web est dédié à un unique locataire. C’est un choix que nous allons pouvoir proposer à nos locataire.

On va commencer par provisionner une instance Shared depuis la console Windows Azure Pack Web Sites. l’instance Web-Worker reposera sur une machine virtuelle avec les caractéristiques suivantes :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • Présence du certificat *.Websites.Windowsazurepack.fr (avec clé privée)
  • UAC : Désactivé
  • Compte WAP\FT-WAP-WEB02 membre du groupe local administrators

Quelques règles de pare-feu entrantes :

  • Protocole « Windows Management Instrumentation (WMI-In) »
  • Protocole WINRM (HTTP TCP 5985)
  • Protocole WINRM (HTTPS TCP 5986)
  • Protocole Web Farm Framework Agent (TCP 8173)
  • Protocole Dynamic WAS Service (TCP 8676)
  • Protocole « Worker Management Endpoint » (TCP 456)
  • Protocole HTTP

 

Note : Selon les informations issues de l’article Capacity Planning for Windows Azure Pack: Web Sites, il faut considérer que :

  • Le système va consommer au minimum 1.2Go de mémoire vive, le reste étant dévolu aux Web Sites
  • La pagination est à proscrire
  • Seulement 5% des sites web sont actifs à l’instant T, seuls eux consomment
  • Le nombre de sites web hébergés ne doit pas dépasser 20 fois le nombre de sites web actifs
  • La consommation moyenne d’un site web est de 70Mo
  • La quantité de mémoire nécessaire pour héberger se calcule selon la formule suivante : Number of Provisioned web sites * 70MB * 5% – (Number of Web-Worker Roles * 1044 MB)
  • La recommandation est d’avoir au minimum deux instances du rôle Web-Worker en mode Shared

 

C’est maintenant que cela commence à se compliquer. Jusqu’à maintenant, on savait que le rôle Web-Worker pouvait être Shared ou Dedicated (Reserved). C’est une question de sizing. On va commencer petit joueur et déclarer une instance Shared. Depuis la console Microsoft Azure Pack Websites nous allons demander le déploiement de notre première instance de Web-Worker.

clip_image002

 

Vu la liste de composants à installer, on comprend que le processus va être relativement long : clip_image003

 

Comme pour les rôles précédents, le contrôleur met à disposition le fichier XML ainsi que le repository préalablement téléchargé. Après avoir installé et configuré tous ces composants, notre instance du rôle Web-Worker va redémarrer et s’annoncer comme opérationnelle (Si au moins une instance du rôle Front-end est opérationnelle). A la fin, la console Windows Azure Web Sites doit ressembler à l’illustration ci-dessous :

clip_image004

 

Note : Si aucune instance du rôle Font-end n’est opérationnelle, l’ajout d’une instance du rôle Web-Worker fonctionne mais elle ne démarre pas. C’est normal, c’est le rôle Font-end qui est chargé de fournir un certain nombre d’informations pour finaliser la configuration.

 

Un peu de PowerShell pour la fin histoire de vérifier que notre rôle est bien provisionné.

Get-WebSitesServer | Where {$_.role -eq « WebWorker » }|Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image005

 

Ça nous fait une seule instance pour le rôle Web-Worker. Or, il nous faut une seconde instance afin de pouvoir proposer le service en haute disponibilité. j’ai donc préparé un serveur supplémentaire pour notre seconde instance. Un peu de PowerShell et c’est joué.

New-WebSitesServer -Name webworker02.windowsazurepack.lan -ServerType « WebWorker »

clip_image006

 

Note : Ce n’est pas précisé mais c’est bien une instance Shared qui a été mises en œuvre. La variable « IsDedicated » est à False.

 

On peut constater que l’installation est en cours avec la commande PowerShell suivante :

Get-WebSitesServer | Where {$_.Name -eq « webworker02.windowsazurepack.lan »}

clip_image007

 

Après un peu de patience et un reboot, une nouvelle exécution de la commande « Get-WebSitesServer | Where {$_.role -eq « WebWorker » }|Select Name, Status, PlatformVersion | Format-Table -Autosize », nous indique la disponibilité de deux instances deux instances du role WebWorker opérationnelles.

clip_image008

 

Pourquoi avoir deux instances du rôle Web-Worker me direz-vous? Pour le vice? Aussi, mais c’est surtout pour la disponibilité et gérer les domaines de panne de notre infrastructure. En cas d’indisponibilité d’une des deux instances, il est facile de déplacer les sites web sur l’instance restante et de rediriger les requêtes entrantes depuis les instances du rôle Front-end. C’est pratique lorsqu’on va patcher / reconstruire une instance, voire procéder à la mise à niveau de l’architecture Web Sites. On sera en mesure de procéder en Rolling-upgrade sans interrompre le service.

 

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

Architecture Windows Azure Pack WebSites – Etape n°2 : Mise en place du rôle Front-End

Le rôle Font-end, est positionné en frontal de l’architecture Web Sites. Sa fonction , sera de router les requêtes des clients vers la bonne instance de Web Worker rôle en s’assurant que celle-ci soit effectivement fonctionnelle. Le rôle assure aussi fonction de Load-Balancer. Notre instance du rôle Font-end seront mise en place dans une zone réseau dédiée, ayant accès à Internet, directement exposés ou via des solutions de type reverse-proxy / équilibrage de charge.

clip_image001

 

L’astuce, c’est l’enregistrement CNAME que nous avons créé dans la zone DNS websites.Windowsazurepack.fr. Pour rappel, quel que soit le nom pour lequel la résolution DNS est demandée, la réponse sera toujours la même : Webfrontend.Windowsazurepack.Fr.

Resolve-DNSName -Name toto.websites.windowsazurepack.fr -DnsOnly

clip_image002

 

Pour cela, il utilisera le module Application Request Routing (ARR) bien connu de IIS. Le rôle agit donc aussi comme un répartiteur de charge. Avant, cela, on va avoir besoin d’un certificat un peu particulier pour le domaine DNS par défaut configuré de notre infrastructure Web Sites : Websites.WindowsAzurePack.Fr. C’est un certificat wildcard qui devra être délivré par une autorité de certification reconnue par nos futurs locataires qui devra en plus être exportable. Nous devrons le mettre en œuvre sur toutes les instances de notre rôle Frond-end ainsi que de le fournir à Windows Azure Pack.

Une fois le certificat installé sur notre serveur, on doit le retrouver dans le magasin personnel de notre serveur avec un peu de PowerShell :

Get-ChildItem Cert:\Localmachine\My | Where {$_.friendlyName -eq « Certificate for Default Domain »} | Format-List

clip_image003

 

Si c’est pas déjà fait, on l’exporte (avec sa clé privée), vous reprendrez-bien un peu de Powershell?

$Password = ConvertTo-SecureString « ******** » -Force -AsPlaintext

Get-ChildItem Cert:\Localmachine\My | Where {$_.friendlyName -eq « Certificate for Default Domain »} | Export-PFXCertificate -FilePath C:\Temp\DefaultDomain.PFX -Password $Password

clip_image004

 

Le certificat en place, nous pouvons commencer la mise en œuvre de notre première instance du rôle Frond-End. Pourquoi commencer par lui? Car si on commence par, le rôle Web-Worker, il ne démarrera que lorsqu’au moins une instance du rôle Front-end aura démarré. Donc, un Frond-End, c’est :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Compte « WAP\FT-WAB-WEB01 » membre du groupe local administrators
  • Le certificat *.sites.windowsazurepack.fr
  • Quelques règles de pare-feu entrantes :
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole HTTP
    • Protocole HTTPS
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole « Certificate Sync Service » (TCP 1233)

 

Note : Selon les informations issues de l’article Capacity Planning for Windows Azure Pack: Web Sites, il faut considérer que chaque cœur consommé par une instance du rôle Font-end est capable traiter 100 requêtes par seconde. Il est donc intéressant d’avoir plusieurs instances de ce rôle avec de l’équilibrage de charge en amont.

Il est possible de réaliser l’opération directement depuis le portail d’administration de Windows Azure Pack, mais je préfère réutiliser la console Windows Azure Pack Web sites. L’avantage, c’est qu’on a directement les logs sous la main pour traiter les éventuels problèmes. En plus, on a plein de commandes Powershell à tester.

clip_image005

 

La liste des produits à installer sera fournie par le contrôleur de l’infrastructure Web Sites. Dans la liste des composants, que du classique avec des choses attendues tel que URL Rewrite et Application Request Routing. Pourtant l’un d’entre eux a attiré mon attention : CertSynchronizationService.

clip_image006

 

C’est un composant magique car, il va nous permettre de prendre en charge l’utilisation de certificats SSL en frontal, le support des SNI et plus généralement le support des certificats que nos locataires vont associer à leurs sites web. Ça promet du lourd à la mise en œuvre. Une fois le processus mené à son terme, le serveur aura automatiquement redémarré et la console Windows Azure Web Sites devrait ressembler à l’illustration ci-dessous :

clip_image007

 

On peut vérifier que notre rôle est bien opérationnel. Subtilité, en Powershell avec la commande Get-WebSitesServer que nous utiliserons depuis notre instance du rôle contrôleur. Une seule subtilité : il se nomme « LoadBalancer » et non « Publisher » : Get-WebSitesServer | Where {$_.Role -Eq « LoadBalancer »}|Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image008

 

Pour être plus précis, il faut parcourir les logs de l’architecture Web Sites avec la commande Get-WebSitesEvent, et plus particulièrement les évènements compris entre 7775 et 7778 inclus.

Get-WebSitesEvent -ComputerName Webfrontend.Windowsazurepack.lan | Where {($_.MessageID -ge 7775) -And ($_.MessageID -le 7778)}

clip_image009

 

Là, je suis assuré que mon instance du rôle Font-End a effectivement démarrée. Notre infrastructure commence à prendre forme. Prochaine étape, le rôle Web-Worker. On va enfin parler de sites Web.

La séance de torture vous plait? Bien. On passe au plat de résistance.

 

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

Architecture Windows Azure Pack WebSites – Etape n°1 : Mise en place des rôles Controller, Management, File Server

La mise en bouche vous a plu? Tant mieux. Maintenant on entre dans la salle de torture. Ça va devenir fun ou pas, c’est selon votre sensibilité. Les rôles contrôleur, Management et File Server constituent le socle d’une infrastructure Web Sites. C’est donc logique de commencer par eux.

Commençons avec le contrôleur. Nous allons l’installer sur un serveur dédié. On va passer beaucoup de temps avec puisque c’est lui qui va provisionner l’intégralité de l’infrastructure Web Sites. Pour sa mise en œuvre, la liste des prérequis est la suivante :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole WebDeploy (TCP 8172)
    • Protocole Web Farm Service (TCP 8675)

Note : Une infrastructure Web Sites ne peut avoir que deux contrôleurs, un primaire et l’autre secondaire.

Pour installer notre rôle contrôleur, nous allons utiliser le Web Platform Installer que nous connaissons déjà. Dans sa version actuelle, c’est un package nommé Windows Azure Pack Web Sites V2 update 6.

clip_image001

 

C’est une installation dès plus simple (package Windows Installer). On n’a plus rien à faire avec le Web Platform Installer.

clip_image002

 

Maintenant, c’est le package Windows Installer qui prend la main. Le processus d’installation propose deux scénarios de déploiement :

  • Déploiement du rôle contrôleur en utilisant les packages disponibles sur Internet
  • Déploiement du rôle contrôleur en utilisant un repository de packages préalablement téléchargés

Le second scénario de déploiement est adapté aux environnement ou l’accès Internet est limité, comme on peut le faire avec le Web Platform Installer. Ce scénario permet aussi de conserver la maitrise de l’architecture. L’installation de tous les rôles sera réalisée en utilisant le repository. Quand on sait que l’architecture Web Sites de Windows Azure Pack repose sur un grand nombre de composants, il est intéressant de bien maitriser le cycle de mise à jour de chacun d’entre eux. Il faut comprendre que l’architecture Web Sites dispose de son propre mécanisme de mise à niveau pour s’assurer que chaque rôle est bien installé avec la dernière version chaque composant disponible. Pour la majorité des rôles, plusieurs instances d’un même rôle peuvent exister dans une architecture. Pendant que certaines sont actives, les autres peuvent être en maintenance, mise à niveau voire même s’auto-réparer.

Dans le contexte de ce billet, nous allons faire simple et réaliser l’installation du rôle contrôleur en téléchargeant les sources directement depuis Internet.

clip_image003

 

Je fais l’impasse sur l’accord de licence et on se retrouve avec la liste des composants de l’architecture qui seront téléchargés. La liste est longue, très longue, il y en a presque pour un giga-octets, donc patience.

clip_image004

 

Au fur et à mesure de la progression de l’installation, nous avons le répertoire « c:\HostingOfflineFeed\Installers » qui se remplit avec les binaires nécessaires. Il y a plein de choses que nous connaissons car en provenance de IIS mais aussi des composants non Microsoft (PHP, …).

clip_image005

 

Après avoir créé le repository local, le Setup va mettre en œuvre notre nouvelle architecture.

clip_image006

 

L’architecture Web Sites est totalement indépendante de Windows Azure Pack. Avant de pouvoir référencer le « Resource Provider », il reste beaucoup de travail. Le rôle Controller est au cœur de l’architecture Web Sites. Il a pour rôle de :

  • Gérer l’architecture Web Sites
  • Provisionner les autres rôles de l’architecture
  • Orchestrer la mise à niveau des différents rôles
  • Gérer les Web Sites mis à disposition des locataires

 

Dans notre situation, nous allons installer notre contrôleur primaire. Il sera tout à fait possible de lui adjoindre un contrôleur secondaire plus tard. A l’instant T, un seul contrôleur « primaire » assure la gestion de l’infrastructure Web Sites.

clip_image007

 

Pour mettre en place notre rôle Contrôleur, c’est aussi mettre en place le rôle File Server. Il est possible de référencer un serveur /cluster de fichiers préalablement configuré ou de laisser notre contrôleur configurer un serveur prévu pour ce rôle. La seule limite est qu’il n’est pas possible d’utiliser un Scale-Out File server (Le rôle File Server Resource Manager qui sera installé n’est pas compatible avec les clusters Scale-out File server).

Pour faire simple, nous allons laisser le programme d’installation nous configurer notre serveur de fichiers. Réutiliser un serveur de fichiers existant implique qu’on mette en place la structure de répertoire, les partages et permissions NTFS par nous-même tel que documenté par l’article Technet « Pre-configure a Windows File Server Cluster or NAS device for Windows Azure Pack: Web Sites« .

clip_image008

 

Ces premiers choix fait, on peut passer à la configuration du rôle contrôleur.

clip_image009

 

Première étape, c’est de désigner une base de données pour le rôle Web Sites Cloud ainsi que pour la mesure des usages. Pour des raisons de sécurité, il est recommandé de dédier une instance SQL distincte pour ces bases de données. Pour une plateforme de développement, il est tout à fait possible de localiser ces bases de données avec celles de Windows Azure Pack, c’est ce que j’ai fait. D’un point de vue réseau, cela se limite au port TCP 1433 (ou celui utilisé pour installer l’instance SQL Server).

clip_image010

 

Note : Attention à bien vérifier que le programme d’installation a bien créé les deux bases de données lors de l’installation. Lors de la mise en œuvre sur ma maquette, je suis tombé sur un cas ou la base de données de mesure des usage était annoncée comme créée alors que cela ne l’était pas, ce qui a bloqué la suite du processus de déploiement de certains rôles.

Une fois les bases de données crées, on peut passer à la phase de configuration des paramètres systèmes.

clip_image011

 

Dans Microsoft Azure, lorsqu’on demande la création d’un Web Sites, celui-ci est référencé dans la zone DNS « AzureWebsites.Net » gérée par Microsoft. Il est possible de configurer un domaine personnalisé, si on est capable de prouver que nous en sommes bien les propriétaires (capable de créer des enregistrements DNS bien spécifiques). Avec l’architecture Web Sites, c’est presque le même principe, sauf que nous avons le choix du domaine public. J’ai créé un sous-domaine « websites.windowsazurepack.fr » qui contient les enregistrements DNS attendus.

clip_image012

 

L’astuce, c’est que l’on va exploiter un enregistrement DNS dit « Wildcard » pour traiter toutes les demandes de résolution DNS pour ce sous-domaine et rediriger le trafic vers les instances du rôle Font-End pour routage vers l’instance Web Worker appropriée. Si on essaie de résoudre n’importe quel nom DNS dans cette zone, on voit bien que la réponse est toujours la même : le rôle Front-End.

Resolve-DNSname -Name toto.websites.windowsazurepack.fr

clip_image013

 

Tous les produits Microsoft proposent une option pour se mettre à niveau via Windows Update. Avec l’architecture Web Sites, c’est un peu plus compliqué. Sur chaque serveur de l’infrastructure, un service « Web Sites update service » est chargé de maintenir le rôle à niveau. Le rôle contrôleur met à disposition un fichier XML à l’Url suivante : http://{controller}/HostingOfflineFeed/Feeds/latest/originalfeeds/WebSites<Version>.XML. Celui-ci référence pour chaque package la version associée. Chaque instance est donc à même de détecter lui-même que un ou plusieurs packages doivent être mis à niveau.

clip_image014

 

L’architecture Web Sites de Windows Azure Pack nous propose de configurer nos rôles pour se mettre à niveau automatiquement. Cela inclus aussi bien les packages de mise à niveau ou les nouvelles fonctionnalités de l’architecture Web Sites. Si on dispose de plusieurs instances pour chaque rôle, cela ne pose pas de problème particulier. Le contrôleur réalisera les mises à niveau progressivement, sans perturber le service. Par contre, sur une plateforme de POC / Développement, il peut être opportun de ne pas activer la mise à niveau automatique pour gérer la maintenance de l’infrastructure Web Sites mais aussi pour garantir la stabilité de la plateforme en terme de version de composants mis à disposition pour les sites web.

clip_image015

 

On rentre dans une section intéressante. L’architecture Web Sites de Windows Azure Pack exploite plusieurs contextes de sécurité. Pour chacun d’entre eux, on peut configurer un compte local ou un compte de domaine. C’est ce qui fait que les serveurs de notre architecture Web Sites peuvent tout aussi bien être installés en Workgroup ou domaine. Personnellement, j’ai fait le choix de raccorder mon infrastructure Web Sites au domaine, on utilisera donc des comptes de services.

clip_image016

 

On commence avec le compte de service qui sera utilisé pour réaliser le provisioning du reste de l’infrastructure Web Sites de Windows Azure Pack. Cela concerne une liste de rôles bien définie :

  • Front-end
  • Publisher
  • Management
  • File Servers

 

Il est possible d’utiliser un compte local pour tous ces rôles mais c’est quand même plus simple d’utiliser un compte de domaine. J’ai donc créé le compte « WAP\FT-WAP-WEB01 » qui sera positionné comme membre du groupe local administrators pour les rôles cités ci-dessus. Dans la console Windows Azure Pack Web Sites, nous n’avons qu’à référencer le compte de service à utiliser ainsi que son mot de passe.

clip_image017

 

Vous avez certainement remarqué que le rôle Web Worker n’était pas dans la liste précédente. C’est logique, il dispose de son propre compte de service, que ce soit pour le Web Worker dedicated ou Shared. J’ai donc créé le compte « WAP\FT-WAP-WEB02 » qui sera positionné comme membre du groupe local administrators sur les futurs serveurs qui hébergeront les instances du rôle Web Worker.

clip_image018

 

Passons au rôle File Server de l’architecture. Il nécessite deux comptes de services car on distingue :

  • Le contexte utilisé pour gérer l’infrastructure Web Sites
  • Le contexte utilisé par les Web Worker Role pour venir récupérer le contenu du site web

 

Pour le premier contexte, j’ai donc créé le compte de service « WAP\FT-WAP-FSO » qui est positionné comme membre du groupe local « Administrators » de toutes les instances du rôle File Server.

clip_image019

 

Pour le second contexte, ce sera le compte « WAP\FT-WAP-FSU ». Pour ceux qui ont suivi les recommandations « Pre-configure a Windows File Server Cluster or NAS device for Windows Azure Pack: Web Sites » pour configurer les permissions de partage et NTFS, c’est un compte qui ne peut que lire le contenu des partages sur les instances du rôle File Server.

clip_image020

 

Il ne nous manque plus qu’une identité. C’est celle sous laquelle sera réalisé le référencement de l’infrastructure Web Sites dans Windows Azure Pack via ses API Rest.

clip_image021

 

Pour continuer, un serveur devra avoir été mis en place pour le rôle File Server avec les prérequis suivants :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Le compte « WAP\FT-WAP-FSO » positionné comme membre du groupe local administrators
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)

 

Le rôle File Server, permet de stocker le contenu des sites web de nos locataires. Dans le contexte d’un POC simple, j’avais retenu une configuration simplifiée. C’est donc le processus d’installation qui va configurer les permissions.

clip_image022

 

Dernière étape, désigner notre Management Server pour que celui-ci puisse être l’interface avec Windows Azure Pack. Ici encore, c’est un serveur dédié avec les prérequis suivants :

  • Socle : Windows Server 2012 R2 de préférence raccordé au domaine
  • Rôles & Fonctionnalités : Framework Dot.Net 3.5.1 installé (attention, y a un piège)
  • UAC : Désactivé
  • Quelques règles de pare-feu entrantes :
    • Protocole « File and printer Sharing (SMB-IN)
    • Protocole « Windows Management Instrumentation (WMI-In) »
    • Protocole WINRM (HTTP TCP 5985)
    • Protocole WINRM (HTTPS TCP 5986)
    • Protocole Web Farm Framework Agent (TCP 8173)
    • Protocole Web Deploy (TCP 8172)
    • Protocole HTTP
    • Protocole HTTPS

clip_image023

 

C’est maintenant que la magie commence, lorsqu’on appuie sur le bouton Start.

clip_image024

 

En démarrant, notre contrôleur dispose de toutes les informations pour mettre en place sa propre configuration ainsi que déployer et configurer les rôles File-Server et Management. En consultant sa base de données, il va découvrir que la configuration de ces deux rôles n’a pas encore été réalisée. Il va donc procéder à leur installation. Pour le rôle Management, la liste des composants à installer est relativement courte :

clip_image025

 

Pour le rôle File Server, la liste est nettement plus courte. Si on exclus HostingFile (le file File-Server), l’autre ne nous sont pas inconnus puisque c’est tout simplement le rôle Windows File Server et le sous-rôle File Server Resource Manager.

clip_image026

 

Note : Depuis l’update 6 de la version 2.0, l’architecture Web Sites n’utilise plus de partage pour stocker les certificats des utilisateurs. C’est le service « Certificate Sync Service » présent sur les instances du rôle Font-end qui se charge de stocker ces certificats et de les mettre en œuvre.

Note : Le Scale-Out File Server est incompatible avec le rôle File Server Resource Manager. De ce fait, il n’est pas possible d’utiliser un Scale-out File Server pour héberger notre rôle File Server. Nous devons nous contenter d’un cluster de fichiers à l’ancienne.

Une fois le processus d’installation terminé, on peut constater la configuration suivante dans la console Windows Azure Pack Web Sites.

clip_image027

 

Ce qu’il faut retenir, c’est que notre contrôleur est chargé de réaliser les déploiements mais aussi de fournir les moyens pour que chaque rôle puisse réalise sa mise à niveau / réparation.

Je pouvais pas finir ce billet sans un peu de PowerShell. L’architecture Web Sites dispose de son propre module PowerShell que l’on peut utiliser sur le rôle contrôleur.

Import-Module WebSitesDev

(get-Command -Module WebSitesDev).Count

clip_image028

 

A quand même! 195 commandes, c’est tout un univers. Pour l’instant, une seule nous intéresse :

Get-WebSitesServer | Select Name, Status, PlatformVersion | Format-Table -Autosize

clip_image029

 

Donc à ce stade, nos trois rôles sont opérationnels. Nous avons le socle de notre infrastructure Web Sites. prochaine étape, le rôle Front-End.

 

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

Créer un trust unidirectionnel en Powershell facile non? (republication)

Le jour où j’ai vu Windows Core la première fois, je me suis dit que ce sera parfait quand toutes les applications Microsoft seront compatibles avec. C’était au moment des premières Beta de Windows 2008. Aujourd’hui avec Windows Server 2012, on peut dire que le rêve est devenu réalité, les principales applications Microsoft sont maintenant utilisables sur plateforme Windows sans interface graphique ou presque, …

Cette vision serait même parfaite si on pouvait tout administrer depuis un langage unifié : PowerShell. Pourquoi dis-je serait? Avec Windows Server 2012 et Power ShellPowerShell V3 on peut tout faire en PowerShell? Y a donc forcément une commande PowerShell pour créer un trust dans le commandlet ActiveDirectory?

Et là, c’est le drame. Recherche rapide sur le Technet pour découvrir que dans PowershellV3, il n’y a qu’une seule commande en relation avec les relations d’approbation : Get-ADTrust, nada pour en créer ou les gérer. Etrange mais pas dramatique, il reste la méthode “Old school”. On peut encore se rabattre sur le vieux NETDOM.EXE, faudra juste parser son retour pour savoir si la commande s’est bien déroulée. Bizarrement, ça se passe pas comme prévus (ça marche pas), et pour cause, l’aide de la commande “NETDOM.EXE” est très claire :

clip_image002

 

Même Microsoft recommande d’utiliser l’interface graphique, c’est un comble. A ce stade, ça se corse car je dois effectivement mettre en place une relation d’approbation entre deux forêts. Donc exit la méthode “Old School”. Va falloir ruser.

PowerShell, c’est aussi Dot.Net. Je passe donc du côté obscur de l’IT et me plonge dans le MSDN à la recherche d’une solution. Oh miracle, il existe une méthode Forest.CreateTrustRelationship. Il faut juste pouvoir l’appeler en PowerShell. Après quelques tâtonnements, cela donne cela :

clip_image004

 

Concrètement, je me positionne sur un contrôleur de domaine du domaine approuvant pour exécuter ce script et cela va automatiquement mettre en place ma relation d’approbation unidirectionnelle dans les deux domaines :

clip_image006

 

On peut vérifier dans le domaine approuvé avec la commande Powershell Get-ADTrust (il faut bien qu’elle serve à quelque chose) et on obtient le résultat ci-dessous :

clip_image008

 

La relation d’approbation unidirectionnelle entre mes deux forêts est donc opérationnelle.

Conclusion, Windows Core, c’est bien, Powershell aussi mais pour pouvoir réellement se passer des outils d’administration classiques, il faudra encore attendre car sur un serveur Windows Server 2012, on a bien l’aide de Powershell (si on a pensé à la télécharger dans son intégralité) mais il n’y a pas d’équivalent pour avoir le MSDN de la même manière.

Simple and Secure by design but Business compliant.

Publier une PKI sur Internet (republication)

En lisant le billet de mon collègue Alexandre GIRAUD sur le processus de demande de certificats pour IIS 7.0, je me suis rendu compte que souvent, nos clients ont besoin de certificats mais sont rebutés par la mise en œuvre. Une des principales problématiques se situe au niveau de la publication des listes de révocation à l’extérieur de l’entreprise. Si un système d’exploitation n’est pas capable de télécharger les listes de révocation, il ne peut déterminer si un certificat donné est toujours valable ou non. Or, il y a de plus en plus de scénarios (Windows, Exchange 2007, SCCM 2007, SCOM 2007, …) qui nécessitent la mise en œuvre d’une PKI.

 

Avertissement

Attention, ce billet n’est pas censé se substituer à une réelle mise en œuvre d’une infrastructure PKI. C’est juste un raccourci pour couvrir un certain nombre de scénarios et répondre uniquement au besoin technique (obtenir des certificats), l’aspect fonctionnel est volontairement négligé. L’aspect technique a lui aussi été épuré. Je renvoie donc les puristes vers le “Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure” ainsi que  l’indispensable référence sur la PKI Microsoft : Windows Server 2008 PKI and Certificate Security de l’immense Brian Komar.

Donc ce qui va suivre est volontairement une forme simplifiée de mise en œuvre de PKI. J’espère que les puristes ne m’en voudront pas.

 

Installation du rôle ADCS

Pour la majorité de nos besoins en certificats, nous avons besoins d’une autorité de certification intégrée à l’annuaire Active Directory (le scénario NAP IPSEC par exemple repose sur une autorité de certification autonome).

Mais alors pourquoi installer le rôle “Certification Authority Web Enrollment”? D’une part, on pourrait en avoir besoin pour certains scénarios, d’autre part, cela m’évite de créer un fichier “CAPOLICY.INF” pour personnaliser la mise en œuvre de mon autorité de certification.

clip_image001

 

Comme indiqué plus tôt, mon choix se porte une une autorité de type “Entreprise”, donc intégrée à l’annuaire Active Directory. On en verra les conséquences plus tard dans ce billet. Pour ceux qui veulent se faire mal, il peuvent consulter le WebCast de François LASSERRE des TechDays 2009.

clip_image002

 

Pour la notion de hiérarchie, on va faire très simple, un seul niveau, donc RootCA.

clip_image003

 

Toujours pour simplifier, je nomme mon autorité de certification RootCA.

clip_image004

 

Pour le chemin de la base de données de l’autorité de certification ou son journal de transaction, je conserve les choix par défaut.

clip_image005

 

Le résumé nous présente la liste des modules de IIS. Les choix proposés me conviennent parfaitement pour l’autorité racine, puisque c’est le choix minimum pour notre cas, donc secure!

clip_image006

 

Une fois l’installation terminée, on peut constater que notre PKI est bien opérationnelle et que ses informations sont publiées mais uniquement localement. La CRL est uniquement publiée dans un chemin HTTP.

clip_image007

 

Jusque là tout va bien. C’est simple finalement la PKI?

Optionnellement, on va configurer l’enregistrement et le renouvèlement automatique de certificats dans la stratégie de groupe “Default Domain Policy”. Ceci permettra aux systèmes d’exploitation clients ainsi qu’aux utilisateurs d’obtenir des certificats automatiquement.

clip_image008

 

Personnaliser les extensions

C’est par là que tout passera. Un raccourci pourrait consister à publier les URL de l’AIA et de la CRL avec ISA Server ou son successeur mais, du pointe de vue de la sécurité, c’est pas terrible. On va donc ajouter les extensions pour publier l’AIA et la CDP sur un serveur tiers que l’on pourra lui publier via ISA Server vers l’extérieur.

clip_image009

 

On constate maintenant la raison de mon choix d’installer le “Certification Authority Web Enrollment”. Si je ne l’avais pas installé, l’installation par défaut du rôle ADCS aurait du être corrigé pour ne pas publier l’AIA et la CDP sous forme HTTP. Il aurait été nécessaire de générer un fichier “CAPolicy.INF”. Je suis en vacances donc, on fait court!

clip_image010

 

Ajoutons notre première extension, à savoir la localisation de notre liste de révocation. Celle-ci devant être accessible d’extérieur, c’est nécessairement un nom pleinement qualifié qui doit être référencé, sous forme d’une URL HTTP. La chaine de caractère illustrée ci-dessous est générique. Elle permet surtout de publier plusieurs listes de révocations à un même emplacement.

clip_image011

 

Note : N’essayer pas de publier en HTTPS surtout avec un certificat issu de votre propre PKI, c’est pas marrant. Comment peut-on vérifier la liste de révocation si on ne peut pas y accéder, on part en boucle!

Subtilité, cet emplacement sera configuré pour stocker les CRL. Par extension, les clients pourront y trouver aussi les CRL “Delta” (qui seront publiées au même emplacement).

clip_image012

 

Voila pour l’accès extérieur mais encore faut-il que notre autorité de certification publie les informations à cet emplacement. Pour cela, on va lui indiquer un chemin UNC (qui correspondra au répertoire virtuel dans IIS) dans lequel l’autorité de certification pourra mettre à disposition les informations nécessaires.

clip_image013

 

Le partage référencé contiendra aussi bien les CRL que les CRL “Delta”.

clip_image014

 

Reste plus qu’à redémarrer le rôle ADCS pour prendre en compte les nouvelles extensions.

clip_image015

 

Voyons voir ce que cela a changé pour l’autorité de certification.

clip_image016

 

On constate qu’il y a bien un nouvel emplacement de publication “externe” pour notre autorité de certifications. Cependant, il ne semble pas opérationnel. A ce stade, c’est normal. Les raisons de cette erreurs sont multiples :

1. La résolution de noms DNS externes n’est peut être pas configurée

2. Le serveur sur lequel on doit publier nos informations n’est pas encore configuré

3. On na pas encore de liste de révocation à publier puisque pas encore de certificats révoqués

 

La résolution de noms externes

Pour que le monitoring de la PKI ne remonte pas d’erreur, il est nécessaire que l’autorité de certification puisse résoudre le nom pleinement qualifié de l’emplacement de publication HTTP. On peut  :

1. Autoriser nos serveurs DNS à joindre les RootHints

2. Configurer nos serveurs DNS pour utiliser des redirecteurs DNS

3. Créer une zone DNS représentant le nom DNS extérieur tel qu’illustré ci-dessous

clip_image017

 

Pour le choix, c’est vous qui voyez!

 

Configuration de la publication

Après l’autorité de certification, passons au serveur sur lequel on va publier les informations. Dans mon cas, j’ai retenu un Windows Server 2008 édition standard. Le choix “full GUI” ou “Core” m’importe peu, cela fonctionne dans les deux cas. Dans ce billet, je ne traiterai que le “Full GUI”, le plus communément

L’autorité de certification va publier dans un partage. Encore faut-il que celui-ci existe? Il sera configuré pour accorder le contrôle total au compte ordinateur de l’autorité de certification.

clip_image018

 

Les informations devant êtres accessibles depuis l’extérieur au format HTTP, nous avons donc besoin d’un serveur web mais uniquement le stricte minimum.

clip_image019

 

Etant donné que je n’ai pas demandé l’installation des outils d’administration de IIS, j’ai quand même besoin d’installer les outils d’administration de IIS en ligne de commande :

clip_image020

 

Notre partage doit disposer des permissions tel qu’illustré ci-dessous (Oups pas core!):

clip_image021

 

Reste plus qu’à créer le répertoire virtuel CRLD tel que déclaré dans l’extension de l’autorité de certification et d’y autoriser le parcours de répertoire (Attention à bien avoir installé les outils d’administration et se positionner dans le sous répertoire %Windir%\System32\InetServ!). La dernière ligne est une subtilité. Elle permet l’utilisation du caractère “+” par le client pour demander la CRL Delta.

clip_image022

 

Pour ceux qui veulent en savoir plus : How to avoid Delta CRL download errors on Windows Server 2008 with IIS7 (Merci Stan!). C’est fini? Nan, par ce que cela ne marche pas encore tout de suite.

 

Dernière passe sur ADCS

On a beau avoir tout mis en place, la console ADCS nous remonte toujours une erreur (Pourquoi tant de haine?).

clip_image023

 

Si on regarde de plus près, un accès HTTP nous retourne l’erreur 404. ce qui signifie que le répertoire est vide.

clip_image024

 

A ce stade, c’est normal, mon autorité de certification n’a pas encore délivré de certificat, donc il n’y a pas eu de révocation, donc pas de liste publiée. Même si la liste est vide, on va quand même demander la publication. Attention, cependant, une liste de révocation reste valide jusqu’à son expiration. La révocation de certificat n’est donc pas instantanée. Pour cela, il faut aller faire un tour du coté de OCSP (Attention, aspirine à prévoir!).

clip_image025

 

Et si tout est opérationnel (veillez à sacrifier une souris au dieux de l’informatique, cela sert toujours), le répertoire doit maintenant être peuplé d’une CRL et une DRL “Delta”.

clip_image026

 

Coté supervision de ADCS, tout est maintenant opérationnel. Notre PKI est maintenant accessible de l’extérieur. Pour finaliser la configuration, une petite publication HTTP avec ISA devrait faire l’affaire.

clip_image027

 

Comment prouver que cela fonctionne?

Bonne question. Une simple commande CERTUTIL permet de demander le téléchargement des CRL et CRLD depuis l’URL extérieure.

clip_image028

 

Conclusion

Ce billet est une réponse technique pour la mise en œuvre d’une PKI pour un besoin “Microsoft”. Cela ne se substitue pas à un réel projet PKI. Je n’ai fait ici qu’effleurer un scénario d’usage de la PKI Microsoft. Les usages des certificats sont très nombreux. l’utilisation des certificats augmentant avec le temps (Windows 2008 R2, Geneva, Exchange 2010?, …), il devient urgent d’intégrer les aspects fonctionnels autour de la sécurité dans nos projets.

Maintenant que c’est aspect a été démystifié, il n’y  plus de raison d’utiliser des certificats pour ADDS, TS Gateway, WINRM, SCVMM, SCOM, SCCM et tout les autres produits qui ne demandent que cela.

Benoîts – Mode Vacances (Pas possible!) + U2 (Yeah!)

SCVMM, un produit qui vous veut du bien (par défaut)

Oui, SCVMM pense à vous les exploitant de cloud privés.. Lorsqu’on l’installe, il vous propose de stocker ses clés de chiffrement directement dans l’annuaire Active Directory de raccordement du serveur. Dans le processus d’installation, ça se passe à ce niveau :

clip_image001

 

Après, certains font le choix de ne pas stocker cette information ultra-sensible dans l’annuaire Active Directory. C’est un choix. Le problème, c’est que c’est un choix qu’on ne fait qu’une seule fois car la clé est soit dans une conteneur dédié dans la partition de configuration de l’annuaire Active Directory, soit c’est stocké localement sur le serveur SCVMM :

HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings.

Après, les « psychorigides » peuvent penser que ce n’est pas assez sécurisé de stocker cela dans l’annuaire Active Directory (un truc de près de 15 an d’âge que l’on retrouve partout dans le monde). Donc, ils stockent l’information localement dans le registre. La vraie question, c’est qu’est ce qui se passe si je perds cette information :

  • VMM inopérant
  • Impossibilité de décrypter les credentials stockées dans la base SCVMM
  • Impossibilité de communiquer avec les agents
  • Services Templates indisponibles

Bref, ne pas stocker la clé de chiffrement dans l’annuaire Active Directory, c’est signer avec son sang que le backup de notre serveur SCVMM a toujours fonctionné et qu’on est capable de retrouver le contenu de la clé de registre.

Après, si vous voulez tester le DRP de SCVMM et vous retrouver avec une infrastructure Cloud privé impossible à gérer, c’est votre choix. Dans ce cas, je vous conseille de prier et tester régulièrement la procédure Restore registry keys, Active Directory objects, and non-VMM managed credentials.

Alors que si l’information est déjà disponible dans l’annuaire Active Directory, une simple réinstallation de SCVMM suffit si votre sauvegarde ne fonctionne pas. Si ce n’est pas déjà fait. Courrez sauvegarder la clé de chiffrement localisé à cet emplacement : HKLM\Software\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings.

 

Sur ce, bonnes vacances.

 

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