In this article, I will discuss how to enable Multi-Factor Authentication for all the users in ServiceNow. Enabling Multi-Factor Authentication (MFA) in ServiceNow is crucial for several reasons. Firstly, it adds an extra layer of security to protect sensitive information and prevent unauthorised access. Secondly, it helps to meet regulatory compliance requirements and industry standards. Thirdly, it reduces the risk of security breaches and potential financial losses. In summary, enabling MFA is an essential step in protecting your organization's data and assets in ServiceNow.
As of the Washington-DC release, there are multiple ways to enforce the MFA in ServiceNow, one through the Multi-factor Criteria and another through the Adaptive Authentication and both of these methods/frameworks are available OOB. While the Multi-factor Criteria is used to enforce the MFA only for the users having "privileged roles", I am going to discuss the other approach, using Adaptive Authentication which is simply more robust in terms of crafting more granular conditions and has more flexibility than the former one.
To enable the MFA through adaptive authentication, the admin has to install the Adaptive Authentication (com.snc.adaptive_authentication) and enable the Adaptive Authentication via the property (glide.authenticate.auth.policy.enabled)
Adaptive Authentication setup and configuration link
After enabling the AA, navigate to MFA Context and open the Step-Up MFA Policy (Adaptive Authentication -> Authentication Policies -> All Policies and open the Step-Up MFA Policy). A new policy can be created if the existing OOB Policy is not required to be modified and it can be set as the Step-Up Policy.
In the policy input, there are a few input filters already added out of the box which are User-Based MFA, Role-Based MFA and Authentication Scheme (if MultiSSO External logins plugin is installed on the instance). Before configuring the policy conditions, we need to create two additional filters as per the requirements. If we want to exclude the set of users belonging to a groups or set of users having any specific roles like snc_external, then we need to create a group filter criteria and a role filter criteria like this -
Group Filter Criteria to exmpt the set of users by adding them in the exempted group -
Role Filter Criteria to exempt the set of users having an specific role -
Both the above filter critierias are added into the new policy to enforce the MFA -
Note that the above additional filter criterias are optional and added to provide the additional flexibility while enforcing the MFA over all the users. Also the other existing policy inputs can be kept as well, no need to remove them from the policy input.
Now, to enforce the MFA for all users, consider the following scenarios -
Scenario 1: If the instance is configured with MultiSSO (External IDP login) and most of the end users are already undergoing MFA during login at the Identity provider(Okta, azure etc), and the Admin wants to enable the MFA only for the users who are logging using the username and password (local login), then admin can configure the Policy like this -
Authentication Scheme is Username and Password
AND MFA Exempted User Roles is false
AND MFA Exempted User Groups is false
The two additional filter criteria are MFA Exempted User Roles and MFA Exempted User Groups are added to ensure that if there is any user who needs to be exempted from the MFA, then the admin just has to add it to the exemption list. Similarly, if the users having any specific roles (For ex. the snc_external role) need to be exempted from the MFA, those roles can be added to the exemption list as well.
Scenario 2: If the instance is not configured with MultiSSO (external IDP login) or MultiSSO is configured but MFA is not being enforced at the Identity Provider, then the first filter for the Authentication Scheme can be removed and thus MFA will apply to all the users irrespective of their login method.
Note that in the above case, if MFA is to be enforced on the SSO users as well, then we need to enable the additional property to enforce MFA for sso users - glide.authenticate.mfa.with.multisso.enabled.
Challenges in Enforcing the MFA for all users and their workarounds -
- Integrations Use cases - If there are any third-party integrations with ServiceNow, there are chances of failures of the integrations with the existing user accounts if these accounts are not web service access only enabled. To avoid the Integration failures, please mark the Integration user account as the web service access only, so that the MFA is skipped for such users. Also, such users should have very limited access roles.
- Another use case in which the user identity is getting re-validated (verify if it is the same user or not), in such cases, the same user is already logged in and if the authentication APIs are invoked again from within a logged in session for the same user with username and password credentials, then there will be no impact on such integrations. Authentication APIs are -
- GlideUser.authenticate(username, password);
- GlideUser.authenticateUser(username, password);
- If there is an integration within another third-party website like chatbots etc, and if the users are getting authenticated using Basic Authentication, then the users will be prompted to enter the MFA code if the MFA is enabled for all the users. This is not a blocking scenario since the users will be undergoing MFA if they log directly into the ServiceNow UI.
- If any automated tests execute on the instance and invoke the login API, then these scenarios will also be impacted. Here the workaround is to either disable the MFA on these test instances or to execute the login with the user accounts that have web service access only enabled if they are not doing a UI login.
- For any other use case in which user accounts doing local login and must be exempted from undergoing MFA, can be added into the exempted user groups.
This is always a best security practice to mark the Integration User Accounts as web service Access only as these user accounts have privileged roles and its credentials are shared (and saved for long time into third party systems) and can be potentially exploited to do the login into servicenow UI if not as web service access only. Also such Integration user accounts should be allowed to have the least privileged roles necessary for the integration to work properly.
Additional information about the Interactive and Non-Interactive Users
Why should we always mark the Integration users as Web Service Access Only
