Migrating from IP address access control to Adaptive Authentication

[Randheer Singh]

IP address access control

Apply an IP access control to outbound traffic, inbound traffic, or bidirectional traffic. The system only blocks an IP address if a matching Deny rule exists and no matching Allow rule exists. By default, there are no restrictions on access to your instance.

Product Documentation

Adaptive Authentication

Adaptive authentication is a policy framework to enforce contextual authentication controls to the right users at the right time. Adaptive authentication uses authentication policies to evaluate authentication requests and either deny or allow access to your instance based on the specified policy conditions.

Admins can use adaptive authentication policies and contexts to restrict access to the instance for users and APIs based on criteria like IP address, user role, and user group.  

Product Documentation

Why migrate to Adaptive Authentication

1. Condition builder-based policy configuriguration experience to define an allow/deny access scenario

2. Supports trusted mobile app feature. https://www.youtube.com/watch?v=rIQNf4M7LyU

3. Supports CIDR-based IP range definition

4. Use user attributes like role/group membership and authentication methods used for logging in to enforce granular restrictions.

5. Change the error code/message shown for blocked sessions.

6. Enforce step-authentication based on the IP range and user attributes

Activating Adaptive Authentication

Enable Adaptive Authentication (com.snc.adaptive_authentication) plugin

Enabling The System Properties

Steps: -

1. Open Adaptive Authentication > Properties
   1. Adaptive Authentication -> Authentication Policies -> Properties
2. Enable the following properties.
   1. Enable Authentication Policy
   2. Enable Device Trust Flow 

Migrate IP Filter Criteria

1. If you already use the IP address access control feature, IP filter criteria can be created automatically by importing data from IP access control inbound IP ranges.
2. Go to System Security > IP address access control.

3. Click on the “Migrate to IP filter Criteria” related link. This will only appear if active IP ranges are available in the IP_access table for inbound IP restrictions.

 

4. Upon clicking on the UI action, a scheduled job (Migrate IP Address Controls to Adaptive Authentication IP Filter) will start in the background to migrate IP ranges to IP criteria. The job will create new IP criteria. Two IP criteria will be created if both allow and deny ranges are defined.
   1. Is allow Migrated IP Filter
      1.      Consist of all active inbound IP ranges that are of “Allow” Type
   2. Is deny Migrated IP Filter
      1.      Consist of all active inbound IP ranges that are of “Deny” Type

Another example

5. You can go ahead and rename the filter as needed.

6. Once you have migrated the IP ranges, the related link will disappear.

Create IP Filter Criteria

1. If IP ranges are not defined as part of IP access control feature, then the admin can manually create IP criteria.
2. Navigate to Adaptive Authentication -> IP Filter Criteria
3. Create an IP filter as desired. Product doc

Steps To Configure Policy

1. Navigate to Adaptive Authentication -> Pre-Authentication Context

2. Change the Default Policy to “Allow Policy” and observe that the “Allow policy” is mapped to Allow Access Policy.

3. Open the Allow Access Policy reference record; click on the Edit button for Policy Input.

4. Select the IP filter created/migrated in the last step

5. Also, select the Trusted Mobile app filter and save the record.

6. Open Policy Conditions, and click on the “New” button
7. Create OR condition as below
   1. The trusted IP range is true, OR the Trusted Mobile app is true.

8. Save the Condition
9. Instance access would be allowed from all the devices connecting from a trusted network. Access originating from untrusted networks would be allowed only from trusted mobile apps. All non-trusted mobile app access would be blocked from untrusted networks.
10. Users would be forced to undergo the device registration process upon accessing the instance from Mobile apps.

Deactivate IP address access control

1. Deactivate all inbound IP ranges, as you have already migrated to pre-auth

Mobile App Registration Process

1. Users will see the device registration screen when clicking on the instance name.

 

2. Users must open another session from a desktop/laptop connected to the trusted network.

 

3. Click on the "Register a trusted mobile device" related link in the user profile section. 

