[Bug]: Connecting to LDAP auth backed ejabberd 24.06 fails with SASL2-SCRAM unsupported error about monal HOT 6 CLOSED

That should not happen since the app has an internal counter to check if it ever succeeded using SASL2 with SCRAM. Can you provide a logfile via email to [email protected]

See https://github.com/monal-im/Monal/wiki/Introduction-to-Monal-Logging

from monal.

Please send the 2 newest logfiles to counter a possibly rotated logfile.

from monal.

Log files have been sent as requested.

from monal.

from monal.

I need more logfiles (see my mail).

In the meantime some explanations:
Monal offers only PLAIN auth for SASL1 and only SCRAM for SASL2.
The database has a field recording if SASL2 was used at least once and that disables SASL1.
The database has a second field recording if PLAIN auth is needed on a server and if so, SASL2 isn't tried, falling back to SASL1.
If Monal sees that SASL2 with something better than PLAIN is advertised during SASL1 authentication, it switches that "plain needed" flag off and restarts authentication.
This retriggered auth will use SASL2 and thus switch the "SASL2 used at least once" field in the db on. This flag will prevent SASL1 auth.

To allow seamless server upgrades for accounts already present when the server did only suppot SASL1 and these flags weren't present in the DB, the database upgrade to Monal 6.2 flipped the flags to plain_activated=true, supports_sasl2=false (default would be both false).

And I guess here is the bug you hit: these flags were only flipped for accounts not enabled and having the supports_sasl2 set when the DB upgrade was done. That's obviously wrong, since already activated accounts not supporting SASL2 should have plain_activated=true, too, to allow seamless upgrades later on.

Nonetheless more logs would be good to check my theory.

from monal.

Since this was a security relevant bug, the only solution for you is to remove the account from monal and set it up again. I'm sorry.

from monal.