Wrong password message in generating database key screen

[ccolussi]

Version: 3.1.4.36.

After user change password in AD, in the next login Teampass shows the update password screen, where the user informs old and new password, Teampass shows the message "user not found". So, with admin account, we create a new OTP for this user, and the next login he informs the key and password, Teampass show the message "wrong password". So after this, the user cannot use Teampass.

How to debug this?

[guerricv]

Hello,

Seems to be quite the same issue on my side : New user, well received his code key, login for the first time on TeamPass, generated key is not accepted. Need to disable ldap sync for this user and generate a local password.

[guerricv]

LDAP login shows “wrong passphrase” on TeamPass 3.1.4.36

Our environment: Ubuntu 25.04, Apache 2.4.63, PHP 8.4.5 with php-fpm 8.4, OpenSSL 3.4.1, TeamPass 3.1.4.36.

Symptom

On first-time LDAP logins, the database key/passphrase screen reported that the code was “wrong / not accepted”, and the user could not proceed.

Root cause we found

php-fpm pool saturation was causing the POST that submits the passphrase to time out or not be processed.

• php-fpm log showed:

  WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

• Apache access log had some HTTP 408 around the first-login time window.

To users this looked like “wrong passphrase”, but it was actually a processing/timeout issue.

Fix (no code changes, only fpm tuning)

Adjusted /etc/php/8.4/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 20      ; was 5
pm.start_servers = 4      ; was 2
pm.min_spare_servers = 4  ; was 1
pm.max_spare_servers = 10 ; was 3
pm.max_requests = 500     ; was commented

Then reloaded:

systemctl reload php8.4-fpm
systemctl reload apache2

Result

First LDAP logins + passphrase setup immediately started working for affected users.

How we verified

• No new fpm warnings and no 408s in Apache access log.
• TeamPass logs in DB showed the normal sequence:
  • teampass_log_system: user_mngt / at_user_new_keys, then user_connection / connection, sometimes at_user_keys_download.
  • teampass_users: is_ready_for_usage = 1 and keys present (public_key, private_key, encrypted_psk not NULL).

Quick SQL snippets we used

-- Recent system events for a user (replace USER_ID)
SELECT id, type, label,
       FROM_UNIXTIME(CAST(date AS UNSIGNED)) AS event_time,
       qui, field_1
FROM teampass_log_system
WHERE (qui = USER_ID OR field_1 = USER_ID)
ORDER BY id DESC
LIMIT 200;
-- User ready & keys present?
SELECT id, login, is_ready_for_usage,
(public_key IS NOT NULL)  AS has_pub,
(private_key IS NOT NULL) AS has_priv,
(encrypted_psk IS NOT NULL) AS has_enc_psk
FROM teampass_users
WHERE id = USER_ID;

Extra checks that helped

• LDAP mapping: we saw one failed_auth user_not_exists when a user typed UPN (user@domain) but our mapping expected sAMAccountName.
• Browser/autofill & complexity: for the very first passphrase, ask users to try a 12–16 char ASCII code (no spaces/accents) in a private window to rule out autofill/charset issues.

TL;DR

If you see “wrong passphrase” on first LDAP login but logs show fpm warnings or 408s, it’s likely php-fpm capacity, not a bad code. Increase the pool as above, reload services, and try again. If it still fails, consider running this vhost under php-fpm 8.3 as a compatibility fallback (we’re fine on PHP 8.4.5 once fpm is sized correctly).

[nilsteampassnet]

Many thanks @guerricv for your feedback 👏 I'll capitalize your return of experience and try to return a specific error message.