"Ordering" Adaptive Authentication Pre-Authentication Policies

[pbusch]

We have Adaptive Authentication deployed on our instance, and our org requires strong security to prevent any non-authorized endpoint from resolving to our instance login.  

Currently our instance 'IP Address Access Controls ['ip_access.list'] features hundreds of records with 'Type' field value of "Allow" for specific trusted IPs. These "Allow" records are punching holes in the sole record of 'Type' field value of "Deny", which is a range starting 0.0.0.0 and ending 255.255.255.255 ;

Our configuration is following the OOTB docs such as what you shared (https://www.servicenow.com/docs/bundle/xanadu-platform-security/page/integrate/authentication/task/r...); 

The current issue our Trusted Mobile App users are currently experiencing is:  just as the Doc states at the beginning, "You must be in the trusted network to perform the trusted device registration.", anyone whose mobile device is not on an explicitly "Allowed" IP cannot ping the instance despite their "Trusted Mobile App".

This is why we are currently attempting to implement a methodology of configuring the 'Policy Conditions' of our instance 'Pre-Authentication Policy Context' so that the "Trusted Mobile App" is checked BEFORE the "Trusted IP" check.  There is indeed an 'order' field on the Policy Conditions' table, but we have so far had no luck with this.

Any recommendations or guidance is greatly appreciated here.

Thanks.

[Randheer Singh]

Hi @pbusch ,

You have missed an important step that is covered in the post. After activating the pre-authentication context policy, you have to deactivate all inbound IP ranges from the IP access list table.

Thanks,

Randheer

[pbusch]

The issue our org has with this deactivation is that the 403 block disappears and any unauthorized end-point is then able to query the instance to attempt to pre-auth.  Due to the 'Simple List' zero-day scenario that occurred in recent memory [Data Exposure and ServiceNow: The Elephant in the ITSM Room] we need that 403 block in place for non-authorized attempts to auth with the instance. I hope you understand, we cannot risk another potential of a bad actor who can leverage any as-yet-to-be-discovered vulnerability as an attack vector. This would be devastating to our org.

I cannot express enough my appreciation for your advisement thus far, Randeer, you are a truly dedicated and attention-to-detail-focused SN professional.

I will submit that a potential "work-around" here is: if we could 100% without-a-shadow-of-a-doubt deactivate every and all public single-factor portal points. We have already deactivated 'login.do' and 'side_door.do' , however I have not finished the legwork required to come to a place where this assurance can be achieved; frankly, I haven't come to believe we can rule anything else out as a possible access point to our instance [i.e. an unauthorized authentication attempt circumvents our MFA policy by resolving to said 'other' single-factor//local-login portal].

Are we are able to achieve this assurance, we can turn off the IP Address Access Control 'deny' record you alluded to could be deactivated, and this should solve for this entire issue for us.

Sir, are you able to advise on any other other potential signle-factor//logcal-login portals on the platform outside of login.do and side_door.do ? 

Thanks so much.

[Randheer Singh]

Hi @pbusch ,
Let me clarify, adaptive authentication pre-authentication context policy provides the same level of protection as the IP address access control feature for public endpoints.

In addition to IP network-based restrictions that you get with the IP address access control feature, the pre-authentication context policy includes additional features like a Trusted mobile app and location-based allow-deny enforcement.

You can also control the HTTP response code with adaptive authentication properties. For example, some customers prefer to have HTTP 404 in case of an attempt to access outside the trusted network.

Using the property "glide.authenticate.global.blocking_policy.error_code" you can update this.
You do not need to worry about public endpoints like login.do and side_door.do if you are migrating from IP address access control to Adaptive authentication pre-authentication context policy

By the way, I am a PM responsible for both of these products. So, let me know if you want to discuss this further.

Thanks,

Randheer

[Brian S]

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

[Randheer Singh]

Hi @pbusch 
You can follow the steps provided in this article
https://www.servicenow.com/community/servicenow-ai-platform-articles/migrating-from-ip-address-acces...

You don't need to worry about the policy condition order field at the pre-auth policy layer.

After activating the pre-auth policy and Adaptive auth property, you must deactivate the IP address access control IP ranges.

Thanks,

Randheer