Archives de catégorie : Smartcard

Windows to go, pas que pour les Geek

Etre Geek, c’est aussi identifier des solutions innovantes qui peuvent apporter un véritable plus dans les projets. Dans le cas présent, les projets de migration de poste de travail. Sur ce point, grand merci à Stanislas Quastana pour la solution SPYRUS WorkSafe Pro :

clip_image001

Cette solution ne doit pas être considérée comme un produit pout "Geek" mais comme un véritable Solution Accelerator pour les projets de migration vers Windows 8. Tout projet de migration vers Windows 8 va impérativement devoir adresser des sujets autour :

  • De la compatibilité applicative
  • Du packaging des applications
  • L’introduction de la virtualisation applicative
  • Introduire de nouvelles fonctionnalités sécurité (Bitlocker, DirectAccess, Smartcard, …)

Par expérience, quel que soit la qualité des intervenants impliqués dans un projet de migration de poste de travail, on tombe invariablement sur la capacité à mettre à disposition les packages applicatifs validés pour pouvoir délivrer le nouveau poste de travail vers Windows 8.1. C’est le principal frein aux projets de migration. Au final, le projet prend du retard, avec risque de ne pas être en capacité de répondre aux exigences business à la source du projet (on ne fait pas de projet pour le plaisir de faire un projet). Un business case a été monté, il est censé avoir mis en évidence des quickwins et donc des réductions de couts.

La solution de SPYRUS (lien) intègre à la fois :

  • Une clé USB prévue pour l’usage Windows To go
  • Assez de capacité pour héberger applications et données utilisateur si nécessaire
  • Une carte à puce intégrée (plus besoin de lecteur)

De mon point de vue, inscrire cette solution dans le cadre d’un projet de migration vers Windows 8.1 doit être pris au sérieux. Le plus grand frein à l’adoption d’un nouveau système d’exploitation dans l’entreprise c’est la disponibilité des applications sur la nouvelle plateforme. Migrer un utilisateur sans ses applications n’a pas de sens. Tout projet de migration de poste de travail doit être en mesure de réduire la phase de coexistence au plus court pour éviter :

  • La double gestion (et donc les double couts)
  • Un allongement de la durée du projet (et donc de son cout)
  • Proposer un retour arrière pour les erreurs de migration (mais pas trop sinon on prend du retard et ça coute cher)
  • La solution du double poste physique qui est un gouffre économique

C’est là que Windows to Go prend tout son intérêt. L’utilisateur en demandant toujours plus, il est prêt à adopter un nouveau système d’exploitation (en changent de PC, cela va de soi) si toutes ses applications sont disponibles.

Dans le cadre d’un projet de migration de postes, la solution de SPYRUS une solution intéressante pour assurer la coexistence entre le legacy et le futur poste de travail. Si toutes les applications ne sont pas encore packagées sous Windows 8, on peut au moins proposer deux postes de travail à l’utilisateur grâce à Windows To go. Certes cela a un cout mais on est capable de rapidement embarquer des utilisateurs et donc accélérer la migration. En plus, cela permet de dissocier les problématiques :

  • On est capable de déployer le nouveau poste de travail rapidement
  • On est capable de maintenir l’accès au poste "legacy" pour certaines applications (un reboot et on retrouve l’ancien poste)
  • C’est l’utilisateur qui peut décider de sa date de migration
  • On peut proposer de l’authentification forte en avance de phase sur les postes "legacy"
  • La migration des données locales est facilité (plus de transfert réseau, c’est que du local)

Lorsqu’on inscrit cette solution dans un projet poste de travail, on peut proposer quelques scénarios intéressants dont l’onboarding rapide :

  1. La mise à disposition de la clé Windows To Go par courrier, y compris à domicile
  2. L’utilisateur connecte la clé Windows To Go à son poste de travail Legacy et démarre Windows 8
  3. L’utilisateur contacte le support pour réaliser l’Offline domain Join en DirectAccess (ben quoi, il fallait bien le caser celui-là)
  4. L’utilisateur réaliser l’enrôlement de sa carte à puce
  5. Installation des applications MSI/APP-V via SCCM même à domicile (Viva DirectAccess)

De là, l’utilisateur a un poste de travail opérationnel sous Windows 8.1 tout en ayant la possibilité de revenir sur son poste "Legacy" en un simple reboot. La majorité des postes de travail étant aujourd’hui des portables, on facilite grandement la migration de ces populations qui ne sont pas souvent dans les locaux de l’entreprise.

