User reactivated. SSO configured. Still getting logged out. Here's the full picture.

Selva Arun
Mega Sage

2 hours ago

ServiceNow Community - Platform Administration | Verified against official KB articles and community documentation
 

A user messages you: "I keep getting logged out as soon as I log in. Even SSO isn't working."

You check their record. Active is true. You just fixed that. You tell them to try again.

Same result.

 

This happens more than people talk about, and it almost never has just one cause. This article walks through the full chain - why it happens, how to read the record before you touch anything, and why the fix keeps breaking if you only solve half the problem.

 

It applies to any account that was ever deactivated: rehires, contractors returning after a gap, employees back from long-term leave, accounts suspended by security and then cleared. The trigger doesn't matter. The pattern is the same.

Why the Account Locks in the First Place

ServiceNow has an out-of-the-box Business Rule called "Lock Out Inactive Users." When a user's active field changes to false, this rule fires and sets locked_out to true. That part works as intended.

What doesn't exist out of the box is the reverse.

When you reactivate the account, setting active back to true, nothing automatically clears locked_out. The account is open, but the door is still bolted. This is a documented Known Error (KB0696657). It has existed across multiple releases with no automatic fix.

So when you reactivated the user and told them to try again, they were still locked out. You fixed the wrong thing first.

Why SSO Makes It Worse

With basic (username/password) login, a locked-out user sees an error message. They call you. You unlock. Done.

With SSO, the experience is different. The user authenticates with the Identity Provider - that part succeeds. But when ServiceNow receives the authentication callback, it checks the user record and finds locked_out = true. It blocks access and redirects back to the IdP. The IdP sees an authenticated session and hands them back. ServiceNow blocks them again.

The user's experience is being logged out instantly, every time, with no useful error message. From their side it looks like SSO itself is broken. From your side the account looks fine because active = true.

This loop is documented in KB2294501.

Read the Record Before You Touch Anything

Before making any changes, export the full user record as XML and read it. One export gives you the complete picture in under two minutes.

 

How to get it - two ways

Right-click method (fastest):
Open the user record in sys_user. Right-click the grey form header bar. Select Export, then XML, then "This Record."

URL method:

https://<your-instance>.service-now.com/sys_user_list.do?XML&sysparm_query=user_name=<username>
Handle the exported file carefully. It contains personal details and internal identifiers. Do not paste it into tickets or community posts.

Read it in four layers

Layer 1 - Can they log in at all?

These three fields tell you immediately whether the account is physically accessible:

<active>true</active>
<locked_out>true</locked_out>       <!-- still bolted even if active=true -->
<failed_attempts>0</failed_attempts>

If locked_out is true, that is your login blocker regardless of what else is configured. If failed_attempts is high, reset it to zero alongside clearing the lockout.

Layer 2 - Will your fix survive the next sync?

<source>ldap:CN=John Smith,OU=Employees,DC=corp,DC=company,DC=com</source>

If the source field shows an LDAP path, Active Directory controls this account's active status. Your manual change in ServiceNow will be overwritten on the next LDAP sync if the AD account is still disabled, or if the LDAP transform map reads the userAccountControl flag and sets active = false when the value indicates a disabled account.

Many enterprise instances also have custom fields tracking termination date, worker type, or an external worker system source. If your instance has these and the upstream record still shows the user as terminated, the next scheduled sync will undo everything you just fixed. Check your own data dictionary - these fields vary by organization.

Layer 3 - Is SSO routing to the right Identity Provider?

<sso_source>sso:</sso_source>

The correct format is sso:<sys_id_of_identity_provider>. An incomplete or blank value causes ServiceNow to either fall back to the default IdP or fail to match the user entirely, both of which contribute to the logout loop. Compare this field against a working user's record. If they differ, you have found a second contributing cause.

Layer 4 - Is SSO hitting the right record?

<email>john.smith@company.com</email>
<user_name>jsmith</user_name>

