Security


Copy Audit and unified audit across databases

The client had a special request: copy the audit data to another database – once -, for compliance reasons.

The Audit data does not let it copy so easily. Before was usually in SYS schema, now it belongs to a special AUDSYS user. None allows to export data by default.

To copy the audit data from one database to another, there is special expdp argument: “include=audit_trails”. This only works in full export mode:

expdp system@server.domain.ch\pdb_service \
  DIRECTORY=expdp \
  DUMPFILE=audit_data_$(date +%Y%m%d_%H%M).dmp  \
  FULL=Y \
  INCLUDE=AUDIT_TRAILS 

On the new database, I’ve imported to a new user “old_audit” and specific tablespace, which I created before the import

SYS@DB1.PDB1> create tablespace unified_audit_ts;
SYS@DB1.PDB1> alter user system quota unlimited on unified_audit_ts;

SYS@DB1.PDB1> create user old_audit no authentication 
    default tablespace unified_audit_ts 
    quota unlimited on unified_audit_ts;

At the end I’ve imported the data, using remap_schema and remove the segment attributes, so all go to the new default tablespace:

impdp system@server.domain.ch\new_pdb \
  DIRECTORY=expdp 
  DUMPFILE=$(ls -tr audit_data*.dmp | tail -n1) 
  REMAP_SCHEMA=sys:old_audit 
  REMAP_SCHEMA=audsys:old_audit 
  TRANSFORM=SEGMENT_ATTRIBUTES:N

Database specific password wallet with 26ai client: the new SEPS_WALLET_LOCATION parameter

One inconvenient I had in the past with the usage of password wallets for Oracle users was their maintenance. With the years, there was just a lot of old entries. At the end you would do a script that would test all credentials and delete the ones which did not work or there was no more network alias equivalent.

In OCI, to connect to Autonomous Databases, there is since few years a possibility to have a wallet parameter defined at the network connection or tnsnames, using “(SECURITY=(wallet_location=/home/oracle/wallets/databases)))” – sometimes also seen using “my_wallet_directory”. But this only works for TLS connections and using certificates.

At my client I wanted to have a wallet per database, so that at the time of decommissioning, we just delete the whole wallet.

After looking around, I finally found out that using a 26ai client there are new parameters for the connection string and one of them is SEPS_WALLET_LOCATION, which allows to specify the location of the wallet for a specific entry.

This way I can do:

# My DB is ANJO_DB
$ echo $ORACLE_SID
ANJO_DB

# Create wallet
orapki wallet create -wallet $ORACLE_BASE/admin/$ORACLE_SID/wallet -pwd <wallet_pwd> -auto_login_local

# Add credential
orapki secretstore create_credential -wallet $ORACLE_BASE/admin/$ORACLE_SID/wallet -pwd <wallet_pwd> -connect_string $ORACLE_SID -username sys -password <sys_pwd>

# Add the wallet location in tnsnames
$ grep $ORACLE_SID $TNS_ADMIN/tnsnames.ora
ANJO_DB = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=anjovm1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ANJO_DB.WSL.HOME))(security=(SEPS_WALLET_LOCATION=/u00/app/oracle/admin/ANJO_DB/wallet)))

# Check with tnsping
tnsping ANJO_DB

TNS Ping Utility for Linux: Version 23.26.2.0.0 - Production on 30-JUN-2026 14:10:10

Copyright (c) 1997, 2026, Oracle.  All rights reserved.

Used parameter files:
/u00/app/oracle/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=anjovm1)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ANJO_DB.WSL.HOME))(security=(SEPS_WALLET_LOCATION=/u00/app/oracle/admin/ANJO_DB/wallet)))
OK (10 msec)

# Connect
$ sqlplus /@ANJO_DB
SQL*Plus: Release 23.26.2.0.0 - Production on Tue Jun 30 14:11:40 2026
Version 23.26.2.0.0

Copyright (c) 1982, 2026, Oracle.  All rights reserved.

Last Successful login time: Tue Jun 30 2026 13:52:44 +02:00

Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.30.0.0.0

SQL>

The documentation about this and other new elements of the tnsnames.ora file in Oracle 26ai are at https://docs.oracle.com/en/database/oracle/oracle-database/26/netrf/local-naming-parameters-in-tns-ora-file.html


How to Patch/Upgrade Java (JDK and JRE) in both Oracle Home and OEM Agent 13.5 home to latest certified version

A vulnerability scan from the customer pointed out many problems due to old patch backups and old JDK versions installed in a Oracle VM.

Many of the problems were with the files:

/u01/app/oracle/product/oem13c/agent/agent_13.5.0.0.0/oracle_common/jdk/jre/lib/rt.jar
/u01/app/oracle/product/19.0.0/dbhome_1/jdk/jre/lib/rt.jar

What I learned:

  • OEM Agent 13.5 default java version is 1.8.0_261, also after patching to the latest RU!
  • Oracle OPatch has its own JRE and this is not updated when applying latest JDK patch for Oracle Home
  • Upgrade JDK in Oracle Home is online

What I already knew:

Below how I “cleanup” the vulnerabilities at my customer VM. This instructions are for java version 1.8.0_481, latest certified for Oracle in January 2026 :

(more…)

TDE misconfigured and ORA-28353: failed to open wallet

I did script the TDE wallet configuration for my client.

  • Script 1 – Set the static parameters TABLESPACE_ENCRYPTION and WALLET_ROOT in the spfile.
  • Script 2 – Restart the database
  • Script 3 – Create the wallet, open the wallet, set the Masterkey, create the autologin wallet.

When running this 3rd script on a database it failed on the second command:

SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY  "wallet_password";
keystore altered.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password";
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "wallet_password"
*
ERROR at line 1:
ORA-28353: failed to open wallet
(more…)

