Strange login behavior. Bug?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
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:
- My non-admin account and admin account share the same email address, but not the same username.
- My non-admin account uses M365 SSO. My admin account is local in the ServiceNow platform.
- 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.
- I am in a domain-separated instance. My admin account and non-admin account both reside in the same domain.
- 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.
- 693 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Create a Support Case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Creating a support case for that behavior on a production instance will get attention very quickly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
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.