Dès lors que toutes les applications ont été validées, l’utilisateur peut passer au bureau pour prendre livraison de son nouveau poste de travail. Si on a bien pensé la gestion de la localisation des données utilisateurs, la migration de celles-ci consistera à réaliser un simple USMT de Windows 8.1 vers Windows 8.1. A la première ouverture de session l’utilisateur récupère donc toutes ses données ainsi que ses applications (SCCM 2012 est user-centric), il n’a plus besoin de la clé SPYRUS, il est possible de recycler celle-ci pour l’onboarding d’autres utilisateurs.

Au final, Windows To Go simplifie grandement la migration vers Windows 8.1, tout en proposant à l’utilisateur d’être early-adopter en toute sécurité. Il existe bien d’autres scénarios d’usages :

  • La mise à disposition d’un poste de travail temporaire en utilisant le portable/tablette personnelle de l’utilisateur
  • Du BYOD maîtrisé (matériel de l’utilisateur mais OS/Applications de l’entreprise)
  • Les partenaires intervenant au sein d’une entreprise pour lesquels on devait fournir un PC
  • Les partenaires intervenant en "remote" pour lesquels on devait fournir PC,accès VPN et token pour authentification forte

Windows to go doit dont être vu comme un véritable accélérateur des projets de déploiement de Windows 8.1, en particulier lorsque la migration doit être réalisé.

Quelques articles/bases à relire sur le sujet :

Quelques sessions Techdays pour réfléchir sur le sujet :

  • Windows 8 et Windows Server 2012: à deux c’est mieux! (SER210)
  • BYOD et Télétravail : Comment autoriser ces nouveaux scénarios avec Windows To Go, Hyper-V client et DirectAccess (CLI314)
  • Nouveautés de App-V 5.0 et intégration avec System Center 2012 (CLI309)

Histoire de montrer que c’est si simple, voilà la commande qui a été utilisée pour provisionner ma clé USB

clip_image002

Et l’utilisation du fichier généré sur mon futur poste de travail.

clip_image003

Et au premier logon sur le domaine, j’étais déjà en DirectAccess. La classe non? Geek oui mais Business focus cette fois.

 

Au passage, grand merci à Stanislas QUASTANA pour m’avoir fait découvrir la solution et la photo.

 

BenoîtS – Simple and Secure by Design but Business compliant

Authentication Assurance

Cette fonctionnalité est propre à Windows Server 2008 R2. Elle permet de détecter le type d’authentification utilisée pour l’ouverture de session. Plus précisément, cette fonctionnalité permet d’adapter le contenu du jeton Kerberos selon le type d’authentification.

 

Très concrètement, il est possible de détecter qu’un utilisateur a ouvert une session avec une carte à puce et non avec son compte utilisateur et d’en tenir compte dans l’accès à des ressources selon l’appartenance à un groupe donné. Dès lors que l’utilisateur a ouvert sa session avec sa carte à puce, il est membre d’un groupe spécifique, ce qui n’est pas le cas si l’utilisateur avait ouvert sa session avec son compte et son mot de passe.

 

Pré-requis

La fonctionnalité n’est disponible que sur les contrôleurs de domaine Windows 2008 R2, ceci implique un mode de domaine configuré au même niveau. Dès que cette contrainte a été levée, on peut s’attaquer à la mise en œuvre.

 

Une histoire de certificats

Tout se passera effectivement dans les certificats. Pour la base de travail, je renvoie vers ma série de billets sur la mise en œuvre de la carte à puce. Je vais donc me limiter aux seules différences avec une mise en œuvre classique. La subtilité consiste en la mise en place. Cela va se passer au niveau des extensions du modèle de certificat, plus précisément au niveau des Assurance Policies.

5

 

On va positionner la “High Insurance Policy”. C’est à celle-ci que l’on va associer le futur groupe de sécurité qui identifiera l’ouverture de session une carte à puce contenant ce certificat. Par défaut, on dispose déjà de plusieurs niveaux (high, medium, Low) mais il est possible de créer ses propres niveaux.

6

Une fois positionné dans le modèle de certificat d’authentification par carte à puce, on en a fini avec le personnalisation du gabarit de certificat.

7

 

Le coté obscur de l’Authentication Assurance

Le coté obscur, c’est qu’il n’y a pas d’interface graphique pour faire le lien entre l’”Insurance Policy” et le groupe de sécurité que l’on veut utiliser pour identifier l’ouverture de session par carte à puce. D’un autre coté, Microsoft a mit à disposition des scripts PowerShell pour faciliter la mise en œuvre. Ces scripts sont disponibles dans le guide de mise en œuvre de la fonctionnalité “Authentication Assurance”.

 

