Activating LDAP with 2FA enabled locks out admin user

Description:

After activating LDAP-auth the admin user has been locked out of the account and can't log in anymore.

Steps to reproduce:

Some of the steps may or may not be important, this is the full list of steps I did.

1. Setup R.C via docker
2. register it
3. [change to community edition],
4. enable LDAP
5. enable account merges
6. assure admin user is mergeable with an LDAP account, by renaming it (maybe important, that is what I did).
7. Manually sync LDAP.
8. realize LDAP support is buggy or does not support direct login without creating a user account in the community edition (no one can login)
9. try to switch to the free subscription again (seems only to work, by removing the subscription plan on cloud.rocket.chat) and reregistering it.
10. sync subscription
11. Try to login via LDAP

Expected behavior:

Login via LDAP works both in CE and Starter for all users out of the box.

Actual behavior:

⇒ Login/register loop

The admin user can't login, since somehow 2fa via E-Mail is enabled for him.

Solution:

Deactivate / gray out 2FA via mail, when no valid and working SMTP server is configured.
Always require a first E-Mail validation before activating 2FA via mail. Don't handle the existence of a user as validated mail.
Don't assume an E-Mail address, even if it came from LDAP, is valid.
Don't handle the merge of users as user creation.

Server Setup Information:

• Version of Rocket.Chat Server: 6.11.1
• License Type: CE & Starter
• Number of Users: 1 (switched to CE, since we need 35 anyway)
• Operating System: Ubuntu Server 22.04
• Deployment Method: docker
• Number of Running Instances: 1
• MongoDB Version: docker-latest

Client Setup Information

• Desktop App or Browser Version: Firefox, 129.0.2
• Operating System: Win11

Additional context

2fa via E-Mail can't work and actually *must not be enabled, when no SMTP server is installed to register the R.C it is required to have a logged-in admin user reloading the window restarts the process

The cause of this is simple. You have the following design flaws in your code:

2FA via E-Mail requires a configured SMTP server, and should be inactive by default, but it is active for new users.
Merging of LDAP with R.C. users handles this as new user creation. Therefore, when backed by an LDAP user, 2fa is enabled for the admin user.
Somehow, 2FA via mail is activated for merged users even if they never verified their email (impossible without an SMTP Server).

Relevant logs: