Pour tout ceux qui ont touché au moins une fois à ISA Server, tout le monde connait le site http://www.isaserver.org/ de Tom Shinder, anciennement MVP sur ForeFront.

Depuis peu, Tom a rejoint Microsoft au sein de l’entité “Microsoft ISDUA – UAG DirectAccess – Anywhere Access Team (AAT)“ et anime un nouveau blog dédié à DirectAccess/ UAG : http://blogs.technet.com/tomshinder/default.aspx.

Son dernier billet : Troubleshooting the “No Usable Certificate(s)” IP-HTTPS Client Error rappelle combien il est important de ne pas bricoler avec les gabarits de certificats. On évite ainsi de nombreuses heures de troubleshooting.

Benoîts – Simple and Secure By Design (J’insiste sur le Secure)

On arrive à la fin, à savoir délivrer un certificat d’authentification par carte à puce pour notre utilisateur “SimpleByDesign”. Notre utilisateur “ITManager” disposant d’un certificat de signature, c’est donc lui qui va générer le certificat de notre utilisateur.

 

ITManager va donc prendre sa carte à puce et s’authentifier avec sur une station de travail et utiliser la console Certificats pour une demande au nom d’un autre utilisateur.



 

la demande étant réalisée pour le compte d’un autre utilisateur, l’interface nous demande d’accéder au certificat de signature situé sur notre carte à puce.



 

Par extension, il faut déverrouiller la carte à puce.



 

Je fait encore l’impasse sur les rappels et les stratégies d’inscriptions de certificats pour me focaliser sur la demande d’inscription de certificat pour la carte à puce. L’interface nous indique que des informations supplémentaires sont nécessaires, facile c’est la signature qui manque à ce niveau. A noter que si on vient d’accéder à sa carte à puce (donc avec saisie du code PIN, on dispose déjà de l’accès à la clé privée du certificat de signature).



 

Gagné. Etant donné que c’est l’utilisateur ITManager qui est connecté, c’est son certificat de signature sur la carte à puce qui nous intéresse.



 

On dispose de toutes les informations. L’interface nous à demandé d’insérer une carte à puce contenant le fameux certificat de signature.



 

Maintenant qu’on dispose bien du certificat de signature de l’utilisateur “ITManager”, plus rien ne nous empêche de réaliser la demande de certificats.



 

La demande devra être réalisée pour l’utilisateur “SimpleByDesign”.



 

La suite n’est qu’un échange de carte à puce et saisie de code PIN tel que déjà abordé dans le billet précédent, je ne vais donc pas m’attarder dessus. Ce qu’il faut retenir, c’est que pour générer un certificat pour “SimpleByDesign”, il faut :

• Générer une clé privée qui devra être stockée sur la carte à puce de notre utilisateur “SimpleByDesign”
• Qu’il faudra signer la demande avec le certificat de signature “ITManager”
• Qu’il faudra stocker la demande sur la carte à puce de l’utilisateur “SimpleByDesign”
• Qu’i faudra stocker le certificat obtenu de la PKI sur la carte à puce de l’utilisateur “SimpleByDesign”

 

On comprend donc vite l’intérêt de disposer de deux lecteurs de carte à puces sur son poste. A la fin, notre utilisateur “SimpleByDesign” dispose maintenant d’une carte à puce opérationnelle.

A ce stade, on ne va pas dire qu’on a fait le tour de la carte à puce. Il y aurait encore beaucoup à dire mais tout dépend du scénario que l’on désire mettre en œuvre. Un futur billet reviendra sur tous les points à ne pas oublier et quelques subtilités.

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

La carte à puce de l’administrateur de l’autorité de certification est censée rester au coffre. Cependant, il faut bien déléguer les tâches courantes. On va donc désigner un responsable de l’enregistrement des cartes à puces qui aura la possibilité de signer les certificats d’ouverture de session par carte à puce. On va maintenant mettre en œuvre une nouvelle subtilité : La demande de certificats au nom d’un tiers.

 

Notre utilisateur “ITManager” est membre du groupe “Smartcard_Issuers”, au même titre que notre administrateur de la PKI.

 