Microsoft met à disposition deux scripts :

  • Get-IssuancePolicy.ps1 : Permet d’afficher les lien entre les “Assurance Policy” est les groupes”
  • Set-IssuancePolicyToGroupLink.ps1 : Permet de configurer le lien entre les “Assurance Policy” et notre groupe de sécurité

 

Etant donné que nous allons travailler avec des scripts PowerShell, on va commencer par autoriser l’exécution de scripts. Par défaut, pour raison de sécurité, ce n’est pas autorisé.

10

Après, on va commencer par voir quels sont les associations déjà en place avec le script “Get-IssuancePolicy.ps1” et ce pour tous les groupes de sécurité.

11

le script a identifié qu’il y a trois “Assurance ¨Policy” déclaré dans la forêt Active Directory mais qu’il n’y a pas encore de lien avec un quelconque groupe de sécurité. En Parlant de groupe de sécurité, on va quand même penser à le créer ce groupe.

1

Levons maintenant un voile sur le coté obscur. Le lien entre l”Assurance Policy” et le groupe est déclaré dans la partition de configuration. L’information est stockée dans l’objet “Assurance Policy” (objet de type “msPKI-Enterprise-Oid”) et plus précisément dans l’attribut “msDS-OIDToGroupLink” dans lequel on doit stocker le DN du groupe.

 

Le script “Set-IssuancePolicyToGroupLink.ps1” va nous permettre d’établir le lien entre l’Assurance Policy “High Assurance” et le groupe de sécurité nouvellement créé.

12

Une fois l’opération réalisée, une nouvelle exécution du script “Get-IssuancePolicy.ps1” va nous confirmer que le lien est bien en place.

13

Et maintenant coté client

La différence entre une ouverture de session par compte/mot de passe et carte à puce doit être perceptible. Pour cela le plus simple consiste à comparer le résultat de l’exécution de la commande “WHOAMI /GROUPS” dans les deux cas sur le poste client.

LOGONSANSSMARTCARD

Voila pour une ouverture de session avec compte et mot de passe, passons maintenant à l’ouverture de session par carte à puce puisque c’est là que tout se joue.

LOGONAVECSMARTCARD

Immédiatement, on constate deux points. D’une part la présence du groupe spécial “AUTORITE NT\Ce certificat d’organisation”, qui identifier une ouverture de session par carte à puce. L’utilisateur a été positionné comme membre de ce groupe car il a ouvert une session avec une carte à puce contenant un des certificats autorisés pour cet usage, sans distinction.

 

Mais le point le plus intéressant reste la présence du groupe “HighInsurranceGroup” qui est présent dans la liste. C’est bien une ouverture de session par carte à puce mais pas n’importe laquelle mais contenant un certificat bien précis, celui que nous avons personnalisé.

 

Conclusion

Voila pour une mise en œuvre simpliste. Comme indiqué, il est possible de créer ses propres niveaux d’Assurance Policy, ce qui ouvre la porte à des scénarios plus qu’intéressants. Immédiatement, on peut penser à appliquer la fonctionnalité à DirectAccess pour forcer l’utilisation de la carte à puce pour accéder à certaines ressources sensibles de l’entreprise.

 

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

DirectAccess et la magie de la smartcard

DirectAccess + NAP + Smartcard = La solution de mobilité la plus complète. C’est vrai, encore fallait-il creuser un peu plus la chose. Commençons avec la carte à puce. Car mine de rien, c’est un véritable tour de magie.

 

Vue de haut

Lors de la configuration de ForeFront Unified Access Gateway 2010, ce n’est qu’une simple case à cocher mais dont on a du mal à déterminer comment elle sera mise en œuvre. Pour la case à cocher, pas de problème.

SMARTCARD0

 

Une fois la mise en œuvre terminée, on constate toujours la présence de trois stratégies de groupe dont une vide (elle est dédiée au mode Selected Server). Coté contenu, on n’arrive pas à voir la différence avec avant.

 

Coté client, on constate qu’il est toujours possible d’ouvrir une session sans la carte à puce. Conclusion, il n’y a pas d’obligation à utiliser la carte à puce pour l’ouverture de session au niveau du poste ou de l’utilisateur par défaut. C’est à nous de configurer cela. Pour cela, deux options :

  • Au niveau du compte de l’utilisateur
  • Au niveau du poste de travail

 

