Skip to main content
Connect NetSuite to Oleria to gain continuous visibility into who can sign in to your NetSuite account and what they can do there. Oleria reads identity, role, and login data through NetSuite’s REST web services. It maps every user, role, group, and access token in one place, so you can find dormant or over-privileged access and act on it directly from Oleria.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your NetSuite account:
  • Accounts - every employee with NetSuite access, with their roles, department, subsidiary, title, and supervisor. Employees whose access was removed but who still hold roles are shown as disabled.
  • Roles - all standard and custom roles, with each user’s assigned roles. Administrator access is flagged, and each role notes the web services and setup permissions it grants.
  • Groups - NetSuite groups, static and dynamic, with the employee members NetSuite lists for them. Members of dynamic groups (defined by a saved search) may not be listed.
  • Access tokens - token-based authentication (TBA) access tokens, with the integration, user, and role each one was issued for, and whether it’s active, inactive, or revoked.
  • Login activity - successful and failed logins from the Login Audit Trail, including token-based and OAuth logins, with IP address, role, and user agent. Oleria also uses this to show each user’s last login. On the first sync, Oleria reads up to 90 days of history.
Oleria refreshes this data on its regular sync schedule.

​
Prerequisites

  • A NetSuite administrator to enable features, create the integration record, and set up the integration role.
  • The REST Web Services feature enabled (Setup -> Company -> Enable Features -> SuiteCloud). For the recommended OAuth 2.0 method, also enable OAuth 2.0. For token-based authentication, enable Token-Based Authentication.
  • A dedicated integration user. Oleria can’t tell which employee its credentials belong to, so use an account that no one will deprovision from Oleria.
  • A role for that user with these permissions:
If the role can’t read the Login Audit Trail, access tokens, or groups, Oleria still connects and syncs everything else, and logs a warning for what it skipped. Make sure the role isn’t restricted to a subset of subsidiaries or departments, or Oleria only sees the employees inside that restriction. You also need admin access on the Oleria platform to add a new integration.
The exact location of these settings can change over time. If the steps below don’t match what you see, refer to NetSuite’s documentation on OAuth 2.0 client credentials and token-based authentication.

​
Connect NetSuite to Oleria

1

Create an integration record

In NetSuite, go to Setup -> Integration -> Manage Integrations -> New. Name it (for example, Oleria), and under Authentication:
  • For OAuth 2.0, select Client Credentials (Machine to Machine) Grant and the REST Web Services scope. Clear Token-Based Authentication and the authorization code grant.
  • For token-based authentication, select Token-Based Authentication.
Save the record and copy the Client ID (OAuth 2.0) or the Consumer key and Consumer secret (token-based authentication). NetSuite shows them only once.
2

Create the credentials for the integration user

  1. Create a key pair and a certificate, for example with OpenSSL: openssl req -new -x509 -newkey rsa:4096 -keyout private.pem -nodes -days 365 -subj "/CN=Oleria NetSuite integration" -out public.pem (an EC key on P-256, P-384, or P-521 also works). NetSuite accepts certificates valid for up to two years, and each NetSuite account (including each sandbox) needs its own upload and mapping.
  2. Go to Setup -> Integration -> Manage Authentication -> OAuth 2.0 Client Credentials (M2M) Setup and select Create New.
  3. Select the integration user as Entity, the integration role as Role, the integration record as Application, and upload public.pem.
  4. Save and copy the Certificate ID. Keep private.pem for the next step.
Treat the private key, consumer secret, and token secret like passwords. Anyone who has them can act in NetSuite with the integration role’s permissions.
3

Find your account ID

Go to Setup -> Company -> Company Information and copy the Account ID, for example 1234567, or 1234567_SB1 for a sandbox.
4

Find NetSuite in Oleria

Go to your Oleria workspace, select Integrations, select the Available tab, and search for NetSuite.
5

Connect in Oleria

Select the NetSuite card and fill in the connection form:Select Authenticate. Oleria checks the credentials against NetSuite before saving the integration, and reports which permission is missing if a required read fails.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered accounts, roles, groups, access tokens, and login activity in your Oleria workspace.
If you revoke the access token or the client credentials mapping, or the certificate expires, update the integration in Oleria by editing it and entering the new credentials.

​
Remediation actions

Beyond discovery, Oleria can act on NetSuite access to remediate risk. All remediation actions need the Lists -> Employees permission at Full. A few safeguards apply to every action:
  • NetSuite only lets an administrator change an administrator’s record. With a non-administrator integration role, Oleria can’t revoke access for, or change the roles of, employees who hold the Administrator or Full Access role, and can’t assign or remove those two roles. NetSuite rejects the change and Oleria reports the failure; nothing is partly applied.
  • Oleria checks the employee’s current state first and makes no change if it’s already as requested.
  • Oleria confirms every change by reading it back from NetSuite.
  • A reversal only undoes the change Oleria made. If someone changed the same user in NetSuite in the meantime, Oleria leaves it as is.

​
Known limitations

  • Records and transactions aren’t discovered. This integration covers identities, roles, groups, access tokens, and login activity, not access to individual records, subsidiaries, or saved searches.
  • MFA and SSO status is limited. NetSuite requires two-factor authentication for Administrator and other highly privileged roles, so Oleria reports MFA as required for administrators. For other users, two-factor enrollment and SSO settings aren’t available through the API and show as unavailable, not as disabled.
  • Customer, vendor, and partner center users aren’t discovered. Only employees are listed as accounts. Their access tokens and logins still appear.
  • Record changes aren’t included. Login activity comes from the Login Audit Trail. Changes to records, roles, and settings aren’t synced as activity.
  • OAuth 2.0 client credentials mappings aren’t inventoried. Only token-based authentication access tokens are listed.
  • API access is matched by permission name. Oleria marks a user as having API access when one of their roles grants a web services or access token permission.

​
Contact us

For questions about this integration, contact us at support@oleria.com.