4. Click on Add New Trusted Device Link

4. Scan the QR code from the mobile app

 

6. Upon successful validation, the device will be registered to the user account, and the user will be redirected to the login page.

After completing these steps users connecting from the trusted mobile device would be able to access the instance from outside the trusted network as well.

[Daichi Ishikawa]

@Randheer Singh 

Thank you for your valuable article!

I finished migrating from IP address access control to Adaptive Authentication (IP filter criteria) successfully on our development instance!!

However I have to consider how we manage IP addresses.

IP address access control has [description] field, so we can note what use for, but IP filter criteria does not have some fields to note it. What do you manage it by??

Does anyone have some answer to this question?

Any help would be greatly appreciated!!

[Randheer Singh]

Unfortunately, the description field is unavailable at the IP range record level. 
For now, you can use the IP criteria description to capture the details.

We will consider adding the description field at the individual IP range and subnet record level.

Thanks,

Randheer

[Daichi Ishikawa]

@Randheer Singh 

Thank you for your quick reply!!

OK, I consider to use the IP criteria description.

[Katie Irvine]

@Daichi Ishikawa @Randheer Singh I have raised an Idea to have the description field added and existing content ported across:  View Idea Page - Now Support (servicenow.com)

Please upvote!

Katie

[Daichi Ishikawa]

@Katie Irvine 

Thank you! I've upvoted!!

[John Anderson]

This is great, thanks for writing it up. I have one question if you don't mind. I don't seem to have the migrate link on the IP Address Access Control screen. Any idea on how I can migrate without that link or at least get the link back? Thanks. 

[Katie Irvine]

@John Anderson the condition on the 'Migrate...' UI action is:

var gr = new GlideRecord('ip_access'); gr.addActiveQuery(); gr.query("flow", "inbound"); gr.hasNext() && GlidePluginManager.isActive('com.snc.adaptive_authentication') && !GlideProperties.getBoolean('glide.ip_address_controls.migrated', false)

So, do you have the Adaptive Authentication plugin installed and is that system property set to False?

[Katie Irvine]

I'm having difficulty setting up the policies/contexts etc.

I'd like to distinguish between interactive and non-interactive (REST) accounts so that:

ALL user traffic (interactive) can access the instance if it comes from a 'trusted' IP address. ☑️ (this works following the instructions above - migrating the allowed and denied IP addresses, then setting the default pre-authentication policy to Allow Access.

For non-interactive accounts (which are used for REST), traffic must be either from a 'trusted' IP address OR from a 'regional IP range' where an OAUTH profile is used.

My question is, do I need to create an Inbound Authentication Profile for every OAUTH profile?  If so, what should be in the API Access Policy?  Just the IP Filter part?

Thanks in advance,

Katie

- 

[John Anderson]

@Katie Irvine - Thanks for your comment. 'glide.ip_address_controls.migrated' was set to True. Setting it back to False has restored the 'Migrate to IP Filter Criteria' link in IP Address Access Controls. 

[Harish V]

@Randheer Singh What do I need to do with IP Address Access Control records after I migrate it? I have enabled Adaptive auth from system property. Is that enough or do I need to set IP Address Access Control records to active-false after migrating?

[Randheer Singh]

Hi @Harish V ,
Yes, you have to set IP Address Access Control records to active-false after migrating. I have added this in the blog in this section.

Deactivate IP address access control

1. Deactivate all inbound IP ranges, as you have already migrated to pre-auth

[Varun Batra]

@Randheer Singh  Can trusted mobile app policy condition be used in post authentication policy context as well? I have a scenario wherein I want post authentication user should be allowed if their mobiles are registered, but it isn't working.  

[Randheer Singh]

Hi @Varun Batra , From the Vancouver release onwards, you will be able to use the trusted mobile app filter criteria in any policy context.

If you can share your use case related to post Authentication context policy and trusted mobile app filter criteria, I might be able to suggest a different policy condition to meet the requirements.

Thanks,

Randheer

[Varun Batra]

Hi @Randheer Singh ,

Here is what I am looking for. 

We have three scenarios where users should be allowed access to the system:

1) Access is from a known IP
2) Access is from a known (registered) device
3) Access is from an external customer (who will be neither at a known IP, nor on a known device)

