Dans les billets de blog précédents, nous avons vu comment implémenter le service SSO avec ADFS afin d’accéder à une application SaaS avec des identifiants d’entreprise (Application GotoMeeting de la plateforme Citrix OnLine). Nous avons vu que l’accès à l’application se faisait de façon transparente depuis l’Intranet (en SSO), et au travers d’un portail d’authentification par formulaire depuis l’Internet (publication de la ferme ADFS avec Web Application Proxy). Bien que ce ne soit pas avéré dans notre cas, les applications SaaS peuvent potentiellement détenir des informations d’entreprise d’ordre confidentiel (SalesForce, DynamicCRM pour ne citer que celles-ci). Nous allons donc voir comment imposer une méthode d’authentification plus stricte que le simple login / mot de passe en vue de sécuriser les accès effectués à cet espace applicatif depuis l’Internet.
La méthode retenue s’appuie sur l’utilisation de cartes à puce Gemalto IDPrime.Net nativement prises en charge par ADFS (authentification per certificat), mais il est possible de coupler cette plateforme à d’autres systèmes d’authentification propriétaires (soft token, hard token, SMS …)
Objectif
Nous devons nous assurer que les utilisateurs se trouvant en dehors du réseau d’entreprise soient soumis à une double authentification lors des accès à notre application SaaS :
- Authentification par formulaire en première étape
- Authentification par carte à puce pour terminer
Les postes de travail utilisés peuvent être de type « Enterprise » ou « BYOD » mais doivent recevoir un lecteur de carte à puce (lecteur USB par exemple), chaque utilisateur doit disposer d’une carte à puce à son nom et du code PIN associé.
Pré requis
- Un domaine Active Directory
- Une autorité de certification intégrée à l’annuaire Active Directory
- Un serveur ADFS
- Une application fédérée (par exemple https://antoinedentan.wordpress.com/2016/10/13/implementation-du-sso-avec-adfs-et-citrix-online-partie-1/ )
- Des lecteurs de carte à puce
- Des cartes à puce
Station d’inscription des certificats.
Nous devons disposer d’une station d’inscription de certificats qui sera utilisée pour inscrire les certificats d’utilisateur sur les cartes à puce. Il s’agit d’un PC joint au domaine, muni d’un lecteur de carte à puce et sur lequel nous disposons d’un certificat de type « agent d’inscription ». Ce type de certificat est nécessaire à l’inscription de certificats pour d’autres utilisateurs.
Nous effectuerons les opérations à l’aide d’un compte Administrateur du domaine, et demanderons en premier lieu notre certificat d’agent d’inscription via la console MMC « Certificats Utilisateurs » :
Création d’un modèle de certificat « SmartCard Logon ».
Les services de certificats de Windows Server disposent de deux modèles de certificats destinés à être utilisés sur des cartes à puce (SmartCard) :
| SmartCard User | Permet l’ouverture de session, l’authentification de l’utilisateur et le chiffrement de mails |
| SmartCard Logon | Permet l’ouverture de session et l’authentification de l’utilisateur |
N’ayant pas besoin de chiffrer les e-mails, nous nous baserons sur le modèle « SmartCard Logon ». Pour cela, nous allons le dupliquer afin de configurer un modèle conforme à nos besoins. Ces opérations se font depuis la console « Modèles de certificats » :
Une fois le modèle dupliqué, nous le configurons en fonction de nos besoins :
- Fournisseur de cryptographie « Microsoft Base Smart Card Crypto Provider »
- Le nom du sujet inclut l’adresse de messagerie en plus de l’UPN
- Délivrance du certificat soumise à une signature associée à un certificat « Agent d’inscription »
- Le droit d’inscription pour les Administrateurs du domaine
Une fois le modèle configuré, il faut encore l’ajouter à la stratégie d’inscription de l’autorité de certification :
Gestion des points de distribution de la CRL.
Il est possible qu’après son émission, un certificat doive être révoqué (l’utilisateur a quitté l’entreprise, le support du certificat a été volé ou perdu …), on utilise pour cela une liste de révocation des certificats nommée CRL (Certificate Revocation List). Cette liste est publiée sur des points de distribution nommés CRL-DP (CRL Distribution Point), qui sont référencés sur chaque certificat émis par une autorité de certification. L’idée est de permettre à tout élément applicatif faisant usage d’un certificat d’en vérifier le statut de révocation en consultant la CRL au travers des points de distribution référencés sur le certificat en question.
Par exemple, le certificat du site https://www.google.com indique l’URL de publication de la CRL, l’accès à cette URL permet de télécharger le fichier GIAG2.CRL qui détient les certificats révoqués, la date de révocation et la raison pour laquelle ils ont été révoqués :
En ce qui concerne notre environnement de test, le serveur WAP procédera à la vérification du statut de révocation et l’accès à l’application échouera si ce contrôle n’est pas possible ou si son résultat montre un statut révoqué (il est en fait possible de désactiver ce contrôle mais en terme de sécurité ça n’a aucun sens, si vraiment vous voulez le faire, il faut mettre à 1 la valeur de registre DefaultSslCertCheckMode comme décrit sur la page https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/ )
Concrètement :
- Notre client va devoir s’authentifier auprès du serveur WAP (authentification par formulaire puis par certificat)
- Le serveur WAP va authentifier l’utilisateur par son login puis par son certificat
- Le serveur WAP va s’assurer de la validité du certificat puis de son statut de révocation
Si tous ces critères sont satisfaits, l’utilisateur aura accès à l’application.
Notons ici un point important : la communication entre le client et le serveur WAP se fait en HTTPS pour l’authentification par formulaire, mais sur le port TCP 49443 en ce qui concerne l’authentification par certificat.
Les accès depuis certains emplacements risquent donc d’échouer si ces protocoles ne sont pas autorisés sur les réseaux clients (par exemple les hôtels, aéroports etc … qui n’autorisent souvent que le http et https).
Ce point est documenté sur Technet : https://technet.microsoft.com/en-us/library/dn486819.aspx
Tout ce cheminement implique que les points de distribution de la CRL soient correctement renseignés sur un protocole accessible aux clients susceptibles de demander le statut de révocation d’un certificat (dans notre cas il s’agit du serveur WAP). Les CDP étant renseignés sur chaque certificat lors de son émission, il convient de traiter ce point avant J.
De façon résumée, il s’agit d’un paramétrage au niveau de l’autorité de certification sur lequel nous devons préciser que la CRL sera accessible en http et qu’elle devra être publiée sous forme de fichiers sur le chemin correspondant au site Web indiqué dans le protocole http. Dans notre cas, l’autorité de certification et le site Web correspondant se trouvent sur le contrôleur de domaine, nous sommes sur un environnement de test, mais dans un environnement de production, il conviendrait de dissocier tous ces rôles.
Inscription d’un certificat au nom d’un utilisateur tiers
Il reste à générer des certificats pour nos utilisateurs. Cette opération se fait sur la station d’inscription de certificats, via la console MMC « Certificats Utilisateur », ou nous allons utiliser notre certificat d’agent d’inscription pour demander un certificat « SmartCard Logon » pour un autre utilisateur :
L’inscription du certificat sur la carte à puce nécessite d’en connaitre le code PIN. Sur les cartes IDPrime.NET, le code par défaut est 0000
Sur le certificat généré, nous pouvons vérifier que les CDP correspondent bien à ce que nous avons renseigné sur notre autorité de certification :
Sur notre serveur WAP, nous pouvons vérifier le statut d’un certificat avec l’utilitaire CERTUTIL. La commande permettant cette vérification est :
Certutil –f –urlfetch –verify <certificat.cer>
Si le CDP n’est pas disponible (site web arrêté), la vérification n’est pas possible :
Si le certificat est révoqué :
Si le certificat passe le test de révocation :
Configuration de la plateforme ADFS
Nous disposons à présent de tous les éléments permettant d’activer l’authentification par certificat. Il nous reste à activer l’authentification multifacteur (MFA) aux accès externes sur notre plateforme ADFS. Nous devons pour cela modifier la stratégie d’authentification. Direction la console ADFS :
Nous choisissons d’appliquer aux accès externes une authentification MFA par certificat :
Validation fonctionnelle
Pour valider le fonctionnement, rendez-vous sur la page d’accueil de notre application. Le formulaire d’authentification nous est présenté :
Une fois la première étape passée, il nous faut choisir un certificat parmi ceux présents dans notre magasin de certificats :
S’agissant d’un certificat sur une carte à puce, il est nécessaire de saisir le code PIN :
Après cette double authentification, nous accédons à notre espace applicatif :
Voila qui clôt cet article sur l’authentification MFA avec ADFS. Merci de votre lecture.
Une réflexion au sujet de « Implémentation du SSO avec ADFS et Citrix Online – partie 3 : Authentification MultiFacteur par carte à puce »