OIDC account linking: verification code silently skipped for LDAP users (API returns 200, UI says email was sent)

Summary

When an existing account is backed by LDAP, the OIDC account-linking flow asks for an email verification code that the server never sends. POST /api/user/verification-code returns HTTP 200, so the web UI displays "We emailed a code to <address>. Please enter the code to sign in.", but the server has already decided to ignore the request. The user is left on a code-entry screen waiting for a mail that will never arrive, with no error shown anywhere in the UI.

The decision is deliberate and visible only at debug log level:

DEBUG [src/auth.rs:1850] Verification code request ignored for email
'user@example.com' from <ip>: ldap user

Refusing email verification for directory-backed accounts may well be intended. The bug is that the API reports success and the UI claims an email was sent.

Version

RustDesk Server Pro	1.8.6 (hbbs 1.8.6, hbbr 1.8.6)
Image	rustdesk/rustdesk-server-pro:latest
Digest	sha256:b7c79bf24f178cda9e90cf040405e2c9c5e2cb87b58ba703eb487f48886b04f5
Deployment	Docker Compose, network_mode: host
Host OS	Ubuntu 24.04.3 LTS (x86_64)
Upgraded from	1.8.2

Auth configuration: LDAP against Active Directory, plus a Microsoft (Entra) OIDC provider enabled in Settings → Auth Provider. The account in question was created via LDAP and has one user_third_auth row of type LDAP. It has no OIDC identity linked yet.

Steps to reproduce

1. Configure LDAP so that users are provisioned from the directory, and sign in once so the account exists with a user_third_auth row of type = LDAP.
2. Enable a Microsoft OIDC provider under Settings → Auth Provider.
3. Sign out, then choose the Microsoft provider on the login page.
4. Complete authentication at Microsoft. The provider returns an email address matching the existing LDAP account.
5. The UI shows the linking prompt: "The email (…) in your Microsoft profile is already a RustDesk account. We'll link your Microsoft credentials to this account… To set this up, we first need to verify your identity."
6. Click Next.

Expected

Either the verification email is sent, or the UI reports that email verification is not available for directory-backed accounts and offers a supported way to link (or declines the link explicitly).

Actual

The UI reports that a code was emailed. No email is sent. There is no way to proceed and no error is displayed.

Evidence

Request flow handled by hbbs during one attempt:

method=POST uri=/api/oidc/auth               status=200
method=GET  uri=/api/oidc/callback           status=302   <- Microsoft auth succeeded
method=GET  uri=/static/index.html           status=200
method=POST uri=/api/user/verification-code  status=200   <- reported as success

The corresponding server-side decision:

DEBUG [src/auth.rs:1850] Verification code request ignored for email
'user@example.com' from <ip>: ldap user

The account is located correctly beforehand — the lookup by name misses and the lookup by email hits:

select ... from "user" as a
  left join user_third_auth as b on a.guid = b.user
where a.name = $1                  rows_returned=0
...
where LOWER(a.email) = $1          rows_returned=1

SMTP was never contacted. Over the whole session the only outbound name resolutions were:

2  resolving host="login.microsoftonline.com"
1  resolving host="rustdesk.com"

No lookup of the configured SMTP host appears, confirming no send was attempted rather than a send failing.

SMTP is known good

Ruled out independently, so this is not a mail-delivery problem:

• A message sent from the same container host, using the exact SMTP settings stored in the server's database (host, port, account, credential, from-address), authenticated successfully and was accepted and delivered.
• hbbs logs no SMTP activity of any kind at debug, successful or failed.

Suggested fix

Have POST /api/user/verification-code return an error status and a machine-readable reason when it declines for an LDAP-backed account, so the frontend can surface it instead of showing the code-entry screen. Logging the refusal at info rather than debug would also make this diagnosable without raising the log level.

If linking an OIDC identity to an LDAP-backed account is unsupported by design, it would help to say so at step 5 rather than after the user has already authenticated with the provider.

Start in src/auth.rs around the verification-code request logged at line 1850, then trace POST /api/user/verification-code and the frontend flow that displays the emailed-code prompt. Check how LDAP-backed accounts are declined and how the response is handled. Done means the refusal is reported explicitly with a machine-readable reason and the UI no longer claims that an email was sent or leaves the user waiting indefinitely.