Archives mensuelles : décembre 2015

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 troisième remarque aura son importance lorsqu’on arrivera à ADFS et la publication avec le Web Application Proxy. Ce sera donc un sujet sur lequel on reviendra à ce moment.
  • Dans certains pays comme la Suisse, le choix de l’autorité de certification publique sera limité à la liste restreinte des services de certification reconnus selon la loi sur la signature électronique (SCSE)

 

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)