Maintenant que nous en avons fini avec notre autorité de certification racine, attaquons nous à quelque chose de plus consistant, à savoir :

• Notre autorité de certification autonome, subordonnée à RootCA
• Le rôle NPS
• Le Health Registration Authority

 

Setup First

Les éléments précédemment cités étant des rôles, il faudra bien les installer sur le serveur nps.corp.windows2008R2.com. Commençons donc. Sur le serveur on va installer tous les rôles cités :

 

Le fait de cocher la case d’option “Health Registration Authority” va automatiquement nous indiquer qu’il sera nécessaire d’installer un serveur web. Ceci est rendu nécessaire car le HRA est uniquement accessible par les clients sous forme d’URL.

 

Notre HRA doit impérativement être associée à une autorité de certification. Cependant, à ce stade de l’installation, elle n’est même pas encore installée. Il nous fout donc indiquer une configuration ultérieure :

 

Le HRA est capable de traiter les demandes authentifiées en provenance des machines du domaine. Il est aussi capable de traiter les demandes en provenance des systèmes non raccordés au domaine. Les demandes de certificats sont donc anonymes. Ce mode de fonctionnement est très pratique pour les postes en cours de déploiement, qui ne sont pas encore raccordé au domaine :

 

Les URL utilisées  par les clients  peuvent être sécurisées en utilisant le protocole HTTPS. Ceci implique des certificats. Cependant, nous sommes en phase d’installation des rôles. Pour la configuration, on repassera plus tard :

 

Ici encore, l’installation de l’autorité de certification sera complétée par le site web de demande de certificats. L’intérêt est de pouvoir soumettre les demandes sans passer par la console d’administration:

 

Notre autorité de certification secondaire sera de type autonome, ce qui implique que celle-ci n’utilisera pas Active Directory. Par conséquence, il ne sera pas possible de réaliser des demande de certificats automatiques, encore moins des renouvellement. Cela ne nous posera pas de problème puis que le HRA pilotera tout cela :

 

Notre autorité autonome sera de type secondaire, c’est à dire subordonnée à l’autorité de certification principale ROOTCA.

 

Ici encore, le seul choix possible, c’est de créer une nouvelle clé privée.

 

Tous les choix proposés par défaut sont conservés. Dans une implémentation réelle, on aurait réduit la taille de la clé :

 

Notre nouvelle autorité de certification sera nommée NAPCA, indiquant ainsi qu’elle sera dédiée à cette fonction. Dans le cadre de NAP IPSEC, c’est une bonne pratique vu le volume de certificats qui seront générés. Les listes de révocations vont être volumineuses!

 

Le choix fainéant aurait été de réaliser la demande en ligne profitant ainsi de l’enregistrement automatique des demandes de certificats et de la délivrance (puisque l’utilisateur Administrateur que je suis a le droit de demander ce type de certificat). Et bien non, on va illustrer cela à l’ancienne :

 

Pas la peine d’isoler des fichiers en relation avec la base de données, il n’y a pas de séparation des rôles (c’est mal, …).

 

L’installation du serveur Web comprend déjà toutes les options nécessaires, pas la peine d’en rajouter :

 

On arrive à la fin ou presque. Plus qu’une confirmation.

 

Le processus d’installation nous indique que l’installation est techniquement terminée mais pour que l’autorité de certification et le HRA soient opérationnel, il reste du travail :

 

Demander le certificat de l’autorité de certification autonome

Comme j’ai pas voulu être fainéant et stocker la demande de certificat dans un fichier texte, il ne me reste plus qu’à la soumettre à l’autorité de certification RootCA au travers du site web d’enregistrement accessible via l’URL : (pas de HTTPS mais quelle honte. Oui mais toujours en laboratoire, na!). On va donc effectuer une demande de certificat :

 

Une authentification sera nécessaire. A ce stade, seul l’administrateur du domaine peut demander un certificat pour une autorité de certification secondaire (toujours pas de séparation des rôles, tsss!). Ce ne sera pas une demande pour un certificat utilisateur mais une demande avancée :

 

La demande existant déjà sous forme de fichier requête, on va donc soumettre son contenu à l’autorité de certification :

 

Le contenu du fichier de requête (à l’exclusion des marqueurs de début et fin) doit être copié dans la zone de texte prévue à cet effet. Reste plus qu’à sélectionner le gabarit : Subordinate Certification Authority :

 

Oh, miracle! Mon utilisateur est autorisé à soumettre un tel type de demande et à les valider automatiquement. Reste plus qu’à télécharger le certificat :

 

