"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]

The order field does not help here.

The mobile can be connected to any network, but to generate the QR code, the user needs to have a session on their laptop or desktop that is connected to the trusted network.

The above step is a pre-requisite for the trusted mobile app registration.

[pbusch]

Hi Randheer,

This is tunderstood that a user must be on a trsuted network to log into Desktop UI in order to generate said QR code, and the mobile device scanning th QR to be on a trusted network as well.

This is not the issue here.

The issue here is after a user has taken the above steps to establish the trust, according to SN documentation that mobile should now be able to authenticate with the instance via mobile app from an outside network. 

This is not what we are experiencing; rather, the 'Deny' ip_access record is blocking the mobile app via pre-auth policy;  this is what we are trying to solve for -- ensure our instance assesses "Trusted Mobile App" pre-auth condition BEFORE the "Trusted IP" pre-auth condition. If our instance does the mobile trust check first, then this should solve the issue here for Trusted Mobile App while retaining the IP Trust security for any other use-cases.

Thanks,

Pat

[Randheer Singh]

Hi Pat,
The user must be on a trusted network to log into Desktop UI in order to generate said QR code: True
The mobile device scanning th QR to be on a trusted network as well.: Not true.
The mobile device can be on any network.

While defining the policy for the pre-auth context, we typically suggest that customers set the Allow policy as the default policy.

So that understanding the conditions is straightforward.

Conditions: Allow Access to the instance if
Trusted network is true 

OR Trusted Mobile App is true

Please refer to the policy example suggested in this community article for detailed steps.

Thanks,

Randheer

[pbusch]

Hi Randheer,

What you advised is the setup we've implemented; except instead of the demo 'Trusted IP Range' policy context record we have the 'Is Allow Migrated IP Filter'. I had referenced your post you shared here when I was troubleshooting this earlier, thank you for making that.

Despite the OOTB configuration we have here, our instance ip_access record of 'Type' "Deny" spanning 0.0.0.0 to 255.255.255.255 is blocking the 'Trusted Mobile App' mobile app from connecting to our instance if the mobile device IP is not listed in the 'Is Allow Migrated IP Filter' list.

It follows that if the 'Trusted Mobile App' pre-auth policy assessed the authentication attempt by the mobile device FIRST, however, then this would pre-empt the IP enforcement blocking the auth attempt by said mobile device app.

It's unclear what next steps could fix this , we'll attempted all reconfigs we could think of. Will need to escalate this to a specialist SN team for advisement, it seems.

Thanks,

Pat