Locked out of Personal Developer Instance after configuring Microsoft OIDC SSO

shubhamsmoh
Kilo Contributor

3 hours ago

Hi Team,

I accidentally modified the default OIDC Provider, Authentication Profile, and Multi-Provider SSO while configuring Microsoft Azure AD SSO on my Personal Developer Instance.

Instance:
dev215219

Current issue:
• Admin login fails even after resetting the admin password from the Developer Portal.
• "Sign in with Microsoft" authenticates successfully but then redirects to:
"Security constraints prevent access to requested page."
• Clicking "Start Building" from the Developer Portal redirects back to the instance login page.

I no longer have access to the instance and cannot revert the authentication configuration.

Is there any way to recover the instance without releasing it?

Thank you.

0 Helpfuls
  • 71 Views
1 REPLY 1

Abhishek Pal
Mega Guru

59m ago

Hi @shubhamsmoh ,

Since this is a PDI and the lockout happened after changing the OIDC / Multi-Provider SSO configuration, try local authentication before resetting the instance.

Recommended recovery steps:

1. From the ServiceNow Developer Site, reset the PDI admin password again.

2. Open a new Incognito/Private browser window so that the existing Azure/OIDC SSO cookie is not reused.

3. Try the local login page directly:

https://dev215219.service-now.com/login.do

Use:

Username: admin
Password: the password generated/reset from the Developer Site

4. If you are still redirected to Microsoft SSO, try the ServiceNow side-door login:

https://dev215219.service-now.com/side_door.do

The side-door login is specifically useful when an SSO configuration is preventing normal local authentication.

5. If you regain admin access, immediately review the OIDC / Multi-Provider SSO changes.

I would recommend:

- Deactivate the custom Azure OIDC Identity Provider temporarily.
- Restore any OOB Authentication Profile or OIDC Provider records that were modified.
- Do not modify the OOB/default Identity Provider records for testing.
- Create a separate Identity Provider configuration for Azure AD instead.
- Verify local admin login before enabling automatic SSO redirection again.

After correcting the configuration, clear browser cookies and test both:

Local login
https://dev215219.service-now.com/login.do

Azure SSO
/login_with_sso.do?glide_sso_id=<your Azure IdP sys_id>

Important:

"Start Building" from the Developer Site does not bypass a broken authentication configuration inside the PDI. It can launch the instance, but authentication is still handled by the configuration currently present in the instance.

Changing the PDI user role to admin will also not correct a broken OIDC or Authentication Profile configuration.

If both login.do and side_door.do fail, unfortunately there is no Developer Site function that rolls back only the authentication configuration while preserving the rest of the PDI.

The remaining recovery option is:

Developer Site
-> My Instance
-> Reset and wipe instance

Do this only as the final option because Reset and wipe permanently deletes the customizations and configuration in that PDI.

For future SSO testing in a PDI, I recommend:

1. Keep the local admin account available.
2. Create a new Azure/OIDC Identity Provider instead of modifying the OOB/default provider.
3. Test the IdP explicitly using:

/login_with_sso.do?glide_sso_id=<IdP sys_id>

4. Verify side_door.do/local login before enabling automatic redirection.
5. Export important Update Sets or commit application work to source control before changing authentication configuration.

Official references:

Multi-Provider SSO login:
https://www.servicenow.com/docs/r/platform-security/authentication/log-in-multi-provider-sso.html

Resetting a PDI:
https://www.servicenow.com/docs/r/application-development/building-applications/resetting_your_pdi_t...

Related Community reference for local/side-door login:
https://www.servicenow.com/community/itsm-forum/how-to-disable-single-sign-on-in-servicenow-portal/t...

I would definitely try login.do and side_door.do with the freshly reset admin password before wiping the PDI.

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal

0 Helpfuls