Oui, on télécharge le certificat car il doit être placé dans un magasin spécifique pour être utilisable par l’autorité de certification. En plus, cela permettra de pouvoir le stocker, de préférence dans un endroit sûr.

 

Installer le certificat de l’autorité de certification

Il ne reste plus qu’à installer le certificat en demandant son installation par la console d’administration de l’autorité de certification (Il aurait été possible de réaliser l’opération avec quelques commandes CERTUTIL.EXE mais bon, …).

 

Le certificat installé, si tout est opérationnel, alors il doit être possible de démarrer cette nouvelle autorité de certification :

 

Et effectivement elle fonctionne.

 

Configuration de la politique de la CA autonome

Reste maintenant à la configurer. En premier lieu pour délivrer automatiquement les certificats dès lors que les demandes sont émises par un demandeur autorisé (qui sera le HRA).

 

C’est un paramétrage qui implique un arrêt.

 

Puis un redémarrage le la CA pour être pris en compte.

 

Pour que le HRA soit autorisé, encore faut-il qu’il dispose des permissions suffisantes. Dans notre cas, le HRA est installé sur le même serveur que l’autorité de certification autonome (c’est moche mais on est en laboratoire, pas en production!). On peut donc se contenter de positionner les permissions pour le contexte “Network Service”. Sinon, c’est le compte ordinateur qu’il faut spécifier :

 

Configuration du Health Registration Authority

La configuration du HRA n’était pas complète. En effet il manquait encore auprès de quelle autorité de certification soumettre les demandes :

 

Ainsi que de s’assurer que c’est bien une autorité autonome. Avec Windows Server 2008 R2, on pourrait utiliser une autorité d’entreprise, ce qui permettrait de différencier les certificats pour les demandes authentifiées des celles qui sont anonymes. Ce choix aurait permit d’éviter d’installer une autorité de certification supplémentaire mais j’ai décidé de continuer à dédier mon autorité de certification à ce rôle précis pour raison de volumétrie de la liste de révocation (en plus, je reste compatible avec Windows Server 2008). On remarquera que les certificats générés seront valables seulement quatre heures :

 

Et pour finir avec la PKI, une petite subtilité registre avec la clé de registre indiquant la périodicité selon laquelle les certificats inutiles seront supprimés de la base de données. La valeur par défaut est de cinq minutes :

 

Voila pour l’installation de notre serveur NPS. Ce fut long mais on en a fini avec l’installation. Le prochain billet sera dédié à la mise en œuvre de NAP. Après, on pourra s’attacher à la mise en œuvre des mécanismes d’isolation IPSEC (on va s’éclater, promis!).

 

Benoîts- Simple and Secure by Design

Pour ce troisième billet, entrons dans le vif du sujet avec la PKI. Plus précisément l’autorité racine de confiance intégrée à l’Active Directory dont nous allons avoir besoin. Le principal intérêt d’une autorité racine de de confiance intégrée à l’annuaire Active Directory, c’est que tous les postes du domaine pourront l’utiliser car déclarée comme racine de confiance.

 

Après, ce n’est pas cette autorité de certification qui sera chargée de délivrer des certificats prouvant le bon état de santé des postes de travail. On va devoir dédier une autorité de certification à ce rôle. L’implémentation NAP IPSEC repose sur des certificats, la mise en œuvre ne prévoit pas d’utilisation des listes de révocation. Cela peut paraître étrange mais cela s’explique par deux raisons :

• La durée de vie des certificats délivrés sera relativement courte (en heures)
• Le trafic engendré par la publication et l’exploitation des listes de révocation serait beaucoup trop important

 

Pour ces raisons, une seconde autorité de certification sera donc nécessaire. Elle sera subordonnée à l’autorité racine mais de type autonome. Mais cessons ces digressions et attaquons nous à notre première autorité de certification.

 

Le pré-requis du contrôleur de domaine

Avant de commencer avec la PKI, il nous faut un environnement Active Directory, ce que nous allons faire rapidement avec l’installation du rôle ADDS-Domain-Controller sur le serveur dc.corp.windows2008R2.com :

 

Pour la promotion du contrôleur de domaine, c’est du standard. Le nom de domaine DNS sera Corp.Windows2008R2.com. Pour le mode de domaine, ce sera Windows Server 2008 R2. L’installation se termine avec la configuration du client DNS avec une petite commande NETSH.EXE :

Il faudra penser à déclarer le sous-réseau pour le site Active Directory. Il n’y a toujours pas de commande Powershell pour cela dans Windows 2008 R2. La configuration de la partie contrôleur de domaine se termine par :

• La création de la zone de recherche inverse
• La configuration de “l’aging” sur toutes les zones DNS

Le DHCP Express