Although 1 and 2 can be determined pre-authentication, 3 cannot, as customers will be identified either by the role they have or a group that they belong to. For this to happen, the user's record needs to be identified, which can only be post-authentication.

[Varun Batra]

@Randheer Singh  Did you find any work around to the case I shared. 

[Tyler Teter]

I am also experiencing the same issue as Katie in regards to API traffic. A number of our integrations calling ServiceNow aren't functioning because they are coming from a wide range of IP addresses from a cloud provider such as AWS or Azure for example which is used by the vendor. Those ranges could literally be hundreds of IP addresses, and they can change often.

How can we go about excluding REST API traffic from the Adaptive Authentication layer? Part of the problem is that role based auth check can only happen during the post step, vs our current check for IP range or trusted mobile app happen at the pre step.
Do you have any advice for how we can handle REST API traffic through Adaptive Auth policies?

EDIT: I found the solution to just move everything from a Pre-check to a post-check. When you run it as a Post-Check, REST API traffic is never evaluated, and skipped completely. As a safeguard, in case ServiceNow ever changes this, I put a role check condition to allow REST API role users.

[Harish V]

@Varun Batra , In your case pre-authentication might not be possible. Everything would have to be through post authentication.

Settings : 1. pre-authentication - Deny policy (allows everyone)

                 2. Post-authentication - Allow policy and configure all your allow rules

[Harish V]

Hello @Randheer Singh , 

We recently ran into an issue where OAuth does not work when Adaptive is enabled. We are seeing below error message. I can confirm that this is due to Adaptive. I set "Enable Authentication policy" to false and OAuth works fine. Can you please give me some pointers on how to resolve this?

[Randheer Singh]

Hi @Harish V , Do you have a case open where I can get more details about the policies you have configured?

A pre-authentication policy with IP restriction will disallow any transaction (interactive or API) from outside the trusted network.

