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