On aura besoin d’un DHCP sur le réseau LAN, pas besoin d’explication supplémentaires sinon une première commande pour installer le rôle lui même. Pour la configuration, on va travailler avec le couteau suisse du réseau, j’ai nommé NETSH.EXE pour créer une étendue DHCP et un peu de configuration :

 

Installation de l’autorité racine de confiance

Note : Encore une fois, je rappelle que l’implémentation de la PKI ci-dessous se limite à l’aspect technique et encore uniquement pour les besoins de NAP-IPSEC. Ceci ne peut être considéré comme une mise en œuvre selon les règles. Il manque déjà les 90% d’organisation et de processus avant d’attaquer les 10% de techniques restantes.

 

A ce stade, je vais temporairement abandonner mon invite de commande PowerShell pour rebasculer dans le monde de l’interface graphique et de la souris (sic) pour mieux documenter mes choix d’installation. C’est un rôle que l’on installe, donc pas de problème à ce stade :

Subtilité, j’installe un sous-composant à cette autorité de certification à savoir son site web de soumission des demandes de certificat. Ceci implique l’installation du rôle Web-Server:

 

Choix crucial, à savoir l’installation d’une autorité de type “"Entreprise”, ce qui implique que celle-ci sera reconnue comme autorité de confiance par tous les postes de travail du domaine (sera automatiquement inscrit dans la Default Domain Policy"). Ce choix permet aussi la soumission et le renouvellement de certificats de manière totalement automatique :

Etant donné que c’est la première autorité de certification, ce sera donc une autorité de type racine et non subordonnée :

Je n’ai pas besoin d’utiliser un clé privée existante (cas d’une réinstallation de la CA par exemple), donc le seul choix possible est “New Private Key” :

Je conserve l’algorithme cryptographique, le CSP proposé ainsi que la longueur de clé. La bonne pratique serait d’augmenter la taille de la clé car la CA sera située au sommet de la hiérarchie. Sa compromission entraine la compromission de toute la hiérarchie. Etant donné que cette infrastructure est montée dans un cadre d’expérimentation, je conserve les choix par défaut :

Afin de bien différencier l’autorité racine de confiance de l’autorité racine secondaire (qui sera installée dans le prochaine billet), je nomme arbitrairement mon autorité RootCA :

La bonne pratique concernant la durée de validité serait de configurer notre autorité racine avec la durée de vie la plus longue et de configurer des durées de plus en plus réduites pour les autorité de certification intermédiaires et enfin très courtes pour les autorité de certification émettrices (de certificats). Attention cependant, plus on aspire à la confiance, plus il faut montrer patte blanche, les critères sont très sélectifs. Il est long le parcours avant de devenir aussi reconnu que Verisign. Donc dans le cas de notre implémentation, je conserve le choix par défaut. La seule conséquence est que les certificats émis ne pourront excéder la durée de vie de l’autorité de certification. Il faudra donc porter une attention toute particulière aux renouvellements :

Le processus d’installation nous permet de placer la base de données (et son journal de transaction) sur un volume disque distinct. Le principal intérêt de cette mesure réside dans l’isolation entre l’administrateur du système et l’administrateur de l’autorité de certification. Comme c’est une option que je vais pas mettre en œuvre, je conserve les répertoires par défaut (pourtant, c’est une très bonne pratique):

Pour l’installation du sous-rôle de site web de soumission des demandes de certificat, l’assistant nous demande si d’autres composants optionnels du rôle “Web-Server” ne nous intéresserait pas. Les choix minimum permettant le bon fonctionnement de la solution étant déjà sélectionnés, on conserve donc les options par défaut :

Ca y est, la fin avec l’inévitable conséquence, à savoir l’impossibilité de renommer le serveur une fois l’installation terminée :

 

Note : Etant donné que nous sommes dans le cadre d’une implémentation en laboratoire, je fait l’impasse sur les vérifications de bon fonctionnement de notre autorité de certification. Merci aux puristes de la PKI de ne pas m’e jeter la pierre!

 

Les exceptions à la règle

Comme pour entrer en boite de nuit, le videur (NPS) à toujours une liste d’exception qui vient contredire la règle générale (la conformité du poste conditionne son accès au réseau). La première exception à la règle, c’est bien entendu le serveur NPS. Si lui même n’a pas accès au réseau alors comment pourra t’il traiter les demandes qui lui sont soumises? Les exceptions seront traitées au travers d’un groupe de sécurité :

Ce groupe de sécurité permettra aux futurs membres de disposer d’un certificat prouvant leur état de santé sans avoir à le démontrer. La prochaine étape consistera donc à disposer d’un gabarit de certificat pour l’état de santé.

 