Dans ce billet, nous allons traiter de deux sujets :

• La mise à disposition du certificat de signature de demande de carte à puce (et son stockage sur la dite carte)

• La demande et la signature de son propre certificat d’authentification par carte à puce

 

 

Mise à disposition du certificat de signature de demande de carte à puce

Notre responsable délégué de la gestion des cartes à puces doit déjà disposer d’une carte à puce pour y stocker son certificat de signature. L’administrateur de la PKI va donc lui préparer un certificat d’authentification de carte à puce. C’est donc l’administrateur qui génère un certificat pour “ITManager”. On a donc ouvert la session avec le compte administrateur.



 

Comme la demande de certificats est effectuée pour le compte d’un autre utilisateur (ITManager), il est nécessaire que l’administrateur de la CA signe cette demande avec son certificat de signature.



 

Pour le signer, encore faut-il pouvoir accéder à la clé privée du certificat qui est stockée sur la carte à puce, ce qui nécessite de déverrouiller la carte.



 

La liste des gabarits de certificats présentée est filtrée en fonction des autorisations dont nous disposons sur les gabarits mais aussi par rapport aux possibilités techniques. Par exemple, dans l’illustration ci-dessous, il n’y a aucune trace du gabarit de certificat de signature de carte à puce, uniquement le gabarit de certificat de la carte à puce (normal, on vient d’y accéder, on a donc toutes les informations nécessaires pour formuler la demande au nom de “ITManager”).



 

Comme nous réalisons la demande pour l’utilisateur ITManager, encore faut-il le préciser :



 

Dès lors, le jeu du swap des cartes à puce commence. Si on ne dispose que d’un seul lecteur, on va passer son temps à changer de carte. Qui dit changer de carte dit de devoir ressaisir le code PIN. La première interface nous demande de retirer la carte à puce de l’administrateur pour placer la future carte de “ITManager” dans le lecteur.



 

Qui dit nouvelle carte, dit saisie de code PIN. A ce stade, il faut générer une clé privée pour notre nouveau certificat :



 

A ce stade, on nous demande de réinsérer la carte à puce de l’administrateur.



 

Et se saisir le code PIN associé pour qu’on puisse accéder à la clé privée du certificat de signature de carte à puce de l’administrateur (on signe la demande).



 

Toutes les informations ont été remontées à l’autorité de certification. La demande étant valide et réalisée par un utilisateur accrédité, le certificat doit être délivré. Encore faut-il placer le certificat sur la carte à puce de “ITManager”.



 

Et se saisir le code PIN associé à sa carte à puce.



 

Pour enfin obtenir le certificat d’ouverture de session par carte à puce.



 

La demande et la signature de son propre certificat d’authentification par carte à puce

A ce stade, notre utilisateur “ITManager” peut utiliser sa carte à puce pour ouvrir une session uniquement. Encore faut-il qu’il récupère son certificat de signature de carte à puce. Notre “ITManager” disposant des permissions nécessaires sur le gabarit de certificat de carte à puce, il peut de lui-même demander son certificat, toujours avec la console MMC :



 

Je fait l’impasse sur les rappels et autres stratégies d’enregistrement déjà abordés précédemment, passons maintenant à la sélection des certificats. Ce qui nous intéresse, c’est un certificat de signature pour les certificats de carte à puce.



 

Le certificat de signature devant être enregistré sur la carte à puce, l’interface nous demande d’y accéder.



 

Au final, Notre utilisateur “ITManager” dispose maintenant de son certificat de signature et d’authentification par carte à puce.



 

On peut constater la présence des deux certificats dans le magasin utilisateur de “ITManager”. Il est prêt à travailler : Générer des certificats d’authentification pour carte à puce.



 

A ce stade, on pourrait penser qu’il serait intéressant de supprimer la publication du gabarit de certificat de signature. Cependant, ce serait une erreur car il ne serait pas possible de renouveler automatiquement les certificats émis.

 

On touche au but. Prochaine étape, la délivrance d’une carte à puce à un utilisateur final.

 

Benoîts – Simple and Secure By Design (J’insiste sur le Secure)

