• Article

DirectAccess : un jeu de lego – (Partie 3/7 : PKI)

 

 

Article par Benoît SAUTIERE (MVP Enterprise Security)

Benoît SAUTIERE est référent technique et architecte infrastructure pour un Microsoft Gold Partner. En tant que MVP, Benoît participe au développement des offres autour des solutions d’infrastructure Microsoft et intervient en tant que Speaker aux Techdays 2010 et 2011.

Mon parcours « Microsoft » a commencé avec Windows NT 3.51 et produits associés, pour progressivement me spécialiser sur les solutions d’infrastructures Microsoft et arriver aujourd’hui à Windows 2008 R2. C’est au TechEd 2008 que j’ai découvert ce qui deviendra DirectAccess, sujet que j’ai développé tout au long de nombreux billets sur mon blog : Simple by design, signant mes articles avec la mention « Simple and Secure by Design », maintenant complétée de « and Business compliant ».

Spécialiste des infrastructures d’annuaire ainsi qu’impliqué dans les aspects sécurité des produits Microsoft, Benoît intervient auprès de grands comptes français voire internationaux pour son expertise dans ces domaines.

  

Articles

Vous trouverez ci-dessous le début de l’article, n’hésitez pas à télécharger la suite directement en format pdf

Sommaire de l'article

  • Préparation Active Directory Certificates Services
    • Installation
    • Publication de la CRL
    • Subtilité de la sauvegarde de la clé privée
    • Subtilité du Health Registration Authority
    • Subtilité du Health Registration Authority bis repetita
  • Préparation des gabarits de certificat
    • Certificats d’authentification IPSEC
    • Certificats d’état de santé
    • Certificat Network Location Server
    • Activation de l’auto-Enrollment

 

>> Télécharger gratuitement l'intégralité de cet article <<

 

Préparation Active Directory Certificates Services

Installation

Dans le cadre de notre plateforme de démonstration de DirectAccess, nous avons besoin d’une autorité de certification. Etant donné que nous ne sommes pas dans le cadre d’un environnement de production, nous pouvons nous permettre des écarts tels que la non mise hors ligne de l’autorité racine de confiance dite « Root ». Par contre, on ne va pas faire l’impasse sur la publication des listes de révocation sur un serveur distinct. Voilà ci-dessous le résumé de mon installation du rôle ADCS.

Installer le rôle ADCS c’est bien mais correctement publier les listes de révocation, c’est mieux. Pour cela, un peu de travail est nécessaire. Lorsqu’on observe la configuration par défaut de l’autorité de certification nouvellement installée, on constate que les listes de révocation sont publiées sous plusieurs formes (fichier, http et même LDAP).

 

Cependant cette configuration pose un problème. Il sera référencé que la révocation des certificats émis pourra être validée en http. Pourtant, il n’y a pas de serveur web sur mon contrôleur de domaine (c’est le mal!).

 

Haut de page | Haut de page

Publication de la CRL

Pour finaliser l’installation de l’autorité de certification, il faut donc publier les listes de révocation mais pas sur le même serveur. Dans les scénarios classiques de déploiement d’une autorité de certification, celle-ci est mise hors ligne. Or, comment peut-on accéder aux listes de révocation si celles-ci sont hébergées sur un serveur inaccessible. On va donc s’assurer que nos listes de révocation soient publiées sur le serveur APP1.

On a vu que la publication http n’est pas conforme. On va donc la remplacer par une nouvelle qui va référencer : http://crl.corp.contoso.com/crld/\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl comme emplacement de publication.

Pour cette première extension, les cases à cocher « Include in CRLs.Clients use this to find Delta CRL locations » et « Include in the CDP extensions of issued certificates » doivent être cochées.

Pour la seconde extension, on va indiquer à l’autorité de certification à quel emplacement publier ses listes de révocation.

Ce nouvel emplacement doit permettre de publier à la fois la CRL mais aussi la CRL Delta.

Il ne nous reste plus qu’à supprimer le point de distribution initial.

Il est nécessaire de redémarrer l’autorité de certification pour les modifications soient prises en compte.

A ce stade, l’autorité de certification est presque prête. Le serveur APP1 n’étant pas encore opérationnel, on devra attendre son installation pour finaliser la publication de la liste de révocation.

 

Haut de page | Haut de page

Subtilité de la sauvegarde de la clé privée

Jusqu’à Windows 2003, l’outil de sauvegarde de Microsoft prenait en charge la sauvegarde de l’autorité de certification sans aucun problème. C’est toujours vrai sous Windows Server 2008/2008 R2, avec une petite subtilité. L’emplacement de stockage de la clé privée ayant été déplacé dans le répertoire caché suivant : « %systemdrive%\ProgramData\Microsoft\Crypto\Keys ». La conséquence, c’est que l’outil de sauvegarde Windows Server Backup n’est plus en mesure de sauvegarder cette clé privée, ce qui est plutôt gênant. On va donc s’assurer de la sauvegarde de la clé privée.

La sauvegarde de la clé privée de l’autorité de certification est essentielle car sans elle, il ne sera pas possible d’effectuer une restauration ou une migration vers un autre système. La recommandation est bien entendu de conserver la clé privée ainsi que le mot de passe associé de manière sécurisée et non la laisser sur le serveur.

 

>> Télécharger gratuitement l'intégralité de cet article <<

 

Haut de page | Haut de page