Le gabarit de certificat “System Health Authentication”

L’implémentation de NAP IPSEC prévoit que si le système est conforme, il se voit attribué un certificat qui sera utilisé pour authentifier (AH) voire chiffrer (ESP) les communications. Par contre, il faut pouvoir identifier le certificat à utiliser. On pourrait se contenter d’un certificat proposant le rôle “Client Authentication”, cependant, cela posera problème pour la règle d’isolation IPSEC qui sera positionnée sur le pare-feu. Comment utiliser le certificat délivré à cet effet et non le certificat “workstation” délivré car la machine à obtenu son certificat automatiquement? Pour cette raison, il est nécessaire de disposer d’un gabarit de certificat indiquant bien l’usage qui en sera fait. Le rôle “Health Authentication” est fait pour cela. La configuration de l’isolation IPSEC exigera d’utiliser un certificat présentant ce rôle.

 

On va donc commencer par dupliquer le gabarit de certificat “Workstation” et utiliser le mode “Windows Server 2008” proposant le plus de possibilité au niveau de la manipulation des certificats :

Note : La manipulation des gabarits de certificats est possible uniquement dans Windows Server 2008 entreprise/Datacenter, Windows Server 2008 R2 standard/Entreprise/DataCenter.

 

Notre nouveau gabarit sera nommé “System Health Authentication”. Le nom du gabarit est nécessairement sans espaces. Etant donné que les systèmes qui disposeront de certificats générés selon ce gabarit n’auront pas à prouver leur conformité, pas la peine de configurer une durée très courte. Un an est amplement suffisant, tout comme les six semaines avant renouvellement. Comme l’enregistrement de ces demandes sera traité par stratégie de groupe on pourra bénéficier du renouvellement automatique, ce qui nous facilitera l’exploitation. Attention, à ce stade, il faut penser à ne pas oublier le publier le certificat dans l’annuaire Active Directory :

La caractéristique de ce modèle de gabarit de certificat sera d’être identifiable pour le rôle “System Health Authentication”. On va donc l’ajouter dans la liste :

Notre gabarit de certificat est presque terminé. Il reste juste à s’assurer qu’il ne sera disponible que pour les systèmes membres du groupe “NAP Exception Group” précédemment créé. Les membres du groupe pourront réaliser l’enregistrement automatique de leurs certificats :

Le gabarit de certificat est finalisé mais pas encore utilisable car pas encore publié. On va donc y remédier :

 

Enregistrement automatique et renouvellement de certificats

L’utilisation d’une autorité racine de confiance intégrée à l’annuaire Active Directory permet aux systèmes raccordés de gérer eux même leur demande de certificat. Etant donné que les demandes émanent de comptes clairement identifiables, l’autorité de certification est capable de délivrer automatiquement les certificats. Les systèmes sont même capables de gérer eux même leur renouvellement. On a donc rien à faire sinon de configurer cela dans une stratégie de groupe :

Reste plus qu’à configurer le paramètre qui va bien parmi les 3000 disponibles :

Cette stratégie de groupe est finalisée (les puristes me jetteraient à la figure qu’étant donné qu’il n’y a pas de paramétrage utilisateur on peut désactiver cette section mais je rappelle que nous sommes dans le cadre d’une implémentation en laboratoire). On va donc positionner cette stratégie de groupe à la racine du domaine :

Il ne nous reste plus qu’à créer un conteneur organisationnel dans lequel on va placer tous les systèmes pour lesquels on configurera plus tard une stratégie de groupe qui mettra  une stratégie de pare-feu pour l’isolation IPSEC sans être restrictive. Etre à la frontière signifie que l’on doit accepter de communiquer avec des clients qui ne sont pas conformes :

 

Et ca marche tout cela?

La question est intéressante. Ce serait dommage de poursuivre l’installation pour s’apercevoir qu’un détail coche déjà à ce niveau. Le plus simple est donc de positionner le compte ordinateur de notre serveur nps.corp.Windows2008R2.Com dans le groupe d’exception et de voir ce qui se passe :

 

Et placer notre serveur dans le conteneur organisationnel “Frontière”, en prévision de la stratégie de groupe de configuration du pare-feu :

Lorsque le serveur NPS (préalablement raccordé au domaine) redémarre, on peut tout de suite constater la présence d’un certificat dans le conteneur personnel de l’ordinateur. Ce certificat dispose bien du rôle “System Health Authentication”, donc ça a bien marché (jusqu’ici) :

Voila qui clos ce billet. Ce fut laborieux mais au moins on est assuré que jusque là tout va bien. Attention, la route vers la conformité est encore longue.

 

BenoîtS – Simple and Secure by Design