Recover missing Masterkey – the famous ORA-28374 2

The client plugged a non-encrypted PDB into a CDB with TDE Encryption Wallet enabled. All works fine, we can read the data. However when trying to create a tablespace we get:

CDB1 SQL> create tablespace TBS_NEW;
Error starting at line : 1 in command -
create tablespace t1
Error report -
ORA-28374: typed master key not found in wallet
28374. 0000 -  "typed master key not found in wallet"
*Cause:    You attempted to access encrypted tablespace or redo logs with a typed master key not existing in the wallet.
*Action:   Copy the correct Oracle Wallet from the instance where the tablespace was created.

What is wrong?

(more…)

Encrypt the whole Oracle database online with TDE

Some programs are part of Oracle ISV – Independent Software Vendors – program and include various types of Oracle licenses. This allows to install the application database in various Oracle configurations. At my customer, the software includes Advance Security Option Oracle license. This was the reason we decided, even before moving to the cloud, to encrypt the database.

Here is a summary on how to perform full online encryption (TDE) of a database. The process is quite simple, but there are known surprises you might want to avoid.

(more…)

Configuring Hybrid Dataguard and have standby on OCI without the need of advanced security license

Hybrid Dataguard is a relatively new 19c feature that allows to have one side of a Dataguard configuration not encrypted. This is particularly useful when having a primary on premises and standby on a OCI, where tablespaces need to be encrypted. The main point is that it allows to spare a Advanced Security licenses on premises site.

Usages of Hybrid Dataguard can be during migration to the cloud or just as a high availability solution, when we have a small on-premises data center.

In the tutorial below I assume to have a primary database on premises without TDE, a we will create a standby in OCI with encryption enabled. The connection between on-premises and OCI is already configured and not explained.

(more…)

What is the Dell BSAFE Micro-Edition Suite MES ?

On the April 2021 Oracle Critical Patch Update, the top vulnerability affects “Oracle Database – Enterprise Edition Security (Dell BSAFE Micro Edition Suite)”.

But what exactly is this Dell MES ? The answer comes on MES v4.1.6 to v4.5 update 18c / 19c databases (Doc ID 2746801.1) note on My Oracle Support. It explains:

” The BSAFE MES is the underlying encryption libraries used by the Database and associated technologies and products to encrypt data at rest and in transit.  Upgrading to MES 4.5 resolves a number of vulnerabilities and provides the latest and most secure encryption ciphers.”

Please note that already on the January 2021 Oracle Release Update (19.10 or 18.13 there was an update of this component and “Anonymous RC4 Cipher” is not supported and does not work anymore.

Other ciphers are deprecated and should not be used anymore, as they are not fully secure:

  • Unix Crypt (MD5crypt) Password verified (used with Oracle Internet Directory OID)
  •  MD4, MD5, DES, and RC4-related algorithms used for instance in Network encryption (recommended to use AES)
  • SHA-1 used in DBMS_CRYPTO and Checksum in SQLNET (recommended to use SHA-2)
  • TLS 1.0 and TLS 1.1 used to network connection authentication to the database using certificates (recommended to use TLS 1.2)

In my case I had problems not with the database, but with an old OEM Agent, that could not communicate anymore to OEM (after the January RU on OEM). The solution was to remove all deprecated algoritms and find common accepted ones between to old agent and patched OEM.


Get unlock from PDB Lockdown profiles

PDB Lockdown profiles allow, on a multitenant database, to limit what a user can do inside a PDB.

One use case is when we want to avoid high privileged users (like Application DBAs) to perform ALTER SYSTEM or ALTER SESSION commands.

Quickly we would think we can do a PDB Lockdown profile like:

SQL> create lockdown profile lock_test;
SQL> alter lockdown profile lock_test disable statement=('ALTER SESSION');
SQL> alter lockdown profile lock_test disable statement=('ALTER SYSTEM');

The problem of this simple profile is that we can lock ourselves, also as common user, inside the lock profile.

Image that you want to enable this profile on several PDBs:

SQL> alter session set container=pdb01;
Session altered.

SQL> alter system set pdb_lockdown=lock_test;
System altered.

SQL> alter session set container=samplepdb;
ERROR:
ORA-01031: insufficient privileges

Oups, you cannot anymore change the active container!

(more…)

Attention OPatch 12.2.0.1.19: ‘opatch util cleanup’ command deletes files from /etc, /bin, /lib 2

On January 28th 2020 I reported to Oracle on a Severy 1 SR that the latest OPatch version tries to delete system files from /etc, /bin, /lib :

I wrote in the SR the use case, provided the logs. On my case, the opatch cleanup command “just” deleted the configuration files of my backup client in /etc (opatch deletes files that are writable by the user who calls the command – ‘oracle’/’grid’ in most of the cases).

The location from where ‘opatch cleanup util’ tries to delete files depends from where you call it! So, if you call from / or from $ORACLE_BASE or from $ORACLE_HOME/OPatch you’ll get different behaviours!

It took two months until I got an answer to that SR, saying a bug was created and it will be fixed on the next version of OPatch:

Today there was a release of April 2020 Security patches, the latest Oracle Patch Bundles. To my surprise, for Oracle versions 12.2, 18c and 19c, there is the requirement of using OPatch 12.2.0.1.19 version, the exact same version that has this dangerous bug!

The bug reported end of January was not yet fixed! At least, on OPatch readme there is now a warning:

So, be careful until then and do not use ‘opatch util cleanup’. Anyway, this command is not anymore needed, as a cleanup (without deleting any wrong file) of the $ORACLE_HOME/.patch_storage directory is automatically done at the end of the patching.