Behavior of login restrictions during version upgrade (SSO, IP restriction, inactive users, Employee

[kuuum_aaaya]

We are planning a ServiceNow production upgrade and would like to control logins during the maintenance window.
Currently, we are considering two approaches:

Restricting by IP address

Setting users as inactive (active = false)

Since our instance uses SSO, I would like to confirm the actual behavior in these cases. Unfortunately, I cannot test SSO locally in our development environment.

Could anyone clarify:

With SSO enabled, what happens if login is attempted from a disallowed IP address?

(In local login, it shows an HTTP Status 403 page.)

With SSO enabled, what happens if the user is set to inactive?

(In local login, it shows “Invalid username or password” on the login page.)

Does the behavior differ when accessing via Employee Center (Service Portal/ESC) compared to the classic platform UI?

Any insights or experience sharing would be greatly appreciated.

Thank you in advance!

[Ravi Gaurav · Accepted solution]

Hi @kuuum_aaaya 

Nice upgrade-window planning question 👌 Let me break it down for you based on how ServiceNow auth + SSO + restrictions behave:

 1. SSO + IP address restriction

• Platform behavior: The IP restriction check happens after the SSO assertion is accepted but before session creation.

• If the source IP is not allowed:

  • The session is blocked.

  • Users typically see a 403 Forbidden error (sometimes a generic error page if coming through the SSO redirect).

• This is the same whether you come through Classic UI (/nav_to.do) or Employee Center/Service Portal (/sp).

• Bottom line: IP restriction is enforced post-auth but pre-login session, so it works with SSO the same way as with local login.

 2. SSO + Inactive user (active = false)

• Even if IdP (SSO) authenticates successfully and returns a valid SAML/OIDC assertion:

  • ServiceNow checks the user record (sys_user.active).

  • If inactive, session creation is denied.

• User experience:

  • You don’t get a ServiceNow session.

  • Depending on your IdP + browser flow, you may see a “login loop” (keeps redirecting back to IdP then SN denies).

  • With local login, you’d see “Invalid username or password.” With SSO, you may just land on the login page or error page.

• This applies consistently across Classic UI and Employee Center.

3. Difference between Employee Center vs Classic UI

• There is no functional difference in how login restrictions (IP / inactive user) are enforced.

• Both /sp (Service Portal/Employee Center) and /nav_to.do go through the same authentication + session validation chain.

• The only variation is the error page styling (portal may show a generic error widget, Classic shows 403/401).

4. Recommendations for upgrade window

• Preferred approach: Use IP restriction for a clean, global block of logins (shows 403).

• If you only need to block end-users but let admins in → combine IP restriction with an “allowed” admin subnet/VPN.

• Inactive users method works but is heavy (and noisy in audit). Better suited for specific accounts, not mass control.

• For extra safety, also configure a maintenance banner / splash page for any admins who do get in.