Après la partie “théorique” avec la PKI et ses gabarits de certificats, passons maintenant à la partie “pratique” avec les cartes à puces. La première carte à générer sera celle de l’administrateur du domaine ou de la PKI (si on a bien activé la séparation des rôles). Dans ce billet, nous allons traiter de deux sujets :

• La mise à disposition du certificat de signature de demande de carte à puce (et son stockage sur la dite carte)
• La demande et la signature de son propre certificat d’authentification par carte à puce

 

Petite révolution par rapport à l’ère Windows 2000/2003, la gestion des cartes à puce ne passe plus par le site web de traitement des demandes du rôle ADCS mais par la console MMC “Certificats”.

 

La mise à disposition du certificat de signature de demande de carte à puce

Une fois authentifié comme administrateur et mis en place notre console “Certificats”, nous pouvons faire notre demande de certificat. Nous sommes administrateur de la PKI donc autorisé à réaliser un “autoenroll” pour ce gabarit de certificat.



 

Etant donné que la demande sera réalisée auprès d’une autorité de certification, il est nécessaire de s’assurer que notre ordinateur est bien connecté au réseau et que nous utilisons un compte utilisateur disposant des privilèges appropriés (administrateur du domaine dans notre cas).



 

Avec Windows 2008 R2, il est possible d’avoir plusieurs stratégies d’inscription de certificats. Dans le cas qui nous occupe, nous allons utiliser celle qui est configurée dans l’annuaire Active Directory.



 

C’est à partir de maintenant que tout se complique. Même si l’interface le propose, nous n’allons pas demander les deux certificats en même temps. La raison est simple. Il faut déjà disposer du certificat de signature pour obtenir notre certificat d’authentification par carte à puce. Il faut signer notre demande avec!



 

Le gabarit de certificat a été configuré pour utiliser la carte à puce pour stocker le certificat. Il faut donc accéder à son magasin privé pour générer entre autre la clé privée et déposer le certificat obtenu auprès de l’autorité de certification.



 

Le certificat de signature de carte à puce est maintenant utilisable. Il est sécurisé car il n’est pas stocké sur le poste de travail mais bien sur le carte à puce. Cette mesure est d’autant importante que de nos jours, une bonne partie du parc informatique des entreprises est composé de postes nomades qu’il nous arrive d’oublier dans un bureau, sans surveillance, sans aucune sécurité physique, …



 

On peut constater que dans le magasin personnel de notre utilisateur, on dispose bien de notre premier certificat.



 

La demande et la signature de son propre certificat d’authentification par carte à puce

A ce stade, une bonne mesure serait de placer cette carte à puce dans un lieu sécurisé et de supprimer la publication du modèle de certificat ayant permit de réaliser l’opération. Cependant, on va continuer avec notre carte à puce de l’administrateur pour y intégrer le certificat d’authentification par carte à puce.

 

La demande de certificats s’effectuera toujours depuis la console MMC et le composants logiciels enfichable "Certificats" :



 

A ce stade, on va bien demander un certificat de carte à puce. A ce stade, la console nous interdit de continuer car il manque une information essentielle pour générer le certificat.



Tout le simplement le certificat de signature que nous avions préalablement positionné sur la carte à puce.

 

Note : Si on va trop vite, la console MMC a toujours accès à la carte à puce et donc au certificat de signature.

 



 

Toutes les informations nécessaires étant maintenant disponibles, on peut continuer. On a bien un certificat de signature pour notre demande de carte à puce.



 

Et voila un nouveau certificat pour notre première carte à puce.



 

Notre console d’administration des certificats utilisateur nous affiche bien nos deux certificats.



 

Pour les fans de la ligne de commande : "certutil -scinfo" et quelques saisies du code PIN plus tard, …



 

Et histoire d’être à la page, un petit peu de PowerShell :

Coté contrôleur de domaine, on va trouver une demande de TGT Kerberos. C’est tout à fait normal.

 

Ce qui change, c’est- que le TGT a été émit pour une authentification par carte à puce.

Voila notre première carte à puce opérationnelle. Prochaine étape, en délivrer une pour notre gestionnaire informatique en charge de délivrer des cartes à puces aux utilisateurs finaux.

