Be an admin on an up-to-date Discourse site with one or more two-factor keys enabled, such as security keys and authenticator app.
Be able to log in and out successfully with those two-factor keys.
Ensure that the site setting for enforcing two-factor logins is set to “no”.
Delete all of the two-factor items from your (admin) account using the standard UI tools in the Security tab of the admin’s user profile preferences.
Log out.
Expected behavior
Log in to site with username or password; access granted; or
Log in to site with “email me a link”; access granted.
Actual behavior
Both “expected” scenarios fail with an error message, and login is not allowed:
The selected two-factor method is not enabled for your account.
There is no further way to log in with the admin’s account.
It is worth noting that I am not actually locked out of the site in question; I had another session still active on another computer and was able to go over to that session and re-add a token-based authenticator to get back in. However, had I not had another session I would have been “fully” locked out.
Thanks for reporting this. I’ve had it bookmarked for the past few days, but haven’t got around to testing it yet. I assume that what you’re reporting is correct, but will take a close look at it next week.
I guess this is the bug? We should not allow that if your site setting says that all admins must have 2fa enabled.
I think you are not fully locked out, you can use the console to recover now, but we should not make it easy for you to create a pathological situation.
I’m not quite sure that’s the right logic? I didn’t have enforce second factor on anything but the default value of “no” and it’s not really safe to assume that every installation has more than one admin account. It seems that once the 2FA keys are removed from the profile, some other flag is not being removed somewhere…
I think you are not fully locked out, you can use the console to recover now
I suppose this is a valid emergency workaround although it may be beyond the skills of an admin who does not also manage their server and they might have to track down a sysadmin.
@Osama pendant que vous êtes dans le code, peut-être :
SI l’utilisateur ne sera pas autorisé à se reconnecter après avoir supprimé cette 2FA (dernière 2FA qu’il possède et 2FA requise pour le compte selon les paramètres de niveau de confiance / paramètres d’administration)
ALORS ne pas lui permettre de supprimer la dernière 2FA et afficher une erreur.
Je pense avoir été touché par le même bug (Discourse version 2.7.10, mis à jour aujourd’hui).
J’ai obtenu les droits d’administrateur et activé la 2FA. Plus tard, j’ai créé un second utilisateur pour moi-même à partir d’un autre e-mail, à utiliser uniquement pour l’administration, et j’ai accordé à celui-ci les droits d’administrateur.
Ensuite, j’ai retiré les droits d’administrateur de mon utilisateur d’origine et supprimé toutes les méthodes 2FA. Maintenant, mon utilisateur d’origine rencontre le comportement d’erreur mentionné par l’OP.
Je n’ai pas d’accès à la console de ce serveur. Le site n’impose pas la 2FA pour les administrateurs.
Quelqu’un pourrait-il détailler exactement ce qui doit être fait à la console pour résoudre ce problème.
Au fait, les raisons pour lesquelles j’ai fait cela sont que je veux être soumis aux permissions et notifications normales (ou non) pour les groupes privés sur le site via mon utilisateur normal, peut-être avec le mode liste de diffusion activé. Je n’ai pas besoin de la friction supplémentaire de la 2FA en tant qu’utilisateur ordinaire.
Bien sûr, l’utilisateur administrateur peut tout voir, donc c’est basé sur la confiance qu’il ne fouine pas inutilement. Cet utilisateur peut désactiver toutes les notifications et ne pas activer le mode liste de diffusion.
@sam Vous dites de manière alléchante que ce problème peut être résolu via la console, sans dire ce qui doit être fait spécifiquement. J’apprécierais vraiment un indice sur la façon de résoudre ce problème particulier.
Je ne pense pas, car le compte a déjà la 2FA désactivée, ou pour être plus précis, a supprimé toutes les méthodes 2FA de son compte (la 2FA est indiquée comme « non » dans le profil), mais la connexion essaie toujours d’utiliser la 2FA.
Ce guide s’adresse à un utilisateur qui a activé la 2FA mais a perdu/oublié son moyen de générer un jeton valide.
SOLUTION : En tant qu’utilisateur admin, visitez la page de détails de l’utilisateur bloqué, faites défiler tout en bas et cliquez sur le bouton rouge Impersonate.
Ensuite, dans les préférences de l’utilisateur, ajoutez une méthode 2FA. (vous devez avoir le mot de passe de l’utilisateur pour ce faire)
Le secret 2FA doit être donné à l’utilisateur bloqué.
Dans ce cas, je suis les deux utilisateurs, donc ce n’est pas une tâche difficile
La suppression de la 2FA en appuyant sur le bouton « Tout désactiver » se comporte-t-elle différemment de la suppression de la dernière méthode 2FA ? C’est-à-dire, cela la supprime-t-il sans vous bloquer ?
J’ai pu reproduire ce problème et trouver une solution en utilisant la console.
La reproduction est légèrement différente de la description dans le premier message. L’étape 2 est cruciale, les étapes 3 et 4 sont moins importantes.
Soyez un utilisateur administrateur sur un site Discourse à jour avec une ou plusieurs clés de double authentification activées, telles que des clés de sécurité et une application d’authentification.
Activez les codes de sauvegarde
Soyez capable de vous connecter et de vous déconnecter avec succès avec ces clés de double authentification.
Assurez-vous que le paramètre du site pour forcer les connexions en double authentification est défini sur « non ».
Supprimez tous les éléments de double authentification (authentificateurs et clés de sécurité) de votre compte administrateur en utilisant les outils d’interface utilisateur standard dans l’onglet Sécurité des préférences du profil utilisateur administrateur.
Déconnectez-vous.
Ce qui se passe, c’est que si tous les éléments de double authentification ont été supprimés, les codes de sauvegarde sont toujours présents dans la base de données, et la double authentification n’est pas considérée comme désactivée lors de la connexion.
Comme il n’y a plus d’authentificateur ni de clé de sécurité, l’utilisateur ne peut pas utiliser les codes de sauvegarde.
Une fois que tous les authentificateurs et clés ont été supprimés, les codes de sauvegarde ne peuvent même plus être supprimés dans le Profil - Sécurité.
Correction proposée : Lorsque le dernier élément de sécurité est supprimé de l’utilisateur, les codes de sauvegarde doivent également être supprimés.
Solution de contournement : supprimez tous les enregistrements UserSecondFactor pour cet utilisateur de la base de données.
Est-il possible qu’une correction soit implémentée pour cela dans une nouvelle version de Discourse ? Cela m’est arrivé exactement aujourd’hui et ce fut une corvée de récupérer mon compte.
J’ai le même problème avec un utilisateur qui se plaint de ne pas pouvoir se connecter. Cet utilisateur avait activé l’authentification à deux facteurs (2FA) sur son compte à un moment donné, mais l’a ensuite supprimée. Le message d’erreur qu’il reçoit lorsqu’il essaie de se connecter est :
La méthode d’authentification à deux facteurs sélectionnée n’est pas activée pour votre compte.
Depuis le menu administrateur, je vois que le profil de l’utilisateur indique « Authentification à deux facteurs » comme « Non ».
Comme il est mal vu de demander le mot de passe de l’utilisateur, j’ai essayé de changer son e-mail, ou d’ajouter un e-mail secondaire que je contrôle. Cependant, après avoir cliqué sur « Confirmer » sur l’URL de l’e-mail de confirmation, j’obtiens cette erreur :
La méthode d’authentification à deux facteurs sélectionnée est invalide.
… et l’e-mail n’est pas modifié/ajouté.
Je n’ai pas accès à la console ou à la base de données pour cette installation Discord car elle est « gérée ».
Y a-t-il autre chose que je puisse essayer ? Ou l’utilisateur est-il bloqué hors de son compte pour toujours ?
Je n’ai pas accès à la console discourse, car il s’agit d’une instance discourse « hébergée ».
Les administrateurs doivent pouvoir effacer l’authentification à deux facteurs (2FA) depuis l’interface d’administration. Il est extrêmement peu professionnel de devoir demander à nos utilisateurs leurs mots de passe.
C’est clairement un bug majeur qui doit être résolu. Comment pouvons-nous signaler formellement cela et suivre sa résolution ?
En tant que projet OpenSource avec une instance discourse hébergée, je ne peux pas accéder à la console ou à la base de données, je n’ai que l’interface d’administration.
En fait, je ne suis pas d’accord. Lorsque la 2FA est désactivée, les codes de sauvegarde de la 2FA doivent être complètement ignorés et ne pas avoir d’importance du tout.
En corrigeant cela au mauvais endroit (lorsque la dernière méthode de 2FA est supprimée, supprimer les codes de sauvegarde), nous avons toujours des personnes qui ne peuvent pas se connecter et qui ont simplement abandonné sans signaler.
En corrigeant le bug réel (en tenant compte des codes de sauvegarde lorsque la 2FA est désactivée), nous corrigeons cela pour 100 % des utilisateurs concernés, immédiatement, au lieu de simplement nous assurer que cela n’arrive pas continuellement à de nouveaux utilisateurs.
Cela a fonctionné pour moi, l’utilisateur m’a donné le mot de passe.
Vous ne devez pas désactiver la 2FA directement, vous devez d’abord :
supprimer tous les codes de sauvegarde 2FA
vérifier trois fois que tous les codes de sauvegarde 2FA sont supprimés
ce n’est qu’ensuite que vous pouvez désactiver la 2FA
En utilisant cette méthode, vous êtes en mesure de désactiver la 2FA. Ceci est vrai à la fois pour les utilisateurs admin qui usurpent l’identité d’utilisateurs pour résoudre ce problème, mais c’est aussi vrai pour tout utilisateur normal qui souhaite simplement désactiver la 2FA.
