How to show only Email MFA Option to Users In Yokohama

Chris Dea1
Tera Contributor

Hi All,

 

We're going to be upgrading to Yokohama next month and I am starting to prep for mandatory MFA with this release.  At my organization, we serve two distinct user bases, internal customers that sign in with SSO and outside customers who use local accounts we set up for them.  Based on what I've read mandatory MFA is applied to local accounts, but will not be applied to users logging in with SSO.  I am concerned with our outside customers getting prompted to setup MFA and the large support load this could generate... 

 

To minimize confusion after the release, I want to only offer the email OTP option for our outside customers.  These outside customers are non-role'd local accounts and basically use ServiceNow to report errors to us so I am not concerned about them only having email for MFA.  (The fewer the choices the better if you get my drift :).

 

Is there any way I can configure MFA in Yokohama to only show the email option for these non-role'd local users when they get the MFA setup screen when logging into the portal? 

 

(Note: my plan is to set the glide.authenticate.multifactor.self_enrolment_period system property to 0 to force the users to setup MFA on first logon after the upgrade.)  Attached below is a screenshot of what I want to customize -- I only want to show the highlighted email option on the MFA setup for these users.  I've looked through the documentation and I could not see how this is done.

 

ChrisDea1_0-1756227354367.png

 

Thanks in advance for any guidance and assistance.

 

-Chris

6 REPLIES 6

@Chris Dea1 

Did you unchecked this option in properties? 

Enable web authentication (FIDO2) based MFA.

Ambuj Tripathi
ServiceNow Employee
ServiceNow Employee

Hi @Chris Dea1 

 

I see @kaushal_snow has already suggested to use the MFA Factor policies to restrict the external users to only email. This is continuation of the same with few additional details.

 

Here is the screenshot if you are still wondering where to configure it.

 

AmbujTripathi_0-1756843628320.png

 

Coming back to the question, the point here is, to configure the policy to allow/restrict the certain specific factors, you should have a filter via which you can correctly and accurately determine and differentiate if the user is external user or internal user. This can be either -

a) A group filter - create a group and add all the ext users into this group (via background script or as you deem suitable).

b) A role filter - create/use a role and assign it to all the ext users/internal users to determine if this is external user or internal user.

With this, you can use any of the above filter as input in the above mentioned Email MFA factor policy in such a way that for the ext users, the policy always ends up evaluating to true.

For ex - if you created a group filter - extUsersGroupFilter (this group contains all ext users only).

Then your condition could be - extUsersGroupFilter = true (true if ext user, false otherwise).

This will force the ext users to redirect to validation screen after login with only email as factor available.


Additional details -

1) although we force the users to login via email, the users can still navigate to the profile page and manage multi factor page from the profile to enroll themselves into other factors.

To restrict that, you can either disable the link to "configure multi factor authentication" on profile for such users. or possibly, can add additional BRs on respective tables to block new entries into these tables as you find it suitable. Other tables are - sys_user_public_credential (for FIDO factor) and user_multifactor_auth (for TOTP factor).

2) Disabling the other factors like FIDO2 etc will also disable it for the internal users which may not be a desired outcome. so better to use the factor policy to limit factos availability for external users instead and at the same time allow the internal users to use other factors.

3) Disabling the new MFA setup screen property ( glide.auth.mfa.ui.v2.enabled = false ) may not come handy here, since this will enforce the TOTP factor instead, which was the de-facto MFA factor for the older version of MFA setup screen.

 

LMK if this works.

 

Cheers!