Zammad: La réinitialisation du mot de passe utilisateur ne fonctionne pas - l'utilisateur ne peut pas se connecter

Même problème pour moi.

La réinitialisation du mot de passe de l'utilisateur dans admin ne fonctionne pas non plus.
La réinitialisation du mot de passe par e-mail fonctionne et les utilisateurs peuvent désormais se reconnecter sans problème.

Nous avons modifié les algorithmes de cryptage, mais les anciens mots de passe devraient être compatibles.

@thorsteneckel des idées ?

PS : Zammad a déjà un backend d'authentification LDAP simple (depuis 1.0). Cela n'a pas changé dans la 1.3, vous pouvez ignorer le message "Connexion refusée" pour le moment.

La réinitialisation du mot de passe de l'utilisateur dans admin ne fonctionne pas non plus.

Pareil ici

La réinitialisation du mot de passe par e-mail fonctionne et les utilisateurs peuvent désormais se reconnecter sans problème.

Cela marche

Je vais regarder ! Désolé pour les circonstances.

Nous avons réexaminé les modifications et essayé de reproduire le comportement. Tout fonctionne comme prévu :/

Pouvez-vous jeter un œil à votre base de données : y a-t-il des PW commençant par {sha2} ? La connexion est-elle possible pour ces utilisateurs ? Il ne devrait y avoir aucun hachage de mot de passe ne commençant {sha2} ou $argon2i$ . Pouvez-vous le confirmer ?

Serait-il possible d'avoir une session à distance pour jeter un œil au système et à la base de données pour vérifier les différences ? Vous pouvez nous contacter via [email protected] .

Ce que nous avons fait:

• Insérez le hachage SHA2 pour PW 'test123' ( {sha2}ecd71870d1963316a97e3ac3408c9835ad8cf0f3c1bc703527c30265534f75ae ) dans la base de données pour un utilisateur de test
• Confirmez le hachage de la base de données en tant qu'utilisateur pw via la console rails ✅
• Essayez de vous connecter avec PW 'test123' ✅
• Changer le PW de l'utilisateur via l'utilisateur admin dans l'interface admin ✅

Ce serait bien de savoir d'où cela vient....

Presque tous nos agents ont des mots de passe "$argon2i$" dans la base de données. La réinitialisation dans la gestion des utilisateurs ne fonctionne pas pour ceux-ci.

Ah ok! Je pensais que nous avions quelques problèmes avec l'ancien support SHA2. Étrange. Quelqu'un d'entre vous a-t-il des problèmes lors de la mise à jour ? Je demande parce que Zammad génère un secret aléatoire qui est utilisé pour la génération du mot de passe. Ce secret ne devrait être défini qu'une seule fois et ne devrait plus changer -> sinon, il cassera tous les mots de passe 💡 Je ne vois aucune situation dans une configuration normale où ce secret change après avoir été défini une fois. J'ai l'impression que c'est la cause principale mais je ne suis pas en mesure de dire pourquoi.

JFI : Toujours pas capable de le reproduire. Merci à @michilehr pour les données cependant... 👍

@michilehr @jannheider y a-t-il une chance que vous ayez rencontré des problèmes ou un comportement inhabituel lors de la configuration ou de la mise à jour de la base de données / du système ? Comme la configuration, l'utilisation, la configuration à nouveau ? Ou transférer la table utilisateur d'une instance de Zammad à une autre ?

@shakalandy ?

Nous n'avons jamais eu de problèmes lors de la mise à jour, nous utilisons Zammad depuis la première version.
Installé à partir du référentiel CentOS sur un serveur propre où rien d'autre n'a été installé.
Aucun transfert de table utilisateur.

Il est très plausible qu'il y ait un problème avec la clé secrète.
Quoi qu'il en soit, pourquoi ne pouvons-nous pas réinitialiser le mot de passe utilisateur dans l'administrateur, seule la réinitialisation du mot de passe par e-mail fonctionne.

Très étrange. Je ne peux pas non plus reproduire le problème de réinitialisation du PW de l'administrateur 🤔 Une session à distance (TeamViewer oe) serait-elle possible pour jeter un œil au système ? @jannheider

pareil pour nous. Je serais heureux de vous offrir une session teamviewer @thorsteneckel

Merci @michilehr pour le soutien sur celui-ci. Je pense que nous avons trouvé la cause : le compte login_failed ne sera pas réinitialisé après un changement de mot de passe. L'utilisateur ne pourra donc plus jamais se connecter

@jannheider pouvez-vous le confirmer ? Pouvez-vous vérifier si le nombre login_failed pour l'utilisateur concerné est supérieur à la limite ? Vous ne pouvez valider cela qu'en regardant dans la base de données : Table users colonne login_failed . Ce serait bien d'avoir des retours pour s'assurer qu'il ne s'agit que de ce bogue.

Nous allons nous occuper de cela et le réparer.

@thorsteneckel
Je peux le confirmer.
Utilisateur qui ne peut plus se connecter -> login_failed count > 11

Réinitialiser le mot de passe avec "réinitialiser le mot de passe par e-mail", l'utilisateur peut se reconnecter et login_failed count = 0
Testé plusieurs fois

Ce serait bien de voir cela dans l'interface graphique, cet utilisateur est bloqué à cause de nombreux échecs de connexion ;)

Merci pour le débogage !

@thorsteneckel merci pour vos efforts 👍

Merci pour votre soutien les gars. Devrait être corrigé avec le commit ci-dessus. Les retours sont les bienvenus

Désolé les gars, je viens d'installer zammad (debian 9, repo) et j'ai la même erreur. La première connexion s'est bien passée, mais maintenant aucun utilisateur ne peut se connecter. Tous les mots de passe commencent par $argon2i$. Des idées? :(

Salut @fbaeumer - veuillez créer un nouveau problème et remplir le modèle car ce problème est résolu depuis un certain temps.

Je travaille Admin LTE et la mise à jour du mot de passe de connexion ne fonctionne pas correctement.