De mon point de vue, la première option est la plus intéressante car il est plus facile de la débrayer alors que la seconde oblige l’ouverture de session sur le poste.

 

Vue de l’utilisateur

Dès lors que l’utilisateur a ouvert une session, on verra rapidement apparaître l’interface ci-dessous dans la zone de notification :

SMARTCARD1

 

Elle nous invite à insérer notre carte à puce.

SMARTCARD2

 

Ce qu’il faut comprendre, c’est que le Wizard UAG a bien activé la prise en charge de la carte à puce, mais au niveau du tunnel IPSEC initialisé par l’utilisateur. A ce stade, arrêtons nous sur quelques subtilités :

  • L’utilisateur n’est pas obligé d’insérer sa carte à puce, il est juste invité. S’il ne le fait pas, alors, le tunnel IPSEC “Utilisateur” ne monte pas. Pourtant, il est bien authentifié auprès du contrôleur de domaine grâce au tunnel “Ordinateur”.
  • Si l’utilisateur refuse d’insérer sa carte à puce et ferme l’interface, il n’y a plus de notification. Si l’utilisateur veut finalement s’authentifier avec sa carte à puce, il doit verrouiller sa session pour que la notification apparaisse de nouveau.
  • Si NAP est activé, la notification de l’utilisateur ne sera possible que si le poste de travail est reconnu comme conforme.

 

Mais quelle est cette magie?

Ce n’est pas de la magie mais simplement l’implémentation du protocole AuthIP, successeur  d’IKEV2 pour la négociation des tunnels IPSEC. Sa particularité est de permettre de prendre en charge de nouveaux critères pour l’authentification tel que :

  • Le certificat d’état de santé du poste de travail (NAP)
  • Le certificat de l’utilisateur (Smartcard)
  • L’appartenance à un groupe de sécurité

 

Pourtant, on a beau chercher, on ne voit pas comment cela se configure et fonctionne. La raison est simple, il n’y a pas d’interface graphique, tout se passe en ligne de commande avec NETSH. 

 

La première chose à faire, c’est de se positionner dans la stratégie de groupe que l’on va éditer. Dans le cas qui nous occupe, c’est la stratégie de groupe du serveur UAG qui configure AuthIP.

AuthIP0

On découvre deux paramètres très intéressants :

  • AuthzUserGrp
  • AuthzComputerGrp

 

C’est grâce au paramètre “AuthzUserGrp” que le tunnel IPSEC de l’utilisateur ne monte que si l’utilisateur est membre du groupe indiqué. Pourtant le groupe référencé ne semble pas très parlant. Cela ressemble juste à un groupe “Spécial” du fait de son SID court.

 

Regardons maintenant du coté du client. Lorsque celui s’authentifie avec une carte à puce, la commande “WHOAMI /GROUPS” nous retourne le résultat ci-dessous :

LOGONAVECSMARTCARD

En regardant bien, on retrouve notre SID “S-5-65-1”, plus connu sous le nom de “Ce certificat d’organisation. Et bien lorsque l’utilisateur s’est authentifié, il a été reconnu que la carte à puce a été utilisée et l’utilisateur a été reconnu comme membre de ce groupe spécial. C’est grâce à cela que le tunnel IPSEC de l’utilisateur va fonctionner. Magique non?

 

Allons plus loin

Par extension, il est donc possible de remplacer le contenu du paramètre “AuthzUserGrp” pour spécifier un autre groupe de sécurité (à condition de le formater la chaîne de caractère au format SDDL strings). On peut donc spécifier d’autres groupes et développer de nouveaux scénarios tel que :

  • Limiter l’utilisation de DirectAccess aux seuls utilisateurs autorisés (en plus des postes de travail)
  • Limiter l’accès à certains serveurs selon appartenance de l’utilisateur à un groupe, l’utilisation d’une carte à puce et même l’utilisation d’une carte à puce bien spécifique (Authentication Insurance)
  • Limiter l’accès à certains serveurs selon l’appartenance du poste de travail à un groupe de sécurité donné

 

Authentication Insurance

Si on regarde encore le résultat de la commande “WHOAMI /GROUPS”, on constate la présence d’un groupe “HighInsuranceGroup”, un simple groupe de domaine. Lui aussi, il n’est présent que parce que je me suis authentifié avec une carte à puce. Oui mais pas n’importe quelle carte à puce. Une carte à puce contenant un certificat bien spécifique.

 

