Strange login behavior. Bug?

Joe1
Tera Expert

I have two accounts in our instance. Both accounts share the same email address but have different usernames. My non-admin one is provided through M365.

 


So yesterday I logged into my non-admin account via SSO as I normally do. I use a private tab for my admin account in the PROD instance but a Firefox container tab for my non-admin account. Since I had an active SSO session the authentication passed without me having to give credentials but when the page loaded I was in my admin account instead of my non-admin.

I then was able to replicate this behavior in Edge and in private tabs, even with providing my SSO credentials.

 

To resolve the issue, we disabled my admin account and then a few minutes later I was able to log-in using my non-admin SSO and got to the right account. Then re-activating my local admin user made my accounts behave like normal again.

So this morning I turned on my computer and launched the PROD instance and the active SSO session logged me in automatically... and it was my admin account (not the SSO account) again! This time I was able to log out and then back in as my non-admin user without issue however. But in Edge I saw the same issue as the day before where I would be logged into my admin account with my non-admin SSO.

Anyway, this is what I know:

  1. My non-admin account and admin account share the same email address, but not the same username.
  2. My non-admin account uses M365 SSO. My admin account is local in the ServiceNow platform.
  3. I observed this behavior only in PROD, but across two browsers and in private browsing mode. DEV and QA seem to not have this issue.
  4. I am in a domain-separated instance. My admin account and non-admin account both reside in the same domain.
  5. Build tag: glide-xanadu-07-02-2024__patch10-hotfix1a-09-24-2025

 

My concern is that this may be a bug in the platform that could result in an escalation of user privileges. I HOPE I am wrong and that this is just weirdness on my end or in my instance, so any advice is appreciated.

5 REPLIES 5

WillieW
Tera Expert

Create a Support Case.

Bert_c1
Kilo Patron

Creating a support case for that behavior on a production instance will get attention very quickly.

Joe1
Tera Expert

@WillieW  @Bert_c1  I will see if we have a support case opened.

For what it is worth it has been a few days since I last saw this behavior in my main browser but in a secondary browser I am seeing the issue still.

lauri457
Giga Sage

If you are using SAML SSO with a default identity provider and on the idp record you have user field as email and your nameid policy is like "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" then this is expected behaviour. 

 

You authenticate with the idp and then the idp sends the saml assertion containing the identity attributes and servicenow matches it to probably the first user it finds with the email. You can get odd behaviour elsewhere too if you share email with multiple sys_users.