Oracle Database

Connect Oracle Database to Oleria to see every database user, role, and privilege, and the paths through which one user can act as another. Oleria also flags risky configurations, such as holders of the DBA role or SYSDBA, accounts with Oracle default passwords, and sensitive packages that PUBLIC can execute.

This integration supports self-managed Oracle Database (VM, on-premises, Exadata, OCI Base Database Service, and Oracle Database@Azure, @Google Cloud, and @AWS), Amazon RDS for Oracle, and OCI Autonomous Database. Oracle Database 19c or later is required. Pick the setup path that matches your deployment below.

What Oleria discovers

Area	Detail
Accounts	Every database user: local and common users, password-authenticated users, OS-authenticated (`IDENTIFIED EXTERNALLY`) users, directory-mapped (`IDENTIFIED GLOBALLY`) users, schema-only (`NO AUTHENTICATION`) accounts, and proxy users. Oracle-maintained and cloud-maintained accounts appear as system accounts. Users who hold `SYSDBA`, the `DBA` role, or a privilege-escalation system privilege are flagged as administrators. Oleria also shows each account’s status, profile, authentication type, creation date, last sign-in, and password change and expiry dates.
Roles and groups	Every role in each container, including `PUBLIC` and Oracle-maintained roles, with role-to-role nesting. Directory groups and app roles behind shared global schemas and global roles appear as groups. Their members come from your directory integration, not from Oracle.
Resources	The database, its containers (root and pluggable databases), schemas, objects, directories, and database links. Columns appear when a privilege is granted on them. Objects in Oracle-maintained schemas (for example `SYS`, `SYSTEM`, and `XDB`) appear only when they’re granted to one of your users or roles.
Access grants	System privileges, schema privileges (Oracle Database 23ai), object, column, and directory grants, database links, schema ownership, and administrative privileges such as `SYSDBA`, `SYSOPER`, and `SYSBACKUP`. Grants `WITH ADMIN OPTION` and `WITH GRANT OPTION` are marked.
Impersonation	Proxy users, `BECOME USER` and `ALTER USER`, definer’s-rights code, and directory groups that sign in through a shared global schema.
Risk signals	See Risk signals below.
Activity	Unified audit trail events: sign-in success and failure, proxy sign-ins, sign-outs, user and role changes, account locks and unlocks, password changes, role and privilege grants and revokes, and system, audit policy, and profile changes. Statements that fail for lack of privilege appear as denied access. Requires the audit setup below.

Risk signals

Oleria reports these risks for Oracle Database:

Oracle DBA role
Administrative privilege in the password file - SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSDG, SYSKM, or SYSRAC.
Account with an Oracle default password
Privilege-escalation system privilege - for example GRANT ANY ROLE, ALTER USER, BECOME USER, EXECUTE ANY PROCEDURE, or ALTER SYSTEM.
ANY data privilege - for example SELECT ANY TABLE, UPDATE ANY TABLE, EXEMPT ACCESS POLICY, or SELECT ANY DICTIONARY.
Privilege held WITH ADMIN / GRANT OPTION
Explicit grant to PUBLIC
PUBLIC can execute a sensitive Oracle package (CIS) - for example UTL_FILE, UTL_HTTP, DBMS_SCHEDULER, or DBMS_SQL.
Public database link with stored credentials
Password never expires
No account lockout
No password complexity check
Password expired
Insecure initialization parameter - REMOTE_OS_AUTHENT=TRUE, O7_DICTIONARY_ACCESSIBILITY=TRUE, SEC_CASE_SENSITIVE_LOGON=FALSE, or AUDIT_SYS_OPERATIONS=FALSE (AUDIT_SYS_OPERATIONS is checked on self-managed databases only).

The connector user’s own profile (below) sets an unlimited password lifetime and no lockout, so Oleria reports Password never expires, No account lockout, and possibly No password complexity check on that user. Oleria doesn’t report the privileges you grant the connector user for remediation actions as risks.

Prerequisites

A dedicated database user for Oleria, with the read privileges listed for your deployment below. You can’t use SYS, because it always signs in as SYSDBA.
Network access from Oleria to your database listener on the configured port. See Network and encryption.
Optional: the AUDIT_VIEWER role and audit policies, if you want Oleria to show activity. See Enable audit policies for activity.
Optional: additional privileges, if you also want to run remediation actions. See Remediation actions.

Before it saves the integration, Oleria checks that the connector user can read every required data dictionary view (users, roles, privileges, objects, proxies, profiles, procedures, database links, and directories). If it can’t read one, Oleria refuses the connection with an error that names the missing grant. Optional views aren’t checked; see Known limitations.