Benoîts – Simple And Secure by Design (J’insiste sur le Secure)

Ce type de migration est loin d’être aussi simple qu’il n’y parait. Il faut distinguer la migration du rôle ainsi que les usages qui en sont fait.

Pour la migration du rôle ADCS (et versions précédentes), l’équipe PKI chez Microsoft vient de mettre à disposition un guide de migration de ADCS. A noter que l’équipe met à disposition un script VBScript destiné à automatiser l’installation du rôle ADCS.

Maintenant, reprenons le cours de notre série Smart Card.

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Passons maintenant au cœur du problème avec le gabarit de certificat d’authentification par carte à puce. L’objectif n’est pas que n’importe qui disposant d’un compte dans l’annuaire Active Directory puisse obtenir son certificat mais bien de le délivrer par des personnes dûment accréditées, disposant du certificat de signature.

 

On va donc commencer par dupliquer un gabarit. On a le choix entre :

• Smartcard Logon
• SmartCard user

Différence entre les deux? Pour le premier, son certificat sera publié dans l’annuaire Active Directory. Le second intègre lui l’adresse de messagerie de l’utilisateur dans le certificat. Dans le cas qui nous occupe, nous partirons sur une base de “SmartCard logon” que nous allons personnaliser, après duplication, cela va de soi.



 

Je vais volontairement publié notre certificat dans l’annuaire Active Directory (pourquoi ne pas avoir utilisé Smartcard User alors?) et m’assurer que le renouvellement du certificat fonctionnera bien.



 

Le rôle de notre certificat sera limité à la signature et l’authentification par carte à puce, en aucun cas au chiffrement. EFS n’est pas à l’ordre du jour. En plus, cela imposerait de désigner un agent récupérateur, beaucoup plus complexe à mettre en œuvre et un KRA sur la PKI. 

 

Subtilité, lors de la demande, le gabarit indique qu’il faut communiquer avec l’utilisateur lors de la génération de son certificat. C’est normal, qui dit carte à puce, dit saisie du code PIN.



 

Notre certificat sera stocké sur la carte à puce. On n’oubliera donc pas de ne conserver que ce CSP.



 

A ce stade, il est possible d’ajouter l’adresse de messagerie de l’utilisateur dans l’attribut “Subject Name” de la demande de certificats. Encore faut-il que l’attribut soit renseigné dans l’annuaire. Sinon il sera nécessaire de fournir l’information lors de la génération de la demande. A noter que l’adresse de messagerie est nécessaire pour compatibilité avec Windows XP.



 

C’est maintenant que cela devient intéressant. l’utilisateur ne doit pas pouvoir demander son certificat lui même. La demande doit être signée par un certificat de type “Certificate Request Agent”. On va demander que lors de l’enregistrement, un certificat de présenté et que celui-ci réponde à l’OID “Certificate Request Agent”.



 

Finissons en avec notre certificat avec la notion d’héritage. Il héritera de “SmartCard Logon”. Notre gabarit de certificat sera donc reconnu comme tel.



 

Passons maintenant à la sécurité du gabarit ou plus précisément qui peut faire quoi. Les utilisateurs authentifiés peuvent savoir que le gabarit existe. C’est normal. Les paranoïaques peuvent supprimer la permission.



 

Les utilisateurs de carte à puces peuvent demander un certificat, ils sont membres du groupe (par contre sans signature, ils ne pourront pas aller bien loin dans la demande). A noter que la permission “AutoEnroll” est nécessaire pour le renouvellement automatique.



 

Enfin, notre groupe en charge de la signature des demandes de certificats dispose aussi des permissions lire et enregistrer, ce qui est normal puisqu’il doivent pouvoir délivrer ce type de certificat.



 

Fini, ne reste plus qu’à publier notre gabarit.

Voila pour la partie purement PKI. Reste maintenant à traiter la mise à disposition des certificats à nos différents utilisateurs (administrateur, IT Manager et utilisateur).

Benoîts – Simple and Secure By Design (J’insiste sur le Secure)

