NetSuite SSO: SAML, Okta & Azure AD Setup Guide

Why SSO matters for NetSuite

If your team is still logging into NetSuite with individual usernames and passwords, you're creating problems you don't need. Forgotten passwords generate help desk tickets. Shared credentials create audit nightmares. Offboarded employees retain access longer than they should because someone forgot to disable their NetSuite account. Single sign-on fixes all of this.

SSO centralizes authentication through your identity provider — the same system your team uses to log into email, Slack, and everything else. When someone joins the company, they get NetSuite access automatically. When they leave, disabling their IdP account revokes NetSuite access instantly. No manual cleanup, no lingering accounts.

Beyond convenience, SSO is increasingly a compliance requirement. SOC 2 auditors want to see centralized identity management. SOX compliance demands clear access controls. If your company handles sensitive financial data in NetSuite (and you do — it's your ERP), auditors will ask how you manage authentication. "Everyone has their own password" is not the answer they want to hear.

From a practical standpoint, SSO also reduces friction. Your team opens their browser, clicks the NetSuite tile in their IdP dashboard, and they're in. No password to remember, no MFA prompt to fumble through separately. The identity provider handles all of that before the user ever reaches NetSuite.

---

How NetSuite SSO works: SAML 2.0

NetSuite uses SAML 2.0 (Security Assertion Markup Language) for single sign-on. If you've configured SAML for any other enterprise application, the flow will be familiar. If you haven't, here's the short version.

Identity Provider (IdP) — This is your central authentication system. Okta, Azure AD (now called Entra ID), Google Workspace, OneLogin, or Ping Identity. The IdP verifies who the user is.

Service Provider (SP) — This is NetSuite. It receives a SAML assertion from the IdP that says "this user is authenticated, here are their attributes," and grants access based on that assertion.

The SAML flow works like this:

1. User attempts to access NetSuite (either directly or from an IdP dashboard)
2. NetSuite redirects the user to the IdP for authentication
3. The IdP authenticates the user (password, MFA, biometrics — whatever's configured)
4. The IdP generates a signed SAML assertion containing the user's identity and attributes
5. The assertion is sent back to NetSuite via the user's browser
6. NetSuite validates the assertion signature, matches the user to a NetSuite account, and grants access

The whole thing takes a couple of seconds. The user clicks a link and lands in NetSuite, fully authenticated.

Two variations exist: IdP-initiated SSO, where the user starts from the identity provider's app dashboard and clicks a NetSuite tile, and SP-initiated SSO, where the user navigates to NetSuite's login page directly and gets redirected to the IdP. You'll want to support both.

---

Supported identity providers

NetSuite's SAML 2.0 implementation is standards-compliant, which means it works with any identity provider that supports SAML 2.0. Some IdPs have pre-built NetSuite integrations that make setup significantly easier.

Okta — The most common choice we see in mid-market companies. Okta has a pre-built NetSuite application in their Integration Network with SAML pre-configured. Setup takes 30-60 minutes if you know what you're doing.

Azure AD (Entra ID) — If you're a Microsoft shop, this is the natural choice. Microsoft's Enterprise Application gallery includes a NetSuite template. The configuration is straightforward, and if you're already managing users in Azure AD, you get the benefit of a single directory.

Google Workspace — Works well for companies that run on Google. Google Workspace supports custom SAML apps, so you can configure NetSuite as a service provider. The setup is a bit more manual than Okta or Azure AD since there's no pre-built NetSuite template, but it's documented and reliable.

OneLogin — Has a pre-built NetSuite connector with attribute mapping and provisioning support. A solid choice if OneLogin is already your IdP.

Ping Identity — Enterprise-focused identity provider with SAML support. Common in larger organizations with complex identity requirements.

---

Step-by-step: Configuring Okta SSO for NetSuite

Okta is the IdP we configure most often for NetSuite clients. Here's the full process.

1. Add NetSuite to Okta

In the Okta Admin Console, go to Applications > Applications > Browse App Catalog. Search for "NetSuite" and select the Oracle NetSuite application. Click Add Integration.

You'll be prompted for your NetSuite account ID. This is the numeric or alphanumeric identifier for your account (e.g., 1234567 or TSTDRV1234567 for sandbox accounts). You can find it in NetSuite under Setup > Company > Company Information.

2. Configure SAML settings in Okta

Under the Sign On tab of the NetSuite application in Okta, select SAML 2.0 as the sign-on method. Key settings:

• ACS URL (Assertion Consumer Service): https://<accountId>.app.netsuite.com/saml2/acs
• Entity ID: https://<accountId>.app.netsuite.com/saml2/acs
• Name ID format: Email address (this is what NetSuite uses to match users)

Download the IdP metadata XML or note the IdP Issuer URI, SSO URL, and signing certificate. You'll need these for the NetSuite side.

3. Configure attribute mapping

This is where things can go wrong. The SAML assertion needs to include attributes that NetSuite can use to identify the user and assign roles.

Required attributes:

• email — Maps to the user's NetSuite email address. This is the primary identifier.
• account — Your NetSuite account ID

Optional but recommended:

• role — The NetSuite role internal ID to assign. If you skip this, users land on their default role.
• firstName / lastName — For user provisioning

In Okta's attribute mapping section, configure these as SAML attribute statements. The email attribute should pull from user.email in Okta. The account attribute should be a static value set to your NetSuite account ID.

4. Assign users and groups

Under the Assignments tab, assign the NetSuite application to the appropriate Okta groups or individual users. Only assigned users will be able to SSO into NetSuite.

---

Step-by-step: Configuring Azure AD (Entra ID) SSO for NetSuite

Microsoft's identity platform has gotten better about pre-built SAML integrations, and NetSuite is well-supported.

1. Add NetSuite from the Enterprise Application gallery

In the Azure portal, navigate to Microsoft Entra ID > Enterprise Applications > New Application. Search for "NetSuite" in the gallery and select Oracle NetSuite. Click Create.

2. Configure Single Sign-On

Go to the Single sign-on section and select SAML. Azure will present the Basic SAML Configuration panel.

• Identifier (Entity ID): https://<accountId>.app.netsuite.com/saml2/acs
• Reply URL (ACS URL): https://<accountId>.app.netsuite.com/saml2/acs
• Sign on URL: https://<accountId>.app.netsuite.com/app/login/secure/sso.nl
• Relay State: Leave blank unless you want users to land on a specific page
• Logout URL: https://<accountId>.app.netsuite.com/saml2/slo

3. Configure attributes and claims

Click Edit on the Attributes & Claims section. You need:

• Unique User Identifier (Name ID): Set to user.email with Email Address format
• Additional claims:
  • account — A constant value of your NetSuite account ID
  • role — Map this to a user attribute or group-based claim if you want role provisioning

4. Download the certificate and metadata

From the SAML Signing Certificate section, download the Certificate (Base64) and the Federation Metadata XML. You'll also need the Login URL and Azure AD Identifier from the Set up Oracle NetSuite section.

5. Assign users and groups

Under Users and groups, assign the application to the relevant Azure AD groups. This controls who can access NetSuite via SSO.

---

NetSuite-side configuration

Regardless of which IdP you're using, the NetSuite configuration follows the same pattern.

Enable SAML SSO in NetSuite

Navigate to Setup > Integration > SAML Single Sign-on. If you don't see this menu option, you may need to enable the feature first under Setup > Company > Enable Features > SuiteCloud > Manage Authentication.

Configure the SAML settings

Identity Provider Issuer: The entity ID or issuer URL from your IdP. For Okta, this looks like http://www.okta.com/exk.... For Azure AD, it's a URL like https://sts.windows.net/{tenant-id}/.

Identity Provider SSO URL: The login URL from your IdP where NetSuite redirects users for authentication.

Identity Provider Certificate: Upload the X.509 certificate you downloaded from your IdP. This is how NetSuite verifies the SAML assertion signature. You can paste the certificate content or upload the .cer/.pem file.

Entity ID / Service Provider Issuer: Your NetSuite ACS URL — https://<accountId>.app.netsuite.com/saml2/acs.

Save the configuration and note the SP metadata URL that NetSuite provides. You may need this if your IdP requires it.

Important details

Certificate format matters. NetSuite expects a Base64-encoded X.509 certificate. If you upload a DER-encoded certificate, it will fail silently — SSO just won't work, and the error messages won't point you toward the certificate format.

Account ID must match exactly. The account ID in your SAML configuration must match the account ID in NetSuite's URL. Sandbox accounts use a different format (e.g., TSTDRV1234567_SB1). If there's a mismatch, the assertion validation fails.

---

Role mapping: IdP groups to NetSuite roles

Role mapping is where SSO configuration gets interesting — and where we see the most mistakes.

NetSuite roles are not the same as IdP groups. A user might belong to a "Finance" group in Okta or Azure AD, but that doesn't automatically translate to the "Accountant" role in NetSuite. You need to explicitly map these.

Option 1: Default role assignment. The simplest approach. Every user who SSOs into NetSuite lands on their pre-assigned default role. You manage role assignments in NetSuite directly (on the employee/user record). This works well for smaller teams.

Option 2: Role attribute in the SAML assertion. You include a role attribute in the SAML assertion that contains the NetSuite role internal ID. The IdP sends the role ID, and NetSuite assigns that role for the session. This lets you control role assignment from the IdP side, which is cleaner for larger organizations.

Option 3: Multi-role access. A user can have multiple NetSuite roles. You can configure the SAML assertion to include a specific role for SSO login, while the user retains the ability to switch roles within NetSuite after authentication. The role in the assertion just determines which role they land on initially.

The common mistake: Setting up role mapping in the IdP but forgetting to assign the corresponding roles to the user record in NetSuite. The SAML assertion says "give this user the Administrator role," but the user doesn't have that role assigned in NetSuite. Result: login failure. The role must exist on the user's employee record in NetSuite for SSO to work.

---

SSO + two-factor authentication

A question we get frequently: "If we have SSO, do we still need two-factor authentication in NetSuite?"

The short answer is that your IdP should handle MFA, and you should enforce it there. When a user authenticates through Okta or Azure AD, the IdP can require MFA (push notification, TOTP, hardware key — whatever you've configured). By the time the SAML assertion reaches NetSuite, the user has already passed MFA at the IdP level.

NetSuite also has its own 2FA capability, and you can layer both. Some compliance frameworks require MFA at the application level, not just the IdP level. In that case, you can enable NetSuite's native 2FA in addition to SSO. The user authenticates through the IdP (with MFA), then gets an additional 2FA prompt from NetSuite.

We generally recommend handling MFA at the IdP level only, unless a specific compliance requirement mandates application-level MFA. Layering two separate MFA prompts creates friction and generates support tickets. Your IdP's MFA is typically more flexible and user-friendly than NetSuite's built-in option.

For highly sensitive roles (Administrator, for example), consider conditional access policies at the IdP level that require stronger authentication — hardware security keys instead of push notifications, or step-up authentication from specific IP ranges.

---

Common issues and troubleshooting

Here are the issues we see repeatedly.

Certificate expiration. IdP signing certificates expire, typically after one to three years. When they do, every SAML assertion fails validation because NetSuite is checking against the old certificate. The fix is straightforward — download the new certificate from your IdP and upload it to NetSuite's SAML configuration. The prevention: calendar a reminder to rotate certificates before they expire. Some IdPs support certificate rollover, where you can upload a new certificate to NetSuite before the old one expires.

Clock skew. SAML assertions include timestamps, and NetSuite validates them. If the clocks on your IdP and NetSuite's servers are more than a few minutes apart, assertions get rejected as expired or not-yet-valid. This is rare with cloud-hosted IdPs (Okta, Azure AD sync to NTP automatically), but we've seen it with on-premises ADFS servers that drifted.

Attribute name mismatch. Your IdP sends emailAddress but NetSuite expects email. Or the IdP sends the account ID as Account (capitalized) but NetSuite expects account (lowercase). SAML attribute names are case-sensitive. Double-check the exact attribute names in both your IdP configuration and NetSuite's expectations.

User not found in NetSuite. The SAML assertion is valid, but NetSuite can't match the email address to an existing user. This happens when the email in the IdP doesn't match the email on the NetSuite employee record, or when the user hasn't been provisioned in NetSuite yet. Check for trailing spaces, domain mismatches, or alias vs. primary email differences.

Role assignment failures. The assertion includes a role ID that doesn't exist in NetSuite, or the user doesn't have that role assigned to their employee record. NetSuite rejects the login because it can't place the user in the requested role.

Sandbox vs. production confusion. Your sandbox account ID is different from production. If you configured SSO for production and then refreshed your sandbox, the sandbox SSO configuration was overwritten with production values — but the sandbox account ID is different. You need separate IdP application entries for production and sandbox.

---

Testing SSO: do it right

Always test in sandbox first. Always. Setting up a broken SSO configuration in production can lock your entire team out of NetSuite. Here's the testing process we follow.

Step 1: Configure SSO in your sandbox account. Create a separate application entry in your IdP for the sandbox. Use the sandbox account ID in all configuration values.

Step 2: Test IdP-initiated login. From your IdP dashboard (Okta, Azure AD), click the NetSuite sandbox tile. You should be redirected to NetSuite and logged in automatically. If this fails, check the SAML assertion using browser developer tools or a SAML debugging extension (SAML-tracer for Chrome is excellent).

Step 3: Test SP-initiated login. Navigate directly to your NetSuite sandbox login URL. You should be redirected to your IdP for authentication, then back to NetSuite. If IdP-initiated works but SP-initiated doesn't, the issue is usually the SP-initiated SSO URL configuration in NetSuite.

Step 4: Test role assignment. Verify that users land on the correct role. Test with users who have multiple roles to confirm the default role behavior.

Step 5: Test edge cases. What happens when a user doesn't exist in NetSuite? What happens if the IdP sends an invalid role? What happens if the user's NetSuite account is inactive? Document the expected behavior for each scenario.

Step 6: Replicate in production. Once sandbox testing passes, create the production IdP application and configure NetSuite production. Test with a small group before rolling out company-wide.

---

Password policy and emergency access

Once SSO is working, you need to decide what to do about direct NetSuite logins — the traditional username/password method.

Option 1: Allow both SSO and direct login. This is the safe starting point. Users can SSO in via the IdP or log in directly with a NetSuite password. This gives you a fallback if the IdP goes down. The downside: users might bypass SSO and log in directly, which defeats the purpose of centralized authentication.

Option 2: Disable direct login for most users. You can require SSO for standard users while keeping direct login available for administrators. This is what we recommend for most companies. Regular users must use SSO — no password option. One or two admin accounts retain direct login capability as a break-glass procedure.

Option 3: Disable direct login for everyone. Maximum security, but risky. If your IdP goes down, nobody can access NetSuite. We don't recommend this unless you have a highly available IdP with guaranteed uptime and you've tested your disaster recovery procedures.

The break-glass account: Regardless of your approach, maintain at least one administrator account with direct login access and a strong, unique password stored in a physical safe or a secure vault separate from your IdP. This account is only for emergencies — IdP outage, SSO misconfiguration, or certificate expiration that locks everyone out. Audit its usage and change the password regularly.

Password policy for SSO users: Even if you require SSO, NetSuite still has passwords on user records. Set a strong password policy (complex, long expiration) as a defense-in-depth measure. Some organizations set SSO-only users' passwords to random, un-remembered values since the password should never be used directly.

---

Frequently asked questions

Frequently Asked Questions

Can I use SSO for NetSuite sandbox accounts?expand_more

Does NetSuite SSO work with SuiteScript and API access?expand_more

What happens if our identity provider goes down?expand_more

Can different NetSuite subsidiaries use different identity providers?expand_more

How long does it take to set up SSO for NetSuite?expand_more

---

Need help configuring SSO for NetSuite?

We've set up SSO for NetSuite accounts across dozens of organizations, from 20-person teams to companies with hundreds of users across multiple subsidiaries. If you want it done right the first time — including sandbox testing, role mapping, and break-glass procedures — reach out to our team. We'll get your team logging in with a single click.