Choose what one integration covers

The Service Name you connect to decides the scope:

A pluggable database (PDB) or non-CDB service - Oleria covers that database. This is the only option for Amazon RDS for Oracle and OCI Autonomous Database.
The root service of a self-managed container database (CDB$ROOT) - Oleria covers the root and every open PDB with one integration. This requires a common user (C## prefix) with CONTAINER_DATA = ALL. Without any CONTAINER_DATA setting, Oracle silently shows only the root, so Oleria refuses the connection.

Set up the integration

Self-managed
Amazon RDS for Oracle
OCI Autonomous Database

Create a connector user in a PDB or non-CDB

Connect to the pluggable database (or the non-CDB) as an administrator and run:

CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
GRANT CREATE SESSION, SELECT ANY DICTIONARY TO oleria;

CREATE SESSION lets the user sign in.
SELECT ANY DICTIONARY lets Oleria read users, roles, and grants. It doesn’t expose password hashes.
The dedicated profile keeps the connector working. Under the DEFAULT profile, the password expires after 180 days and 10 failed sign-ins lock the user. If your policy requires a finite FAILED_LOGIN_ATTEMPTS, keep PASSWORD_LOCK_TIME short, for example 1/24 (one hour), and rotate the password yourself.

To cover every PDB with one integration instead, skip this step and use the next one.

Create a common connector user in the root (optional)

Connect to CDB$ROOT as an administrator and run:

CREATE PROFILE c##oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED CONTAINER = ALL;
CREATE USER c##oleria IDENTIFIED BY "<strong password>" PROFILE c##oleria_profile CONTAINER = ALL;
GRANT CREATE SESSION, SELECT ANY DICTIONARY TO c##oleria CONTAINER = ALL;
ALTER USER c##oleria SET CONTAINER_DATA = ALL CONTAINER = CURRENT;

Set CONTAINER_DATA = ALL. If the user has no CONTAINER_DATA setting, Oleria refuses the connection. If it lists specific containers, Oleria covers only those.

Grant access to the audit trail (optional)

To show activity, grant the audit viewer role:

GRANT AUDIT_VIEWER TO oleria;

For a common user in the root, use GRANT AUDIT_VIEWER TO c##oleria CONTAINER = ALL;. Then enable the audit policies in Enable audit policies for activity.

Choose the encryption

Decide how Oleria encrypts the connection. See Network and encryption. If your listener has a TLS (TCPS) endpoint with a certificate from a publicly trusted certificate authority, use Verified TLS.

Create a connector user

Connect to the database as the RDS master user. On a container database (CDB) instance, connect to the tenant database, not the root. Run:

CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
GRANT CREATE SESSION, SELECT ANY DICTIONARY TO oleria;

Grant access to the audit trail (optional)

The RDS master user can’t grant AUDIT_VIEWER. Grant read access to the audit trail instead:

GRANT SELECT ON AUDSYS.UNIFIED_AUDIT_TRAIL TO oleria;

Then enable the audit policies in Enable audit policies for activity.

Find your instance endpoint

In the AWS console, open your RDS instance and copy the endpoint. You enter it as Host when you connect. Oleria doesn’t look up the endpoint and needs no access to your AWS account.

Choose the encryption

Native network encryption over TCP works with the default option group on the default port 1521.
Verified TLS requires the SSL option in the instance’s option group. The TLS port is commonly 2484. Oleria verifies the certificate against the Amazon RDS certificate authority.

TLS without certificate verification isn’t available for RDS. See Network and encryption.

Create a connector user

Connect to the database as ADMIN and run:

CREATE PROFILE oleria_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED FAILED_LOGIN_ATTEMPTS UNLIMITED;
CREATE USER oleria IDENTIFIED BY "<strong password>" PROFILE oleria_profile;
GRANT CREATE SESSION, SELECT_CATALOG_ROLE TO oleria;

Use SELECT_CATALOG_ROLE, not SELECT ANY DICTIONARY. On Autonomous Database, SELECT ANY DICTIONARY doesn’t reach the dictionary views Oleria reads.

Grant access to the audit trail (optional)

To show activity, grant the audit viewer role:

GRANT AUDIT_VIEWER TO oleria;

Then enable the audit policies in Enable audit policies for activity.

Note the connection details

In the OCI Console, open the database and select Database connection. From a connection string, note the host, the port, and the service name.

Prepare TLS

Autonomous Database accepts only TLS connections, and Oleria always verifies the server certificate. Choose one:

Mutual TLS (wallet). Download the database wallet from Database connection, extract cwallet.sso from the ZIP file, and base64-encode it on one line:
# Linux base64 -w0 cwallet.sso # macOS base64 -i cwallet.sso
You paste the output into the Wallet (cwallet.sso, base64, optional) field. Mutual TLS uses port 1522.
One-way TLS (no wallet). On the database details page, edit Mutual TLS (mTLS) authentication and clear Require mutual TLS (mTLS) authentication. Autonomous Database requires an access control list or a private endpoint for this. Leave the wallet field empty. One-way TLS works on port 1521 or 1522.

If you restrict access with an access control list, contact support@oleria.com for the addresses to allow.

Network and encryption

Oleria connects directly to your database listener. Your network must allow connections from Oleria to the listener’s host and port.

Host must be a host name or IP address. Oleria refuses loopback, link-local, and cloud metadata addresses.
If the listener redirects the connection, for example a RAC SCAN listener, Oleria follows up to four redirects. With TLS, Oleria refuses a redirect to a non-TLS endpoint.

Choose one of these Encryption options:

Option	What it does	Available for
Native network encryption over TCP	Connects over TCP and requires Oracle native network encryption and integrity. This is the default for self-managed and RDS.	Self-managed, Amazon RDS for Oracle
TLS without certificate verification	Encrypts with TLS but doesn’t verify the server certificate. Use it only for a self-signed listener certificate.	Self-managed only
Verified TLS	Encrypts with TLS and verifies the server certificate. On self-managed databases, the certificate must chain to a publicly trusted certificate authority. On RDS, Oleria uses the Amazon RDS certificate authority. On Autonomous Database, it’s the only option.	All deployments

Native network encryption protects against eavesdropping, but it doesn’t authenticate the server. An attacker who can intercept the connection could capture data that lets them crack the connector user’s password offline. Use Native network encryption over TCP only on a trusted network, such as a private link, VPN, or peered VPC. Use Verified TLS wherever your listener has a TLS endpoint.

With Native network encryption over TCP, Oleria refuses a server that turns native encryption off, for example with SQLNET.ENCRYPTION_SERVER = REJECTED. After sign-in, Oleria also requires AES encryption and SHA-2 integrity. If the connection is refused for weak algorithms, set SQLNET.ENCRYPTION_TYPES_SERVER to AES algorithms and SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER to SHA-2 algorithms in the server’s sqlnet.ora. To connect with Verified TLS to a host name that the certificate doesn’t carry, such as an IP address, alias, or load balancer name, enter the certificate’s full subject in Server Certificate DN (optional). Oleria then matches the subject instead of the host name, and still verifies the certificate chain.

Enable audit policies for activity (optional)

Complete this section only if you want Oleria to show activity. Oleria reads the unified audit trail, which records only what an enabled audit policy audits. A default database records failed sign-ins and only some grants and revokes. It doesn’t record successful sign-ins.

PDB, non-CDB, RDS, or Autonomous
CDB root

In the database the integration connects to, run:

AUDIT POLICY ORA_ACCOUNT_MGMT;
CREATE AUDIT POLICY oleria_logons ACTIONS LOGON, LOGOFF;
AUDIT POLICY oleria_logons EXCEPT oleria;

ORA_ACCOUNT_MGMT records user creation, changes, and deletion, and role and privilege grants and revokes.
oleria_logons records successful and failed sign-ins, and sign-outs, of every user except the connector user.

A policy enabled in CDB$ROOT covers only the root unless it’s a common policy. In CDB$ROOT, run:

CREATE AUDIT POLICY c##oleria_account_mgmt ACTIONS CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, GRANT, REVOKE CONTAINER = ALL;
AUDIT POLICY c##oleria_account_mgmt;
CREATE AUDIT POLICY c##oleria_logons ACTIONS LOGON, LOGOFF CONTAINER = ALL;
AUDIT POLICY c##oleria_logons EXCEPT c##oleria;

Keep the default ORA_SECURECONFIG policy enabled. Enable each policy for all users, as shown. A policy enabled only BY certain users, with a WHEN condition, or EXCEPT users other than the connector user records only part of the activity.

If the connector user can’t read the audit trail, the sync continues without activity. It doesn’t fail.

Connect Oracle Database to Oleria

Open the integration

Complete the connection form

Select your Deployment first. The form updates to show only the fields that deployment needs.

Self-managed
Amazon RDS for Oracle
OCI Autonomous Database

Field	Notes
Deployment	Select Self-managed.
Host	Required. The host name or IP address of the database listener, without a port or path. An IPv6 address may be in brackets.
Port	Defaults to `1521`.
Service Name	Required. A PDB, non-CDB, or `CDB$ROOT` service. Letters, digits, and `_ . - $ #` only.
Username	Required. The user you created above, for example `oleria` or `c##oleria`. Can’t be `SYS` or contain a colon.
Password	Required.
Encryption	Native network encryption over TCP (default), TLS without certificate verification, or Verified TLS.
Server Certificate DN (optional)	Shown with Verified TLS. The full subject the server certificate must carry, for example `CN=db.example.com,O=Example`. Replaces the host name check.

Field	Notes
Deployment	Select Amazon RDS for Oracle.
Host	Required. The instance endpoint.
AWS Region (optional)	An AWS region name, for example `us-east-1`. Used only to link to the instance in the AWS console.
RDS Instance Identifier (optional)	Used only to link to the instance in the AWS console. Oleria always connects to the endpoint entered as Host.
Port	Defaults to `1521`. With Verified TLS, enter the TLS port, commonly `2484`.
Service Name	Required. The service name of the database, or of the tenant database on a CDB instance.
Username	Required. The user you created above.
Password	Required.
Encryption	Native network encryption over TCP (default) or Verified TLS. TLS without certificate verification is listed but refused for RDS.
Server Certificate DN (optional)	Shown with Verified TLS. Use it only if you connect through a name the certificate doesn’t carry.

Field	Notes
Deployment	Select OCI Autonomous Database.
Host	Required. The host from the database’s connection string.
Port	Defaults to `1522`, the only port for mutual TLS.
Service Name	Required. The service name from the database’s connection string.
Username	Required. The user you created above.
Password	Required.
Server Certificate DN (optional)	The full subject the server certificate must carry. Leave it empty unless you connect through a name the certificate doesn’t carry.
Wallet (cwallet.sso, base64, optional)	Required for mutual TLS. The base64-encoded `cwallet.sso` on one line. Leave it empty for one-way TLS.

Autonomous Database has no Encryption field. Oleria always uses Verified TLS.

Complete the connection

Select Authenticate. Oleria signs in, detects the deployment and scope, and checks that the connector user can read every required view. Oleria then saves the integration and begins the first sync.

After you save the integration, you can change only the Password and the Wallet (cwallet.sso, base64, optional). Leave either empty to keep the stored value. To change any other field, connect a new integration.

Verify the integration

Confirm Oracle Database appears on the Connected tab of your Oleria Integrations page. After the first sync completes, you can review the discovered accounts, roles, resources, access grants, risks, and activity in your Oleria workspace. If the connection is refused with an error that names a missing grant, grant it to the connector user and try again.

After a failed sign-in, Oleria waits up to 10 minutes before it tries the same password again, so repeated retries can’t lock the connector user. Updating the password in Oleria, or testing the connection again, retries immediately.

Remediation actions

Oleria validates the connector user’s privileges before it runs each action, and reads the current state first. If nothing needs to change, Oleria records the action as a no-op and never reverts it. Lock Oracle User Account also requires approval in Oleria.

Action	What it does	Privileges the connector user needs
Grant Oracle Role to User	Grants a role to a user (`GRANT role TO user`). Reversible: the revert revokes it.	`GRANT ANY ROLE`, or the role granted `WITH ADMIN OPTION`
Revoke Oracle Role from User	Revokes a role from a user (`REVOKE role FROM user`). Reversible: the revert grants it back with its original `ADMIN OPTION`, `DELEGATE OPTION`, and default role setting.	`GRANT ANY ROLE`, or the role granted `WITH ADMIN OPTION`, plus `ALTER USER` so the revert can restore the default role setting
Lock Oracle User Account	Locks the user (`ALTER USER … ACCOUNT LOCK`), then ends the user’s open sessions so access stops immediately. Reversible: the revert unlocks the user.	`ALTER USER`. To end sessions, `ALTER SYSTEM`, or on Amazon RDS, `EXECUTE` on `rdsadmin.rdsadmin_util`.

Grant the privileges for the actions you want to use:

PDB, non-CDB, or Autonomous
Amazon RDS for Oracle
CDB root

GRANT GRANT ANY ROLE, ALTER USER TO oleria;
GRANT ALTER SYSTEM TO oleria;

The RDS master user can’t grant ALTER SYSTEM. Oleria ends sessions through the RDS administration package instead:

GRANT GRANT ANY ROLE, ALTER USER TO oleria;
GRANT EXECUTE ON rdsadmin.rdsadmin_util TO oleria;

A grant made in the root reaches the PDBs only with CONTAINER = ALL. SET CONTAINER lets Oleria change local users in their own PDB.

GRANT GRANT ANY ROLE, ALTER USER, ALTER SYSTEM, SET CONTAINER TO c##oleria CONTAINER = ALL;

Without ALTER SYSTEM (or, on RDS, EXECUTE on rdsadmin.rdsadmin_util), the lock still succeeds, but the action output says that open sessions weren’t ended. Those sessions keep access until they disconnect.

Oleria refuses an action when:

the target is the connector user itself
the target is an Oracle-maintained user, a cloud-maintained user on Autonomous Database, or RDSADMIN or OPS$RDSDB on Amazon RDS
for a revoke, the role was granted commonly from CDB$ROOT (CONTAINER = ALL) and the integration connects to a PDB. Revoke it in CDB$ROOT with CONTAINER = ALL instead.
for a lock or unlock, the target is a common user and the integration connects to a PDB. Common users can be locked and unlocked only through a CDB$ROOT integration.
the database is open read-only, such as a Data Guard standby. Connect the integration to the primary database.
Database Vault blocks the statement. Authorize the connector user, for example with the DV_ACCTMGR role or a realm or command rule authorization.

If a user was temporarily locked out by failed sign-ins (LOCKED(TIMED)) before a lock action, the revert leaves the user permanently locked, because Oracle can’t re-create a timed lockout. The revert output says so.

Known limitations

No account creation or deletion: Oleria grants and revokes roles, and locks and unlocks users. It can’t create, drop, or change the password of a database user.
Unified auditing only: Oleria reads the unified audit trail. Traditional auditing (AUDIT_TRAIL=DB, DBA_AUDIT_TRAIL) and fine-grained auditing aren’t read. If your database writes only traditional audit records, Oleria shows no activity.
Statement text is redacted: Oleria removes literals, numbers, email addresses, and comments from audited statements, and never reads bind values. Oracle already masks passwords in audited statements.
Synthetic email: Most Oracle users have no email address. Oleria synthesizes one from the user name, container or database name, and host, which may not match a real address. Directory-mapped users with a user principal name use that address instead.
Group membership: Members of directory groups behind global users and roles come from your Microsoft Entra ID, Active Directory, or other directory integration, not from Oracle.
Restrictive security features aren’t evaluated: Database Vault, Oracle Label Security, Real Application Security, Data Redaction, and Virtual Private Database policies are recorded as labels, not evaluated. Oleria may show more access than these features allow.
Access outside the database isn’t visible: Operating system users who sign in as SYSDBA through OS groups (/ as sysdba) aren’t in the data dictionary. AWS and OCI identities that can reset the master or ADMIN password are visible only through your cloud integration.
Not covered: Scheduler jobs and credentials, and roles granted to PL/SQL code (code-based access control).
Partial reads don’t fail the sync: If the connector user can’t read an optional view, such as the password file users, default passwords, Database Vault, Data Redaction, or VPD views, Oleria syncs the rest and records what it couldn’t collect.
Containers that aren’t open: In a CDB$ROOT integration, PDBs that aren’t open are listed as skipped and aren’t scanned. Seed PDBs aren’t shown.
Very large databases: One integration handles about 8 to 10 million dictionary objects. For a larger container database, connect each PDB as its own integration.
Connector authentication: The connector user signs in with a password. Kerberos, RADIUS, token-based authentication, and Secure External Password Store wallets aren’t supported for the connector user.

Contact us

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

Overview

Generic connectors

Identity providers

HR systems

Cloud infrastructure

Applications

Ticketing

Messaging

What Oleria discovers

Risk signals

Prerequisites

Choose what one integration covers

Set up the integration

Network and encryption

Enable audit policies for activity (optional)

Connect Oracle Database to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us

​What Oleria discovers

​Risk signals

​Prerequisites

​Choose what one integration covers

​Set up the integration

​Network and encryption

​Enable audit policies for activity (optional)

​Connect Oracle Database to Oleria

​Verify the integration

​Remediation actions

​Known limitations

​Contact us

What Oleria discovers

Risk signals

Prerequisites

Choose what one integration covers

Set up the integration

Network and encryption

Enable audit policies for activity (optional)

Connect Oracle Database to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us