Pour la mise en œuvre de la PKI, c’était un peu léger. Maintenant on rentre dans le vif du sujet avec la création de notre premier gabarit de certificat. Celui-ci sera dédié à la signature des demandes de certificats pour un usage de carte à puce. Le gabarit de certificat existe bien mais lequel choisir :

• Enrollment Agent
• Enrollment Agent (computer)

Afin de corser le sujet, on ne va pas stocker le certificat de signature dans le profil Windows de l’utilisateur mais dans sa carte à puce. De cette manière, cela ne pose pas de problème de sécurité si notre responsable de l’émission de carte à puce venait à perdre son ordinateur portable (avec son certificat dessus).

Règle d’or concernant la PKI : On ne manipule pas les gabarits par défaut, on les duplique. Pour raison de compatibilité avec les systèmes d’exploitation précédents, on va choisir “Windows 2003 Entreprise”.

Notre certificat de signature n’a pas besoin d’être stocké dans l’annuaire Active Directory (ce serait mal en plus). Par contre, on va s’assurer que son renouvellement automatique est bien pris en charge.

Le rôle de mon certificat sera uniquement limité à la signature des certificats. On va jute imposer une longueur de clés. A ce stade, il est essentiel de bien s’assurer que l’utilisateur soit notifié des éventuelles informations manquantes pour générer le certificat au nom d’un autre. L’information manquante à ce stade, c’est tout simplement le nom de l’utilisateur pour quoi on va générer la demande de certificats. Il faut donc pouvoir poser la question.

Subtilité du stockage du certificat, on va le placer sur la carte à puce. Depuis Windows Vista, on dispose d’un CSP générique pour les cartes à puces.

Lorsque notre gestionnaire de carte à puce va faire une demande de certificat d’authentification par carte à puce pour le compte d’un autre, toutes les informations nécessaires seront issues de l’annuaire Active Directory. L’inscription de l’UPN est nécessaire.

Le déploiement des certificats de signature de certificats d’authentification par carte à puce sera autorisé par simple enregistrement automatique, grâce à l’appartenance à un groupe. Dans une mise en œuvre plus “réaliste”, la demande de ce type de certificat devrait être approuvée par une autorité supérieure (administrateur de la PKI par exemple). Pour simplifier, j’ai retenu un autre scénario, plus simple :

• Pas d’approbation
• pas de signature requise

Notre certificat de signature personnalisé référencera qu’il est un enrichissement d’un certificat initial dont l’OID est connu de tous.

Comme indiqué précédemment, les utilisateurs identifiés comme autorisés à émettre des certificats pourront réaliser une enregistrement de leur certificat de signature eux même (en passant par la console “Certificats”).

Notre certificat est maintenant opérationnel. Il ne reste plus qu’à le publier pour le rendre utilisable.

Donc à ce stade, dès lors qu’un utilisateur est membre du groupe “Smartcard_Issuer”, il peut de lui même obtenir un certificat de signature. On comprend donc tout de suite qu’il est essentiel de bien maîtriser qui est membre de ce groupe.

Pour rendre le sujet accessible, j’ai volontairement autorisé la mise à disposition de ce gabarit de certificat sans approbation de la part d’un autre utilisateur (administrateur de la PKI). Dès lors que nos responsables en charge de l’émission de certificats disposent de leurs certificats de signature, il sera donc recommandé de supprimer la publication de ce gabarit de certificat de signature.

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Après la théorie passons à la pratique avec la mise en œuvre de son composant de base, à savoir la PKI. Depuis Windows 2008, c’est un rôle à installer. Dans le scénario que nous allons mettre en œuvre, on a juste besoin du composant de base. Le site web d’enregistrement des demandes ne nous intéresse pas.

Pour le type d’autorité de certification, c’est nécessairement entreprise afin de disposer de la fonctionnalité d’enregistrement automatique. Dans une mise en œuvre plu complète d’une infrastructure de clés publique, on utiliserait un modèle basé sur une hiérarchie à deux niveaux, le premier étant mis “hors ligne”.

Comme c’est la première autorité de certification de notre hiérarchie (à un seul niveau pour faire simple), c’est donc une autorité racine.

Cette autorité doit avoir un nom. Par commodité, ce sera “SmartCard-RootCA”.

