Hiding the "Switch to Email and Password" Sign-In Option for AD/LDAP-Only Deployments

Applies to: Mattermost Server (self-hosted, Enterprise), Authentication settings, applicable to any version supporting AD/LDAP authentication alongside email/password sign-in.

Symptoms: Users authenticated via AD/LDAP can still see and use a "Switch to sign in with email address and password" link on their Security settings page, undermining an AD/LDAP-only authentication policy.

🛑 Problem

The "Switch to Using Email and Password" link in a user's Security settings appears whenever account creation with email and email/username sign-in are enabled server-wide. Organizations that manage authentication exclusively through AD/LDAP may not want any user to be able to opt out of that policy by switching to a local email/password login, but the link is not tied to a dedicated visibility toggle, it is a side effect of other authentication settings being enabled.

Symptoms

• The sign-in method switch link is visible even though the organization only wants AD/LDAP logins.
• Disabling other SSO providers alone does not remove the link.
• Admins are unsure whether hiding the link also blocks the underlying capability, or only the UI element.

✅ Solution

Disabling email/username account creation and sign-in removes the link, since it only renders when those settings are on, and separately disabling authentication transfer blocks the underlying switch capability at the server level, even if a user reaches the switch flow directly.

Disable email-based sign-in and account-creation

1. In System Console > Authentication > Email, set:
   • Enable account creation with email = false (this removes the "Switch to Using Email and Password" item)
   • Enable sign-in with email = false
   • Enable sign-in with username = false
2. In System Console > Environment > Experimental Features, set:
   • Allow Authentication Transfer = false (server-side setting ServiceSettings.ExperimentalEnableAuthenticationTransfer)

Together, these hide the switch option and make AD/LDAP the only viable sign-in method, provided no other SSO providers (SAML, GitLab, Google, Office365, OpenID Connect) are also enabled.

⚠️ Important: These settings are global. Disabling email and username sign-in also affects any local System Admin account that normally logs in without AD/LDAP. Confirm you have System Admin access via AD/LDAP before applying this change, to avoid locking yourself out.

Additional Resources

• Authentication configuration settings