Also, Have you enabled the ACR context policy?`

[Avinash34]

HI @Randheer Singh We have recently implemented adaptive auth and trusted mobile device ( for now mobile and agent) using pre auth policy which is working as expected. We use notify /twilio to support  SMS and voice channels on the ServiceNow platform for communicating internally with team members. This has been broken since the implementation of adaptive auth , user are not able to acknowledge voice /sms , they will need to respond to sms or press a key for voice call to acknowledge and get assignment to ticket. As the responses will be coming from mobile devices ? how does IP whitelist work in this scenario ?  We have a case opened with SNOW but is there any additional context which you can provide to handle notify /twilio with adaptive auth ?

Thanks,

Avinash.

[Randheer Singh]

@Avinash34 Please check if the IP address of the API request is part of your trusted network. I do not have a complete understanding of Twilio integration. But my assumption is that when the user acknowledges the SMS or presses a key, Twilio will make an API call to ServiceNow to assign the ticket.

If the API call is originating from outside your trusted network, the request will be blocked by the Adaptive Authentication pre-authentication policy.

You can either add the IP range as part of your trusted network (difficult considering Cloud platform IPs are not fixed) or you can move to a combination of post-authentication context policy and API access policies.

[Harish V]

How can I implement REST API access policy with IP control?

I already have 

- Pre-auth  - deny policy - to allow everyone to hit serviceNow

- post-auth - allow policy

          1. to allow trusted IP with SSO

          2. to allow local login users who have a certain role

I would like to make sure,

When someone is using rest, they are not allowed to even hit our end point.

[markholderness]

Hi @Randheer Singh , thank you for this very useful article.

I do have a question about Step 7. You set up the condition "Trusted IP Range is true". I presume if we have migrated from IP Address Access Controls which creates the two filters criteria records"Is allow Migrated IP Filter" and "Is deny Migrated IP Filter" then the condition becomes "Is allow Migrated IP Filter is true"?

Also do I need another condition for the "Is deny Migrated IP Filter" filter criteria? E.g.:

Is deny Migrated IP Filter is false
OR
Is allow Migrated IP Filter is true

[Daniel Savard]

@Randheer Singh In reference to your post at 03:31 on 02-02-2023, it means for each record in the ip_access table there should be a new IP filtering criteria. Then you will have to add each one in the Policy Input and then in the Condition filter.

Is my understanding correct?

[markholderness]

@Daniel Savard That's how I read that too. Though I suppose you can document multiple IP addresses/Ranges in the comments if there are not too many e.g.

xxx.xxx.xxx.xxx - xxx.xxx.xxx.yyy: Acme (US)
xxx.xxx.xxx.aaa - xxx.xxx.xxx.bbb: Acme (Uk)

etc.

This is a bit cumbersome though so it would be much better to be able to attach the comment to each range as per the IP Address Control table. This would make maintaining those ranges much easier. @Randheer Singh in your earlier response you said you would consider this. Is this something that might still happen?
 

[Randheer Singh]

Hi @Daniel Savard , No,
I meant that in the description field of criteria, you can specify the description for ranges.

Please avoid creating policy inputs for each range, it will add a lot of performance overhead. Please refer to this article for best practices.

[Daniel Savard]

@Randheer Singh thanks for the quick answer. So, you said in the original post you are considering adding a description column or something at the range level. Is there anything we can do to make sure this is seriously considered or this has already been decided? Should we open an enhancement request or something like that?

This is really required when you have more than a bunch of ranges in the ranges table.

[AnirbanNL]

Hi @Randheer Singh , thank you for the detailed post. We are planning to switch to Adaptive Authentication and I have two queries/questions. It will be very helpful if you could reply to that

1. In 'IP Filter Criteria', we can only migrate the 'Inbound' IP Address Access Controls?

2. We can keep the 'Outbound' and 'Bidirectional' IP ranges active in IP Address Access Controls?

3. How to we disallow the 'Deny' "Inbound" IP Ranges from IP Address Access Controls in 'IP Filter Criteria'? Like "deny Migrated IP Filter is false"?

Regards

Anirban

[AnirbanNL]

Hi  thank you for the detailed post. We are planning to switch to Adaptive Authentication and I have two queries/questions. It will be very helpful if you could reply to that

1. In 'IP Filter Criteria', we can only migrate the 'Inbound' IP Address Access Controls?

2. We can keep the 'Outbound' and 'Bidirectional' IP ranges active in IP Address Access Controls?

3. How to we disallow the 'Deny' "Inbound" IP Ranges from IP Address Access Controls in 'IP Filter Criteria'? Like "deny Migrated IP Filter is false"?

Regards

Anirban

[andrewrouch]

Hi @Randheer Singh great article.  

We have IP address access controls in place already and will migrate to IP Filters. My question is if we have pre auth policy for IP address range but also want to allow mobile access where the control is authentication with EntraID and being an active user which we can set in post auth context, will the IP address range controls prevent them from accessing at all?

[Brian S]

is there a way to bulk register users? mine are not happy with going through the rigmarole...

[Randheer Singh]

Hi @Brian S ,
The user device needs to exchange secrets with the platform, so the device's one-time registration is mandatory.  

[Brian S]

thanks Randheer - understood.

would and MDM such as intune be able to perform the registration systematically some way?

[andrewrouch]

I can't see a way around getting the shared secret from the profile, but possibly creating a shortcut menu item so the user only has to scan the QR code from the Now app might help.

[Randheer Singh]

@Brian S , Unfortunately, no.  For the trusted mobile app flow to work, secrets need to be shared between the mobile apps and the platform.  Device registration with Intune or other MDM/MAM solutions will not work for this use case.

We can use device attributes in the post-authentication context policy and Zero Trust Access policies.
https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/integrate/authentication/conc...