Admin

NetSuite Sandbox SSO: Fixing the Different Metadata Error

A Sandbox SAML upload can fail when its identity provider metadata differs from the configuration already stored in another NetSuite account. Here is what to check, which file to use, and how to verify access.

By Jack Ring · Independent NetSuite consulting since 2019 · October 21, 2026

Call Jack: (724) 816-1000 Start a conversation

The XML uploads, but NetSuite rejects the configuration

After a Sandbox refresh, checking single sign-on belongs on the administrator's list. Production may already use Microsoft Entra ID, while the Sandbox configuration still needs attention. During a recent setup attempt, submitting a supplied metadata XML file produced this message:

NetSuite recognized the identity provider's Entity ID, but found different metadata associated with it elsewhere. The message does not identify that other account. Oracle's multiple-account guidance requires identical metadata when accounts share the same identity provider.

XML is the expected format. Renaming the file or converting it will not address this conflict. Do not manually change the Entity ID to get past the message.

Two metadata files with different jobs

Before downloading anything, identify which side of the SAML connection the file describes. Microsoft is the identity provider, or IdP. NetSuite is the service provider, or SP.

Which metadata belongs in this procedure?
Metadata	What it describes	Use here
Identity Provider Metadata	Microsoft's SAML configuration, including signing information.	Download the existing file from Production and upload it to Sandbox.
NetSuite Service Provider Metadata	NetSuite's side of the SAML connection.	Reference for identity provider configuration. This is not the file being transferred.

The NetSuite SP metadata at system.netsuite.com/saml2/sp.xml serves a different purpose. For this procedure, use Production's Current Identity Provider Metadata download.

Use the metadata already stored in Production

For this shared-Microsoft-IdP environment, I adopted the following procedure. Oracle documents using an existing metadata file for additional accounts as an alternative to its preferred coordinated redefinition process.

Sign in to Production as Administrator. Confirm the environment before proceeding.
Open the SAML setup page. Go to Setup > Integration > Manage Authentication > SAML Single Sign-on. Some menu layouts show the page directly under Integration.
Download the existing IdP metadata. In Current Identity Provider, select Current Identity Provider Metadata. Leave Production's configuration unchanged.
Sign in to the refreshed Sandbox as Administrator. Verify that you are in the intended Sandbox.
Open its SAML setup page. Use the corresponding navigation in Sandbox.
Select Upload IDP metadata File. Choose the XML downloaded from Production.
Submit and check the result. Confirm whether NetSuite accepts the configuration.
Test an actual SAML login. Use an intended Sandbox user and permitted business role. Confirm the account and role reached.

If the upload still fails, stop repeating it and involve the identity administrator. Inventory the accounts sharing that Entity ID and review whether metadata has changed. Oracle's preferred redefinition procedure involves coordinated changes across accounts. Treat that as a separate planned activity, rather than deleting Production's configuration as a routine troubleshooting step.

An accepted configuration still needs a login test

Saving the setup establishes one checkpoint. A successful user login establishes another. Before testing, review these items:

Feature: SAML Single Sign-on is enabled under Setup > Company > Enable Features > SuiteCloud > Manage Authentication.
Role: The intended business role has SAML Single Sign-on permission at Full.
User: The user has that role assigned and appropriate Sandbox access.
Destination: The test reaches the correct Sandbox and expected role.

The setup and login permissions are separate. Adding SAML Single Sign-on permission requires SAML authentication for that role, so inspect existing access before changing it.

Use Administrator for configuration. Oracle's SAML permission limitations exclude Administrator from SAML login. Test with an appropriate business role in a separate browser session so an existing session does not obscure the result.

Check the Microsoft account claim separately

The Microsoft configuration in this case reportedly included an account claim directed at Production. That raises a separate access question even after matching the metadata.

Oracle advises omitting the account attribute when users need to switch between accounts that trust the same IdP. Ask the identity administrator to review the Microsoft Entra configuration against that intended behavior.

Changing the claim does not repair a metadata mismatch. Matching metadata does not prove that account switching works. Coordinate both checks and record the actual login result.

Put the procedure in your refresh checklist

Validate that this approach fits your configuration. A refresh does not universally mean SAML has broken or needs rebuilding. Keep a dated internal runbook with the environment, metadata source, user and role tested, and outcome. The completed login test is what makes the checklist useful.

References

Documentation reviewed October 21, 2026.

Back to all insights