Enfin, pour finaliser la mise en œuvre, on va avoir besoin de deux groupes de sécurité. le premier pour utilisateurs heureux détenteur de carte à puce avec un petit peu de Powershell pour la route.

Et un second pour identifier la population des utilisateurs chargés de émission des cartes à puces.

Bon, à ce stade, cela peut paraître simple mais pour rendre le sujet accessible, je suis obligé de faire l’impasse sur un certain nombre de sujets :

• La mise en œuvre d’une infrastructure de clés publiques à deux niveau
• La mise hors ligne du premier niveau de l’autorité de certification (installée en mode core, cela va sans dire)
• la séparation des rôles d’administration de la PKI
• La restriction quand à l’utilisation de l’agent d’enregistrement

Voila donc pour la base de notre PKI. prochaine étape, la création de nos gabarits de certificats. La, ça va commencer à devenir technique.

Benoîts Simple and Secure by Design (J’insiste sur le Secure)

Cela faisait longtemps que je comptais faire une série sur la carte à puce. On va donc s’y lancer. Pour être clair, la mise en œuvre qui sera proposée dans cette série de billets se limitera à la technique autour de la carte à puce, sans prendre en considération les aspects organisationnels.

Une Smart Card, c’est quoi?

C’est avant tout un support pour stocker des informations. Le plus commun, c’est celui de la carte à puce tel que présenté ci-dessous :

Il existe plusieurs types de cartes à puces, les dernières générations embarquent même plusieurs technologies d’authentification, permettant de répondre à différents besoins. Autant l’insertion de la carte à puce est envisageable pour ouvrir une session sur une station de travail, autant ce n’est pas aussi adapté pour ouvrir une porte. Voila donc pour la forme la plus commune.

Mais il existe aussi d’autres support pour la puce en elle même. On utilise généralement les dispositifs ci-dessous dans lequel on insert une puce.

En quoi les Smart Card ont changé depuis Windows Vista?

• Le Microsoft Base Smart Card Cryptographic provider est une nouveauté de Windows 2008/VISTA qui propose un modèle d’implémentation des cartes à puces. Charges aux autres fournisseurs de se baser dessus. Cela ainsi permit aux différents fournisseurs de travailler sur leurs spécificités et d’utiliser un driver commun plus fiable
• La gestion des cartes à puces a radicalement changé avec l’arrivée de Windows VISTA
• Les utilisateurs sont maintenant obligés d’initier le processus d’ouverture de session (CTRL+ALT+SUPPR) pour pouvoir utiliser la carte à puce.
• Le certificat peut être localisé n’importe ou dans la carte à puce (L’utilisateur peut même sélectionner l’identité qu’il désire utiliser)
• Il n’est plus nécessaire de positionner une extension pour la CRL dans le gabarit du certificat
• Il n’est plus obligatoire de configurer le Subject Alternative Name avec l’UPN de l’utilisateur mais fortement recommandé
• L’Extended Key Usage n’est plus obligé de contenir l’OID Smartcardlogon (mais fortement recommandé rien que pour la compatibilité avec les versions antérieures de Windows)

Certificats mis en œuvre

Qui dit carte à puce, dit certificats. On commencera donc par la mise en œuvre d’une infrastructure de clés publique tout à fait standard. Pour les cartes à puces, on a besoin de deux types de certificats :

• Smart Card

Ce type de certificat existe déjà dans l’infrastructure de clés publiques, nous allons juste le personnaliser pour différentes raisons que nous développerons dans un billet ultérieur.

• Enrollment Agent

Ce type de certificat existe aussi dans l’infrastructure de clés publiques. On utilise ce type de certificat pour réaliser l’enregistrement du certificat Smart Card. Plus précisément pour signer la demande de certificat pour prouver que la demande de certificat réalisée pour le compte d’un tiers est bien issue d’un utilisateur valide.

Scénario proposé

Dans le scénario qui sera développé dans cette série de billets, on va disposer de trois utilisateurs :

• L’administrateur de la PKI

Il disposera d’une carte à puce. Cette carte sera utilisée pour générer la carte à puce du gestionnaire IT. Après, la recommandation sera de mettre cette carte en lieu sur?