L’authentification de l’utilisateur avec cette carte à puce à positionné l’utilisateur dans le groupe “HighInsuranceGroup”. C’est ce qu’on appelle l’”Authentication Insurance”, une nouvelle fonctionnalité de Windows 2008 R2 que je détaillerai prochainement.

 

Conclusion

Voila pour la magie de DirectAccess avec les Smartcard. Le wizard de DirectAccess fait un peu de la magie car AuthIP n’est pas configurable au travers des GPO. Il n’est possible de le manipuler qu’au travers de la boîte à outil NETSH.EXE. C’est pour cette raison qu’il ne faut surtout pas manipuler les GPO générées avec la console GPMC.

 

Voila de nouveaux scénarios autour de DirectAccess, que je développerai dès que j’aurai un peu de temps.

 

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

DirectAccess + NAP + Smartcard = La solution de mobilité la plus complète

L’équipe WSiXN (Windows Server Information Experience Networking) en charge entre autre de DirectAccess et NAP a enfin mis à disposition un guide de mise en œuvre de DirectAccess intégrant Network Access Protection. L’ensemble est assez complet, couvrant à la fois :

  • L’architecture de la solution globale
  • Sa mise en œuvre détaillée
  • Un guide de mise en œuvre pas à pas.

D’un point de vue purement technique, NAP est mis en œuvre selon le scénario du Health Registration Authority. A noter que ce HRA est localisé en interne, de préférence sur un serveur dédié afin de s’assurer qu’il soit accessible aussi bien par les clients conformes que non conformes.

Donc maintenant, en recombinant mes séries de billets (Les sujets n’avaient pas été choisit au hasard) : DirectAccess + Network Access Protection + Smartcard = La solution de mobilité la plus complète.  La solution est :

  • Transparente pour les utilisateurs
  • Propose une gestion de la conformité LAN/WAN
  • Sécurisée car reposant sur une authentification forte

Il ne faut pas croire qu’on a fait le tour de DirectAccess. Il nous restera pas mal de sujets à développer (haute disponibilité, scénarios IPV6, …). Il y aura donc encore pas mal de séries de billets en perspective.

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

Série Smart Card : Etape n°6 : Génération de la carte à puce "SimpleByDesign"

    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.

    clip_image001

     

    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.

    clip_image002

     

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

    clip_image003

     

    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).

    clip_image004

     

    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.

    clip_image005

     

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

    clip_image006

     

    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.

    clip_image007

     

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

    clip_image008

     

    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.

    clip_image018

 

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)

Série Smart Card : Etape n°5 : Génération de la carte à puce "ITManager"

    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.

    clip_image001

     

    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.

    clip_image002

     

    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.

    clip_image003

     

    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”).

    clip_image004

     

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

    clip_image005

     

    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.

    clip_image006

     

    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 :

    clip_image007

     

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

    clip_image008

     

    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).

    clip_image009

     

    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”.

    clip_image010

     

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

    clip_image011

     

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

    clip_image012

     

    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 :

    clip_image013

     

    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.

    clip_image014

     

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

    clip_image015

     

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

    clip_image016

     

    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.

    clip_image017

     

    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)

Série Smart Card : Etape n°4 : Génération de la carte à puce "Administrateur"

    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.

    clip_image001

     

    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).

    clip_image002

     

    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.

    clip_image003

     

    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!

    clip_image004

     

    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.

    clip_image005

     

    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, …

    clip_image006

     

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

    clip_image007

     

    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" :

    clip_image008

     

    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.

    clip_image009

    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.

     

    clip_image010

     

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

    clip_image011

     

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

    clip_image012

     

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

    clip_image013

     

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

    clip_image014

     

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

    clip_image015

 

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

    clip_image001[4]

     

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

    clip_image002[4]

 

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)

Série Smart Card : Etape n°3 : Personnalisation du gabarit de certificat Smard Card User

    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.

    clip_image001

     

    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.

    clip_image002

     

    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.

    clip_image003

     

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

    clip_image004

     

    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.

    clip_image005

     

    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”.

    clip_image006

     

    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.

    clip_image007

     

    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.

    clip_image008

     

    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.

    clip_image009

     

    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.

    clip_image010

     

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

    clip_image011

 

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)

Série Smart Card : Etape n°2 – Personnalisation du gabarit de certificat Enrollment Agent

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”.

image

 

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.

00 

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.

1

 

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.

2

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.

3

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

4 

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

5 

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”).

6

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

image

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)

Série Smart Card : Etape n°1 – Mise en place de la PKI

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.

image

 

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”.

image 

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.

image

 

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

image

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.

image

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

image

 

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)