When a Salesforce sandbox is refreshed from a production environment, the Single Sign-On (SSO) configuration using SAML (Security Assertion Markup Language) is partially carried over to the refreshed sandbox — but not fully. Specifically, SAML settings are automatically disabled in the sandbox after a refresh because the Recipient URL is updated to match the new sandbox URL assigned by Salesforce.
If your production org uses SSO, users will not be able to log into the refreshed sandbox via SSO immediately after the refresh. The SAML settings must be reconfigured before SSO access is restored in the sandbox.
This article explains what SSO settings are copied during a sandbox refresh, what changes automatically, and what steps are required to re-enable SSO access in the refreshed sandbox.
When a sandbox is refreshed, the following behavior applies to SSO (SAML) settings:
If the sandbox administrator cannot log in due to SSO being disabled, an admin in the production org can reset the sandbox user's password:
000385851

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.