• l’IT Manager

Le gestionnaire IT disposera d’une carte à puce pour s’authentifier mais aussi pour générer celles des utilisateurs.

• L’utilisateur “SimplebyDesign”

Enfin pour finir, un simple utilisateur disposera d’une carte à puce qui aura été générée par l’IT Manager

Donc pour résumé, une fois que l’infrastructure sera en place, voila ce qui va se passer :

1. L’administrateur se génère une carte à puce lui-même pour signer les demandes de certificats ainsi que s’authentifier
2. L’administrateur va générer la carte à puce de l’ITManager
3. L’IT Manager va s’authentifier avec sa carte à puce et obtenir son certificat de signature
4. L’IT Manager va générer la carte à puce de l’utilisateur “SimplebyDesign”

Limitation du scénario présenté

L’implémentation de la Smart Card est purement technique. Elle ne répondra pas nécessairement à tous les usages. Ce billet a pour unique vocation d’illustrer un exemple de mise en œuvre dans lequel j’ai volontairement passé sous silence ou simplifié :

• Pas de gestion de la carte à puce en elle même (réinitialisation du code PIN, …)
• Pas de gestion de la mise à disposition de la carte à puce à l’utilisateur
• Une mise en œuvre volontairement simplifiée de la PKI (pas d’infrastructure à deux niveau avec le premier hors ligne)
• Pas de mise en œuvre de l’OCSP

Détail de la mise en œuvre

Nous en avons fini avec la théorie (j’ai fait au plus court), passons maintenant à la technique pure. Pour des raisons de volume, la série sera découpée en plusieurs billets qui seront publiés au fur et à mesure :

• Etape n°1 : Mise en place de la PKI
• Etape n°2 : Personnalisation du gabarit de certificat Enrollment Agent
• Etape n°3 : Personnalisation du gabarit de certificat Smard Card User
• Etape n°4 : Génération de la carte à puce « Administrateur »
• Etape n°5 : Génération de la carte à puce « ITManager »
• Etape n°6 : Génération de la carte à puce « SimpleByDesign »

Enfin, pour cette série de billets, je remercie la société GEMALTO (Mr GIRARDIN) pour les cartes à puces Dot.Net et les lecteurs qui vont avec.

Benoîts – Simple And Secure By Design (J’insiste sur le Secure)

le Split-Tunneling est le mode de fonctionnement par défaut de DirectAccess pour traiter les flux qui ne sont pas à destination du réseau interne de l’entreprise (donc pas référencés dans la NRPT).

Ce mode de fonctionnement par défaut diffère des solutions VPN/SSL existantes. Il favorise l’utilisateur en situation de mobilité car il n’est pas nécessaire d’encapsuler tous les flux sortants de son poste de travail, c’est le choix de Microsoft.

Comme indiqué dans notre session, il existe un mode “Forced Tunneling” permettant de configurer DirectAccess de la même manière que les solutions de VPN/SSL du marché. Sa mise en œuvre consiste à :

• Indiquer dans la NRPT que toutes les demandes DNS doivent être traitées par les serveurs DNS IPV6 (caractère joker)
• Configurer le poste de travail pour encapsuler tous les flux sortants.
• Autoriser la résolution des noms externes sur les serveurs DNS IPV6 (roots hints ou forwarders)

Note : Le mode « Force Tunneling » aura pour conséquence que seul le protocole « IPHTTPS » sera utilisable.

Maintenant, le mode Split-Tunneling doit il est considéré comme un risque?

Dans un scénario Split Tunneling, le risque serait qu’étant connecté à la fois à Internet et l’entreprise, la machine pourrait jouer le rôle de routeur entre les deux réseaux.

DirectAccess impose une authentification ainsi qu’un chiffrement des flux avec des règles IPSEC au niveau du pare-feu coté client. De ce fait, tout flux non autorisé est automatiquement refusé. Donc, le mode “Split-Tunneling” n’est pas moins sécurisé que le mode “Force-Tunneling.

Benoîts – Simple and Secure by Design (j’insiste sur le Secure)