Can we use Oracle Key Vault to Store the DB Wallet for Enterprise User Security(EUS) ?

Oracle Key Vault (OKV) enables customers to easily deploy encryption and other security solutions by offering robust, central management of encryption keys, Oracle Wallets, Java Keystores, and credential files.

Enterprise User Security (EUS) is an Oracle Database EE feature which leverages the LDAP-compliant directory services to centralize database user and role management.

While implementing EUS, we need to register the DB with the LDAP which houses the users. This process creates a DB wallet which is used to securely communicate to the LDAP.

Question is if we can use OKV to store this wallet and EUS can refer to OKV instead of wallet stored locally in the DB thereby enhancing Security.

Here's what I could find out on this -

• When we register a database to OUD using DBCA, a local wallet will always be created containing the credentials for OUD access.

• This behavior cannot be changed, however the same wallet can be uploaded to OKV for a backup using okvutil utility.

• We cannot use/get the EUS credentials directly from OKV, they will always be taken from the local wallet [i.e. sqlnet.ora will not refer to OKV wallet].

• Even if the EUS wallet is uploaded in the OKV after the DB registration, we cannot do a 'direct connection' to OKV to retrieve EUS credentials from the virtual wallet.  Such a 'direct connection' is possible with TDE wallets (OKV directly provides access to the TDE master keys). The wallets containing SSL certificates or credentials can be uploaded to OKV and downloaded at will, but client cannot be configured to use them directly from OKV.

• There is no auto sync job for the wallet (local->OKV), once the credentials change, we need to re-upload the wallet in the OKV.

DB Security/Enterprise User Security (EUS) : Logon Trigger for auditing LDAP user logged on to Oracle DB

Use Case: 

Find a way to identify the AD domain user logged into a database configured with EUS

Pre-requisite: DB Users/Groups have already been centralized in an LDAP like Active Directory(AD) using Enterprise User Security (EUS)

Details:After logging in using sqlplus if we issue the following SQL we still see the shared schema user(which was used to map the Oracle DB Default Domain to the LDAP Container)

SQL> show user
GLOBAL_IDENT_SCHEMA_USER

Now the question is if we see a runaway query or a transaction causing blocking, how do we tie that back to the exact  external user instead of a Global Schema? How would we identify this information from within Oracle Enterprise Manager (OEM)session info?

A workaround could be to issue the following SQL query
SQL>  SELECT SYS_CONTEXT('USERENV','EXTERNAL_NAME') FROM DUAL;
SYS_CONTEXT('USERENV','EXTERNAL_NAME')

--------------------------------------------------------------------------------

cn=Sudipto Desmukh,cn=Users, dc=corp, dc=kdemo,dc=com

But wouldn't it be great if this is available in v$session for anyone to see real-time without specifically issuing a SQL query ?

We are able to create a logon trigger (attached) which populates enterprise user session information to client_info of V$SESSION.

create or replace trigger sys.on_logon after logon on database 

declare 

v_externalname varchar2(64) := ''; 

begin 

SELECT substr(sys_context('userenv','external_name'),1,63) into v_externalname FROM dual; 

if v_externalname is not null 

then 

DBMS_APPLICATION_INFO.SET_CLIENT_INFO (v_externalname ); 

end if; 

end; 

/ 

We should be able to pull up the blocking session information, if any from OEM tied to this enterprise user. An illustration of the result :

References:

1) How To Know The DN Of The Users Authenticated Via Enterprise User Security (EUS) Using Audit Records (Doc ID 465674.1)

2) How to Identify users using a shared global schema in Enterprise User Security