deactivating all local-login // single-auth portals to ensure 100% auth is forced through SSO

[pbusch]

It is my understanding that setting sys_property `glide.authentication.external.disable_local_login` to `true` will disable local login. To further empower our need for ALL authentication attempts to go with our SSO, we have also deactivated login.do and side_door.do ;

Is anyone able to provide any insights into there being any *other* single-factor//local-login portals nested around the platform? The 'simple-widget' zero-day spooked our SecOps to the point that in order to resume 'typical' end-user access to our instance, our security needs are such that we must be able to prove to our SecOps that there are exactly zero single-auth//local-login portal(s).

Thanks so much,

Pat 

[Dr Atul G- LNG]

Hi @pbusch 

I am not sure, I fully understand your question, but what I understood, you want enable SSO for your users.  For that you need to add SSO properties and then setup SSO link in user profile and you can enable MFA as well. 

https://www.servicenow.com/docs/bundle/xanadu-platform-security/page/integrate/single-sign-on/concep...

[pbusch]

Hi Atul,

I corrected a typo from my post, so perhaps it's clearer that our Business Requirement is that no un-authorized user can attempt to authenticate with our instance.

Our current Adaptive Authentication pre-auth policy is enforcing a 'Deny' rule that blocks 0.0.0.0-255.255.255.255 ; this 'Deny' rule has holes punched in it by hundreds of 'Allow' rules which permit white-listed end-users and office WiFi subnets to permit our trusted user base to get around that iron-clad 'Deny' rule I mentioned.

We also have the Adaptive Authentication 'Trusted Mobile App' policy in place; but here's there the problem shows itself -- our users can only ping our instance via their Trusted Mobile App if and only if they are in fact already on one of the aforementioned 'Allow' IPs. So this makes mobile access unuseable for a user whose mobile happens to be on an exotic IP [e.g. at a data center, in transit, etc].

In hopes of deactivating that 'Deny' rule, we are auditing the instance to decipher if login.do and side_door.do are indeed the only single-factor // local login portals. Deactivating the 'Deny' rule would fix the exotic IP mobile access issue , however we simply cannot expose the instance to non-'Allowed' IPs if there does indeed exist such a portal somewhere in the myriad of ServiceNow records. 

We need to know where every publically available single-factor//local-login portals are accounted for in SN, and so we are certain that all have been deactivated.

Thanks,

Pat 

[SrinivasaR20247 · Accepted solution]

Hi @pbusch 

Please go through the below KB;

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0746067

[Randheer Singh]

Hi @pbusch ,
here is a more complete article.

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1649420

Thanks,

Randheer