How do you lock out all SSO users and kick out active sessions from all nodes?

[chadto]

What is the recommended method of locking out SSO users, and kicking out users from all nodes during platform upgrades and patches?

We unchecked the system property in Multi-Provider SSO > Properties titled "Enable multiple provider SSO".

We then went to Multi-Provider SSO -> Identity Providers and disabled all the providers.

While the above was successful at preventing any new sessions through Single Sign-On, existing sessions persisted.

We then went to User Administration -> Logged in Users and attempted to lock out all active users. However, any given admin was only able to see and lock out users on the same node; we could see there were still many users on other nodes that we could not lock out, nor do we know any way to force a user to log in to a specific node.

Is there a recommended method to force all but select (admin) users off the platform, particularly for platform upgrades?

Thank you in advance!

[Matt Taylor - G · Accepted solution]

You can query the sys_user_session table to see all currently active users regardless of node using the following encoded query parameters: nameISNOTEMPTY^invalidatedISEMPTY 

You can then use GlideSessions.lockOutSessionsInAllNodes(<user_name>); to lock out a user no matter what node they are on. 

var gr = new GlideRecord('sys_user_session');
gr.addEncodedQuery('nameISNOTEMPTY^invalidatedISEMPTY');
gr.query();

while (gr.next()){

    if (gr.name != gs.getUserName()) {
        GlideSessions.lockOutSessionsInAllNodes(<user_name>);
    }
        
}

[Allen Andreas]

Also, just a side note (letting you know that it is allowed and doesn't affect anything) -- that users can be on the platform during an upgrade. They can still submit tickets, and request items, etc. The only thing that really turns off during the upgrade is scheduled jobs and web services in that upgrade window (which usually lasts for about 2 hours). So you can have it be a non-impact situation for your company with that in mind, which tends to please the higher ups when logistically looking at everything.

Anything that the upgrade would touch that would differ from what you did custom....it would hit your skipped changes and not immediately apply itself (thus preventing the upgrade from breaking stuff and causing chaos for those logged in users).

Just wanted to toss that out there.

Please mark reply as Helpful/Correct, if applicable. Thanks!