Okta FastPass est l’authentificateur résistant au phishing d’Okta, disponible sur les terminaux iOS, macOS, Windows et Android. Il y a quelques années, certains de nos clients nous ont fait savoir que FastPass ne fonctionnait pas correctement dans certains environnements virtuels Windows. Nous avons donc entrepris d’identifier et de résoudre ces problèmes. Cela s’est révélé un défi intéressant.
Dans cet article de blog, nous nous concentrerons sur Okta Verify et FastPass pour Windows. Nous examinerons pourquoi ces outils ne fonctionnaient pas dans certains environnements virtuels et comment les ingénieurs d’Okta ont résolu de manière créative les défis techniques pour intégrer notre authentificateur aux environnements virtuels.
Pour plus d’informations sur FastPass, consultez notre Deep Dive FastPass et notre livre blanc technique sur FastPass.
Pourquoi FastPass ne fonctionnait-il pas dans les environnements virtuels ?
Il existe deux raisons principales pour lesquelles FastPass ne fonctionnait pas bien dans les environnements virtuels. La première concernait certaines de ses dépendances sur le terminal et la seconde était liée à la vérification de l’utilisateur avec Windows Hello. Nous examinerons chacun de ces problèmes en détail, mais avant cela, passons en revue brièvement les types d’environnements virtuels et leurs différences.
Que sont les VDI ?
VDI est l’acronyme de Virtual Desktop Infrastructure, ou infrastructure de bureau virtuel. C’est un terme qui englobe toute infrastructure de virtualisation conçue pour donner aux utilisateurs l’accès à une machine virtuelle sous forme de bureau. Le terme VDI peut se référer à la fois à l’infrastructure et au bureau auquel un utilisateur se connecte.
Les types de VDI
Il existe trois principaux types de VDI :
- VDI persistantes
- VDI non persistantes
- VDI en couches
VDI persistantes
Une VDI persistante est une infrastructure VDI dont l’état et toutes les données de l’utilisateur sont conservés entre les sessions. Par exemple, lorsqu’un utilisateur crée une machine virtuelle sur son ordinateur portable, celle-ci fonctionne comme une VDI persistante. Chaque fois que l’utilisateur se connecte, l’état de son bureau et toutes ses données sont conservés.
Dans un environnement où il existe plusieurs utilisateurs et plusieurs machines virtuelles, l’utilisateur est généralement affecté de façon statique à la machine. Cela signifie qu’un utilisateur se connecte à la même machine virtuelle à chaque fois qu’il se connecte. Pour cette raison, les VDI persistantes sont parfois appelées VDI statiques.
VDI non persistantes
Dans un environnement VDI non persistant, l’état de la machine virtuelle, y compris toutes les données de l’utilisateur, ne persiste pas entre les sessions. La machine virtuelle est effacée ou restaurée à partir d’une image maître entre les sessions. Dans la plupart des environnements, il existe un pool de nouvelles machines virtuelles à partir duquel la machine de l’utilisateur est sélectionnée au hasard. Dans un environnement VDI non persistant, l’utilisateur peut se connecter à une machine virtuelle différente à chaque fois qu’il se connecte.
VDI en couches
Certains fournisseurs d’infrastructure proposent un troisième type de VDI, qui est un hybride de VDI persistantes et non persistantes. Ces environnements sont généralement divisés en couches distinctes. Il y a une couche utilisateur, une couche application, une couche machine, etc. Pour cette raison, nous appelons ces environnements « VDI en couches ». Dans un environnement VDI en couches, l’utilisateur se connecte à une machine virtuelle non persistante, mais un service de profil utilisateur synchronise les données de l’utilisateur afin qu’elles soient conservées entre les sessions. Comme dans un environnement VDI non persistant, l’utilisateur peut se connecter à une machine virtuelle différente à chaque fois qu’il se connecte. Mais comme une VDI persistante, ses données sont conservées entre les sessions.
Les environnements VDI en couches sont le type d’environnement virtuel le plus difficile à supporter, car l’utilisateur se déplace effectivement entre plusieurs machines virtuelles. Nous nous concentrerons sur les défis techniques liés au support des VDI en couches, puis nous aborderons brièvement les défis et solutions également utilisés pour le support des VDI statiques.
Prise en charge des VDI en couches
Afin de prendre en charge les environnements VDI en couches, il fallait prendre en compte quatre composants d’Okta Verify et de FastPass :
- Compte de service utilisé pour protéger la paire de clés cryptographiques de preuve de possession
- Clés cryptographiques protégées par TPM
- Identifiant persistant local d’Okta Verify
- Informations d’identification du terminal signalées au backend Okta
Nous allons examiner chacun de ces composants en détail.
Compte de service Okta Verify
L’une des paires de clés cryptographiques qu’Okta Verify utilise pour l’authentification est la paire de clés de preuve de possession (PoP). La clé PoP peut être utilisée pour l’authentification silencieuse à un seul facteur où il n’y a aucune interaction avec l’utilisateur. Par conséquent, elle doit être protégée pour s’assurer qu’un autre processus sur la machine ne puisse pas y accéder et l’utiliser à l’insu de l’utilisateur. Par le passé, Okta Verify créait un compte Windows local qui était utilisé pour protéger la clé (PoP). Nous appelons ce compte le service Okta Verify, ou compte sandbox. Okta Verify assume l’identité du compte de service pendant les opérations de clé PoP. Étant donné que ce compte est un compte d’utilisateur local, il ne peut pas suivre l’utilisateur entre les machines virtuelles dans un environnement VDI en couches.
Notre solution : pour protéger la clé PoP dans les environnements virtuels, nous avons utilisé la protection par code d’accès. Au démarrage de l’application, Okta Verify dérive un passcode de protection de la clé. Lorsqu’Okta Verify crée une clé PoP à l’aide des API Win32, nous utilisons la fonction NCryptSetProperty avec l’identifiant NCRYPT_PIN_PROPERTY pour définir la propriété PIN sur le handle de la clé, et nous fournissons notre passcode de protection de la clé. La définition de cette propriété indique au système d’exploitation qu’il doit créer une clé protégée par notre passcode. Après la création, lorsque la clé est utilisée, le passcode correct doit être fourni. Cela empêche d’autres processus sur la machine de charger et d’utiliser la clé PoP, car ils ne possèdent pas notre passcode de protection de la clé.
Clés cryptographiques protégées par TPM
Okta Verify protège les clés cryptographiques qu’il crée avec le Trusted Platform Module (TPM) de la machine, si disponible. Même dans de nombreux environnements virtuels, Okta Verify protégera les clés avec le TPM, car de nombreux environnements virtuels disposent de TPM virtuels. Cependant, dans un environnement VDI en couches, Okta Verify ne peut pas utiliser le TPM pour protéger ses clés. Quand Okta Verify protège ses clés avec un TPM, ces clés sont liées cryptographiquement à ce TPM. Si Okta Verify se déplace vers une autre machine avec un TPM différent, comme c’est le cas dans un environnement VDI en couches, il ne peut pas accéder aux clés qu’il a créées et ne peut pas authentifier l’utilisateur.
Notre solution : dans les environnements VDI en couches, Okta Verify stocke ses clés cryptographiques dans un fournisseur de stockage de clés logicielles dans un format non exportable. Le fournisseur de stockage de clés logicielles est fourni et implémenté par le système d’exploitation Windows, qui stocke les clés sous forme de fichier dans l’annuaire de l’utilisateur. Lorsque le service de synchronisation des profils utilisateurs du VDI en couches synchronise l’annuaire de l’utilisateur, toutes les clés de l’utilisateur stockées dans le magasin de clés logicielles seront synchronisées. Consultez la documentation de Microsoft sur le stockage des clés pour plus d’informations.
Identifiant Okta Verify
Okta Verify stocke un identifiant d’application dans le Gestionnaire d’informations d’identification Windows, utilisé pour protéger les ressources de l’application. Okta Verify définissait auparavant la propriété Persist sur l’identifiant sur CRED_PERSIST_LOCAL_MACHINE, ce qui conservait l’identifiant sur la machine locale. Un identifiant conservé localement ne peut pas être accédé par Okta Verify sur une autre machine virtuelle.
Notre solution : pour permettre à l’identifiant de se déplacer avec le profil utilisateur entre les machines virtuelles dans un environnement VDI en couches, nous définissons la propriété Persist sur CRED_PERSIST_ENTERPRISE.
Informations sur le terminal
Okta Verify collecte deux éléments d’information d’identification du terminal qui sont rapportés au backend Okta :
- Le nom du terminal
- L’identificateur de sécurité (SID) du terminal
Dans les environnements VDI en couches, ces deux identificateurs de terminal pourraient changer entre les sessions, ce qui pourrait entraîner un comportement inattendu, tel qu’un échec d’authentification.
Notre solution : pour signaler des identificateurs de terminaux cohérents dans les environnements VDI en couches, nous utilisons le SID de l’utilisateur comme identificateur de base, car il ne changera pas entre les sessions. À partir de celui-ci, nous dérivons un nom de terminal et nous le signalons directement comme le SID du terminal.
Après avoir traité chacun de ces points, Okta Verify était prêt pour les environnements virtuels. FastPass, par contre, ne l’était pas tout à fait. Les utilisateurs ne pouvaient toujours pas effectuer la vérification de l’utilisateur ; nous avions donc encore du travail devant nous.
Vérification de l’utilisateur dans les environnements virtuels
La vérification de l’utilisateur est le processus par lequel un authentificateur (par exemple, Okta FastPass) vérifie que l’utilisateur est présent et qu’il est bien celui qu’il prétend être.
FastPass utilise Windows Hello pour la vérification de l’utilisateur, ce qui permet à l’utilisateur de vérifier son identité avec un code PIN ou une vérification biométrique. Cependant, la plupart des machines virtuelles n’ont pas Windows Hello. Pour permettre aux utilisateurs d’effectuer une authentification à deux facteurs avec vérification de l’utilisateur dans des environnements virtuels, nous avons introduit la fonctionnalité Okta Verify Passcode.
Inscription FastPass
Lors de l’inscription à FastPass, l’utilisateur est invité à créer un passcode à huit chiffres dans Okta Verify.
Lorsqu’Okta Verify crée la paire de clés de vérification cryptographique de l’utilisateur, nous utilisons les mêmes API Win32 pour définir la propriété NCRYPT_PIN_PROPERTY sur le handle de la clé, en fournissant le passcode de l’utilisateur comme valeur. Cela signifie que la clé de vérification de l’utilisateur n’est accessible que lorsque le passcode de l’utilisateur est fourni. Okta Verify ne stocke pas ce passcode : il le transmet simplement au système d’exploitation via les API Win32.
Authentification FastPass
Pendant l’authentification, Okta Verify invite l’utilisateur à saisir son passcode pour effectuer l’étape de vérification de l’utilisateur.
Lorsqu’Okta Verify charge la clé de vérification de l’utilisateur pour signer le JWT de demande d’authentification, nous définissons à nouveau la propriété NCRYPT_PIN_PROPERTY sur le handle de la clé, en fournissant le passcode que l’utilisateur a fourni. Le système d’exploitation gère la vérification pour s’assurer que l’utilisateur a fourni le passcode correct.
Passcode incorrect
Si l’utilisateur saisit un passcode incorrect, il dispose d’un maximum de deux tentatives supplémentaires avant que la demande d’authentification n’échoue.
Étant donné qu’Okta Verify ne stocke pas le code d’accès de l’utilisateur, il ne peut pas détecter directement un code incorrect. Au lieu de cela, il traite les erreurs du fournisseur de stockage de clés pour déterminer quand le passcode saisi par l’utilisateur est incorrect, puis affiche l’erreur « passcode incorrect » à l’utilisateur. Le problème est que l’erreur renvoyée varie en fonction du fournisseur de stockage de clés.
Lorsque la clé est stockée chez le fournisseur de logiciel, le code d’erreur NTE_INCORRECT_PASSWORD (0x80090033) est renvoyé lorsque nous ouvrons la clé et définissons la propriété NCRYPT_PIN_PROPERTY sur le handle de clé avec une valeur incorrecte. Cela nous permet de détecter facilement lorsque l’utilisateur a saisi un passcode incorrect.
Cependant, le comportement du TPM est différent. Premièrement, aucun code d’erreur n’est renvoyé lorsque la clé est ouverte et que la propriété NCRYPT_PIN_PROPERTY est définie sur le handle de la clé avec une valeur incorrecte. Au lieu de cela, un code d’erreur est renvoyé ultérieurement lorsque le handle de la clé est utilisé, par exemple pour hacher des données. Deuxièmement, le code d’erreur renvoyé n’est pas NTE_INCORRECT_PASSWORD, mais est plutôt NTE_PERM (c’est-à-dire, accès refusé, 0x80090010).
Étant donné que l’erreur d’accès refusé est une erreur générique qui peut être déclenchée dans divers autres contextes, nous ne pouvons pas simplement traiter toutes les erreurs d’accès refusé comme des tentatives de passcode incorrectes par l’utilisateur. Nous devons plutôt traiter ces erreurs en fonction du contexte de l’opération. Si nous recevons l’erreur d’accès refusé lors d’une tentative d’utilisation d’une clé de vérification d’utilisateur dont nous savons qu’elle est protégée par un passcode fourni par l’utilisateur, nous traitons l’erreur comme une erreur de passcode incorrect et autorisons l’utilisateur à saisir à nouveau son code.
Prise en charge des VDI statiques
Les VDI statiques étaient beaucoup plus faciles à prendre en charge. Elles fonctionnent de manière très similaire aux machines physiques. Une fois que nous avons résolu les défis liés à la prise en charge des VDI en couches, nous avons pu réutiliser certaines solutions pour supporter les VDI statiques. Le principal défi dans ce cas est la vérification de l’utilisateur. Pour résoudre ce problème, nous utilisons la fonctionnalité Okta Verify Passcode.
Remarque concernant la prise en charge des VDI non persistantes
Okta Verify n’est pas pris en charge dans les VDI non persistantes, car aucune donnée utilisateur ne persiste entre les sessions, y compris les données Okta Verify de l’utilisateur. Si un utilisateur tentait de s’inscrire à FastPass sur une VDI non persistante, son inscription serait perdue après qu’il se soit déconnecté puis reconnecté à l’infrastructure VDI.
Configuration d’Okta Verify pour les environnements virtuels
Afin de permettre aux administrateurs de configurer Okta Verify pour les environnements virtuels, nous avons ajouté un nouveau paramètre de configuration appelé AuthenticatorOperationMode. Il a trois valeurs :
- Normal
- VirtualDesktopStatic
- VirtualDesktopLayered
Consultez notre documentation pour plus d’informations sur la configuration d’Okta Verify pour les environnements virtuels.
Afin de permettre aux administrateurs de configurer Okta Verify pour qu’il utilise Okta Verify Passcode pour la vérification de l’utilisateur, nous avons ajouté un nouvel indicateur d’installation appelé UserVerificationType. Il a deux valeurs :
- WindowsHello
- OktaVerifyPasscode
Pour faciliter la tâche de l’administrateur, nous ajustons la valeur par défaut de l’indicateur UserVerificationType en fonction de la valeur fournie pour l’indicateur AuthenticatorOperationMode.
- Lorsque le mode est Normal, la valeur par défaut de UserVerificationType est WindowsHello.
- Lorsque le mode est VirtualDesktopStatic ou VirtualDesktopLayered, UserVerificationType est par défaut OktaVerifyPasscode.
Pour configurer Okta Verify afin qu’il s’exécute dans un environnement virtuel et qu’il utilise Okta Verify Passcode pour la vérification de l’utilisateur, l’administrateur doit simplement définir correctement AuthenticatorOperationMode, et UserVerificationType sera automatiquement défini sur Okta Verify Passcode.
Consultez notre documentation pour en savoir plus sur la configuration du type de vérification de l’utilisateur dans Okta Verify.
Remarque sur les nouveaux indicateurs d’installation
Étant donné que les indicateurs d’installation AuthenticatorOperationMode et UserVerificationType modifient les fonctionnalités principales d’Okta Verify, leurs valeurs sont définies une seule fois lors de l’installation. Toute modification de leurs valeurs après l’installation n’est pas prise en compte. Ceci est nécessaire pour empêcher Okta Verify de mal fonctionner. Cependant, certains clients ont récemment manifesté leur volonté de migrer leurs utilisateurs d’un type de vérification à un autre après l’installation.
Okta Verify Passcode à la place de Windows Hello sur des machines physiques
Parfois, les administrateurs ne souhaitent pas que leurs utilisateurs utilisent Windows Hello, ou les utilisateurs ne peuvent pas utiliser Windows Hello, même sur des machines physiques. Nous avons donc conçu la fonctionnalité Okta Verify Passcode pour qu’elle fonctionne également sur les machines physiques. L’indicateur UserVerificationType peut être configuré indépendamment de AuthenticatorOperationMode pour activer la vérification de l’utilisateur avec Okta Verify Passcode sur les machines physiques.
Consultez notre documentation pour en savoir plus.
Essai gratuit
Si l’outil vous intéresse, essayez-le. Vous pouvez installer la dernière version de Windows Okta Verify en la téléchargeant depuis le tableau de bord administrateur. Veillez à suivre nos instructions pour configurer Okta Verify pour les environnements virtuels et pour configurer le type de vérification de l’utilisateur.
Vous avez des questions sur cet article de blog ? Contactez-nous à l’adresse eng_blogs@okta.com.
Consultez d’autres articles de notre blog Engineering d’Okta pour approfondir vos connaissances.
Prêt à rejoindre notre équipe d’ingénieurs aussi passionnés qu’exceptionnels ? Consultez notre page Carrières.
Libérez le potentiel d’une gestion des identités moderne et sophistiquée pour votre entreprise. Contactez notre équipe commerciale pour plus d’informations.
