Evaluation de la solution AuthLite avec les clés de sécurité Yubico

Introduction

Les clés de sécurité Yubico sont conçues pour l’authentification à deux facteurs (2FA) dans les infrastructures informatiques sécurisés. Elles ont notamment été validées par Microsoft dans le cadre du programme « Authentification sans mot de passe » sur Azure Active Directory (Passwordless authentication with Azure Active Directory).

Je me suis interrogé sur les possibilités d’utilisation de ces clés dans un environnement Active Directory « On Premise », sachant que la solution fournie par le constructeur ne permet que de sécuriser les ouvertures de sessions locales pour moi sans intérêt. La référence en la matière semble être AuthLite (https://www.authlite.com/), qui offre une solution logicielle plutôt élégante et assez bluffante pour l’intégration d’une solution 2FA sur Active Directory avec les clés Yubico.

Choix du matériel

Les clés Yubico sont vendues en France notamment sur le site d’Amazon ou je me suis procuré la mienne.

Il s’agit de clés au format USB A, USB C ou Lightning déclinées en différentes tailles :

Ma clé est une « Yubikey 5 » USB A et NFC. Elle coute 55 € TTC chez Amazon ou peut être achetée en volume chez Yubico:

Ca peut paraitre un peu cher, mais ce modèle supporte en contrepartie de nombreux protocoles :

• FIDO2
• FIDO U2F
• SmartCard PIV
• SmartCard OpenPGP
• OATH (TOTP/HOTP)

Le modèle plus simple « Security Key » USB A, vendu 32 € TTC ne supporte que les protocoles FIDO U2F et FIDO2, et donc pas applicable à ce que je souhaite faire:

Hormis ses caractéristiques techniques propres à l’usage que l’on souhaite en faire, les clés Yubico ont la particularité d’être particulièrement robustes :

• Design ultra fin
• Faible encombrement (moins gros qu’une clé de serrure classique)
• Entièrement moulé monobloc
• Pas de batterie
• Etanches à 50 mètres sous l’eau salée
• Fonctionne après :
  • 2 mois dans un lave-linge
  • L’écrasement par une voiture
  • Avoir été ingérée puis …évacuée par un chien

Source : https://www.yubico.com/press-releases/yubikey-survives-ten-weeks-in-a-washing-machine/

Objectif

Mon objectif est de sécuriser les comptes à privilège d’une forêt Active Directory en les protégeant notamment contre les attaques de type « Pass the hash ». La solution AuthLite se prête bien à ce scénario et de façon plutôt simple.

La logique du produit consiste à différencier, pour une population d’utilisateurs donnée, ceux qui se seront soumis à une authentification simple (login + password) de ceux qui se seront soumis à une authentification forte (clé + password). Cette distinction permet de tagger les sessions « 1F » (simple facteur) ou « 2F » (deux facteurs)

Par exemple, John DOE peut se connecter de façon classique avec son login et mot de passe. Il intégrera dans ce cas le groupe « 1F ».

S’il choisit de se connecter avec la clé Yubico qui lui a été affectée, il sera cette fois ci membre du groupe « 2F » en lieu et place du « 1F ».

Le schéma ci-dessous illustre cette logique :

Dans les deux cas, il s’agit du même compte d’utilisateur, avec par conséquent un seul mot de passe soumis aux mêmes stratégies (longueur, complexité, renouvellement …). Seule l’utilisation de la clé lors de la connexion permet de différencier une session taggée « 1F » d’une session taggée « 2F »

Bien entendu, les noms de groupe « 1F » et « 2F » ne sont que des exemples explicatifs et seront par la suite substitués par des noms appropriés à un environnement de production.

Environnement de test

Dans mon environnement de test, je dispose d’une forêt Active Directory simple « CORP.NET ». Cette forêt est portée par un unique contrôleur de domaine fonctionnant sous Windows Server 2019 en mode Core (pas d’interface graphique).

La forêt détient un serveur membre, Windows Server 2019 avec interface grapique, destiné à administrer la forêt Active Directory.

S’agissant d’un environnement virtualisé (VMWare), il est nécessaire de modifier les fichiers de configuration (.VMX) de sorte que les périphériques USB génériques puissent être présentés aux machines virtuelles. Il suffit d’ajouter ces deux lignes dans les fichiers de configuration :

• usb.generic.allowHID = “TRUE”
• usb.generic.allowLastHID = “TRUE”

Installation du produit

AuthLite est disponible en téléchargement ici : https://www.authlite.com/downloads/.

Après avoir récupéré les binaires d’installation (format .MSI), je lance l’installation depuis le shell CMD de mon contrôleur de domaine en mode Core :

L’assistant d’installation se lance et ne présente aucune difficulté :

Seul petit bémol : un redémarrage est nécessaire en fin d’installation:

Analyse Post installation

Après l’installation, j’ai utilisé l’outil « Schema Analyzer » afin de comparer le schéma « avant et après ».

Cette analyse à revelé la présence de 5 classes d’objet supplémentaires ainsi que 22 attributs, tous associés aux 5 classes d’objet ajoutées. Aucun attribut n’est associé aux classes d’objet déjà existantes :

Un navigateur LDAP peut être utilisé pour naviguer dans les partitions Active Directory. Comme indiqué dans la documentation, l’installation crée une partition applicative « AuthLite » dans l’espace de noms Active Directory :

Cette partition applicative sert de stockage à la configuration du produit, on y retrouvera notamment les affectations de Tokens aux utilisateurs (dans notre cas, ce sera des clés Yubico mais le produit supporte aussi les Tokens « soft » OATH/TOTP comme Microsoft Authenticator / Google Authenticator).

Configuration

Après l’installation, il est nécessaire d’obtenir une licence produit. Une licence d’évaluation peut être obtenue sur la page https://www.authlite.com/license (j’ai obtenu mes licences d’évaluation par mail en moins de 30 minutes).

Une fois la licence obtenue, il suffit de l’installer via l’outil « AuthLite Configuration Manager » qui sera le principal outil d’administration de la solution :

Dès lors que le produit est sous licence, il est possible d’attribuer des Tokens aux utilisateurs. Pour les clés Yubico, c’est l’option « Setup a Yubikey Token ». Il suffit de plugger la clé dans un port USB, de sélectionner le compte utilisateur et de cliquer sur « Program AuthLite Key » :

Si la clé est déjà programmée, un avertissement nous met en garde :

C’est tout ! La clé est maintenant associée à John DOE :

Utilisation

Pour utiliser la clé Yubico, John DOE va devoir saisir un code OTP généré de façon unique à chaque appui sur le bouton « Y » de sa clé. Ce code est à saisir dans le champ « User Name » en lieu et place du traditionnel SamAccountName.

Le code à une longueur de 64 caractères, il est à usage unique et chaque appui sur le bouton de la clé en génère un nouveau. Exemple de codes générés en appuyant 4 fois sur le bouton de la clé, les 32 premiers caractères sont liés à programmation de la clé, les 32 suivants sont ceux de l’OTP:

nkgtvbcbeuruhegnuddjrvrtvckrcvleeggndftftkjnfjnujbjjkenbtgiikgui
nkgtvbcbeuruhegnuddjrvrtvckrcvleflvnnrccegbgfdkfdkfeerefedeveihc
nkgtvbcbeuruhegnuddjrvrtvckrcvlekerthtjinfcglfrtgedtbrvrlljthtbh
nkgtvbcbeuruhegnuddjrvrtvckrcvlerjuitigrtitutuucktgjrugvdbubllfv  :

Le service AuthLite fait bien l’association entre l’OTP de la clé Yubico et l’utilisateur John DOE. A ce stade, rien ne diffère entre une ouverture de session traditionnelle et celle effectuée avec la clé. L’utilisateur est tout simplement John DOE et ce qui vient d’être fait ne présente aucun intérêt autre que celui de la démonstration :

Gestion des paires de groupes

Comme expliqué précédemment, notre objectif est de dissocier les droits entre une session classique (1F) et une session Yubico (2F). Cela se traduit concrètement par une association entre des groupes 1F et 2F. La session ouverte sans clé rendra l’utilisateur membre du groupe 1F, la session ouverte avec une clé le rendra membre du groupe 2F

De façon plus précise, nous allons créer une paire de groupes où nous associerons un groupe nommé « AuthLite Domain Admins » (qui sera un groupe 1F) et le groupe « Domain Admins » (qui sera un groupe 2F). Dans un environnement de production, il sera possible d’éviter l’association directe du groupe « Domain Admins » mais il s’agit là d’une présentation « proof of concept » et je choisis de faire simple.

John DOE sera rendu membre du groupe « AuthLite Domain Admins » et par conséquent :

• Ne disposera d’aucun privilège particulier lorsque sa session sera ouverte avec son Login + Password
• Sera Administrateur du domaine lorsque sa session sera ouverte l’OTP de sa clé + Password

Le groupe « AuthLite Domain Admins » ne contient qu’un seul membre : John DOE. John DOE n’est membre que de ce groupe et du groupe par défaut « Domain Users ».

Le groupe « Domain Admins » ne contient qu’un seul membre : Administrator que nous n’utiliserons plus par la suite (assignation d’un mot de passe > 64 caractères + stockage au coffre).

L’association de groupes se fait avec l’outil « AuthLite Configuration », via l’option « AuthLite User Group Pairs » :

On associe le groupe 1F (One-Factor Tag) « AuthLite Domain Admins » avec le groupe 2F (Two-Factor Tag) « Domain Admins »

Tant pis pour les avertissements, on est sur un environnement POC :

Et c’est terminé.

Lorsque John DOE utilise une méthode de connexion classique (samAccountName / userPrincipalName), il est simple utilisateur membre du groupe 1F (AuthLite Domain Admins) :

Lorsque John DOE utilise une méthode de connexion OTP (clé Yubico), il est membre du groupe 2F (Domain Admins) :

Objectif atteint:

• Ouverture de session classique = utilisateur simple
• Ouverture de session Yubico = administrateur du domaine

Il s’agit d’un scénario simple mais pour autant essentiel. L’utilisation des clés Yubico dans un environnement Active Directory me semble vraiment intéressante avec cette solution. D’autres articles suivront, ou nous verrons de quelle façon il est possible de sécuriser également des sessions utilisateurs sur des postes de travail en prenant en compte les accès déconnectés (nomadisme, VPN etc…)

Merci de votre lecture