Search for any other sys_user record sharing the same email or username - one active, one inactive. SSO may be matching the wrong one. If you find a duplicate, rename the inactive record's user_name to something distinct so SSO resolves to the correct account.

The Fix - In This Order

Do not jump straight to unlocking. Confirm each layer first, then fix from the top down.

Field Table What to do
locked_out sys_user Set to false
failed_attempts sys_user Reset to 0
sso_source sys_user Confirm format is sso:<sys_id> - compare against a working user
Upstream source AD / external system Fix the source record before your next sync runs, or it undoes the fix

Test login in an incognito or private browser window after each change. Cached browser sessions carry old authentication state and will mislead you.

After They Log In - Check Their Roles

Clearing the lockout gets them in the door. It does not guarantee they can do anything once inside.

One thing to know: the roles field in the XML export will almost always appear empty. That is expected - it is a legacy field no longer populated since Contextual Security was introduced. Do not use it to judge whether a user has roles.

Actual role assignments live in sys_user_has_role. Group memberships that carry roles live in sys_user_grmember. Run this in System Definition, Scripts - Background to see the full picture:

(function checkUserAccess(username) {

    var userGr = new GlideRecord('sys_user');
    if (!userGr.get('user_name', username)) {
        gs.info('User not found: ' + username);
        return;
    }

    var userSysId = userGr.getUniqueValue();
    gs.info('=== User: ' + username + ' ===');
    gs.info('Active: '          + userGr.getValue('active'));
    gs.info('Locked Out: '      + userGr.getValue('locked_out'));
    gs.info('Failed Attempts: ' + userGr.getValue('failed_attempts'));
    gs.info('SSO Source: '      + userGr.getValue('sso_source'));

    // Direct and inherited roles
    var roleGr = new GlideRecord('sys_user_has_role');
    roleGr.addQuery('user', userSysId);
    roleGr.query();
    gs.info('--- Roles (sys_user_has_role) ---');
    var roleCount = 0;
    while (roleGr.next()) {
        gs.info('  ' + roleGr.getDisplayValue('role') +
                ' | Inherited: ' + roleGr.getValue('inherited'));
        roleCount++;
    }
    if (roleCount === 0)
        gs.info('  NO ROLES FOUND - check group memberships below');

    // Group memberships
    var grpGr = new GlideRecord('sys_user_grmember');
    grpGr.addQuery('user', userSysId);
    grpGr.query();
    gs.info('--- Groups (sys_user_grmember) ---');
    var grpCount = 0;
    while (grpGr.next()) {
        gs.info('  ' + grpGr.getDisplayValue('group'));
        grpCount++;
    }
    if (grpCount === 0)
        gs.info('  NO GROUPS - user has no group-inherited roles');

})('target_username'); // replace with actual username

If roles are missing, check whether your instance has a custom Business Rule that strips roles when a user goes inactive. Out of the box, ServiceNow does not remove roles on deactivation, but many organizations have added one. If your instance does this, roles need to be re-granted after reactivation. Granting admin gets the user working quickly, but it is a workaround - restore the specific roles they held before deactivation when you have time.

Why It Keeps Breaking

The most frustrating version of this problem is when you fix everything correctly, the user logs in successfully, and two days later they are locked out again.

This almost always means the upstream source still has the old state. LDAP ran overnight and re-read a disabled userAccountControl flag. An external worker system processed a pending termination record. A scheduled HR sync wrote the old status back.

The fix has to happen in the source system, not just in ServiceNow. Coordinate with whoever manages your user lifecycle integration before making changes in the instance, and confirm the upstream record is correct before assuming ServiceNow is the only place that needs updating.

References

All sources verified before inclusion in this article.

 

Thank you,

Selva (Meena) Arun

0 Helpfuls
  • 69 Views
Version history
Last update:
2 hours ago
Updated by:
Mega Sage
Contributors