Tag Archives: Enterprise User Security

Oracle Security EUS Snippets – Setup Proxy User Privileges

Since I’m always short of time for a longer blog post, I’ll just try a short one. Intended as a mini-series, I will show different configuration examples for Oracle Enterprise User Security. Today I’ll start with the configuration of EUS based proxy privileges. The environment I use is DOE, my Docker based Oracle Engineering environment. In particular the EUS configuration. For more information, see the corresponding GitHub repository oehrlis/doe respectively in the folder eus for the EUS specific environment.

Background

Database proxy privileges are used relatively often to give certain users rights to access a different schema. The user authenticates himself with his credentials and becomes a proxy user in the database. Below an example where the user RMAN, gets access to a different schema, specifically an other RMAN catalog schema (see also blog post about SEPS and RMAN).

CREATE USER rman IDENTIFIED BY welcome1;
CREATE USER rman19000 NO AUTHENTICATION QUOTA UNLIMITED ON rman_data;
GRANT RECOVERY_CATALOG_OWNER TO rman19000;
ALTER USER rman19000 GRANT CONNECT THROUGH rman; 
ALTER USER rman19000 DEFAULT TABLESPACE rman_data;

The following users were created

  • RMAN1900 is the schema owner for an Oracle 19c RMAN catalog stored in the tablespace RMAN_DATA. The user is created without any authentication but with a proxy privilege for the user RMAN.
  • RMAN is the user which will be used to connect to the catalog. There are other catalogs as well but not shown in this example
SQL> connect rman[RMAN19000]/welcome1@CATALOG
Connected.
SQL> show user
USER is "RMAN19000"
SQL> SELECT sys_context('userenv','PROXY_USER') PROXY_USER,
sys_context('userenv','SESSION_USER') SESSION_USER from dual;

PROXY_USER SESSION_USER
---------- ---------------
RMAN	   RMAN19000D

With pure database authentication or authorisation, the configuration of proxy users is easy. With Enterprise User Security, proxy privileges are no longer managed in the database but in the directory. Let’s take a look at that.

Database Configuration

For Enterprise User Security based proxy privileges, only ENTERPRISE USERS is specified in the database. The rest is done in the OracleContext of the directory. See also ALTER USER in Oracle® Database SQL Language Reference 19c.

ALTER USER scott GRANT CONNECT THROUGH ENTERPRISE USERS;

Enterprise User Security Configuration

The configuration can be either done via Oracle Enterprise Manager Cloud Control as documented in Oracle® Database Enterprise User Security Administrator’s Guide 19c or with the command line utility eusm. I prefer the command line utility as I often do not have an OEM by hand.

  • Create the proxy permission in the directory.
eusm createProxyPerm proxy_permission="Scott Proxy" \
domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt)
  • Define a target user for this proxy permission.
eusm addTargetUser proxy_permission="Scott Proxy" \
database_name="TEUS01" \
target_user="SCOTT" dbuser="system" \
dbuser_password=$(cat /u00/app/oracle/admin/TEUS01/etc/TEUS01_password.txt) \
dbconnect_string="eusdb.trivadislabs.com:1521/TEUS01.trivadislabs.com" \
domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt)
  • Explicit granting of proxy permission to the user KING. Can also be assigned to a group.
eusm grantProxyPerm proxy_permission="Scott Proxy" \
user_dn="cn=Ben King,ou=Senior Management,ou=People,dc=trivadislabs,dc=com" \
domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt)
  • Display the proxy permissions defined for the EUS default domain.
eusm listProxyPermissions domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt)
  • Display information for the proxy permission Scott Proxy
eusm listProxyPermissionInfo proxy_permission="Scott Proxy" \
domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt)
  • Display proxy permissions for the user KING.
eusm listProxyPermissionsOfUser \
user_dn="cn=Ben King,ou=Senior Management,ou=People,dc=trivadislabs,dc=com" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=eusoud.trivadislabs.com ldap_port=1389 \
ldap_user_dn=cn=eusadmin,cn=oraclecontext \
ldap_user_password=$(cat /u01/common/etc/eusadmin_pwd.txt) 

Using the Proxy Permissions

Let’s test the permissions and connect as user KING.

  • Regular connection to the database as schema owner SCOTT.
SQL> connect SCOTT/tiger@TEUS01
Connected.
SQL> show user
USER is "SCOTT"
SQL> select sys_context('userenv','PROXY_USER') PROXY_USER,
sys_context('userenv','SESSION_USER') SESSION_USER from dual;

PROXY_USER	SESSION_USER
--------------- ---------------
                SCOTT
  • Regular connection to the database as KING.
SQL> connect king/welcome1@TEUS01
Connected.
SQL> show user
USER is "KING"
SQL> select sys_context('userenv','PROXY_USER') PROXY_USER,
sys_context('userenv','SESSION_USER') SESSION_USER from dual;

PROXY_USER	SESSION_USER
--------------- ---------------
                KING
  • Proxy connection to the database
SQL> connect king[SCOTT]/welcome1@TEUS01
Connected.
SQL> show user
USER is "SCOTT"
SQL> select sys_context('userenv','PROXY_USER') PROXY_USER,
sys_context('userenv','SESSION_USER') SESSION_USER from dual;

PROXY_USER	SESSION_USER
--------------- ---------------
KING            SCOTT

Conclusion

Configuration of proxy permissions in connection with Oracle Enterprise User Security is not as complicated as you might think. It is also useful if shared global users need access to certain schemas. For example, a power user is allowed to access the application schema.

Losing the Oracle Wallet for Enterprise User Security

Having a reliable backup solution for your Transparent Data Encryption (TDE) or Enterprise User Security (EUS) Wallets, is beyond discussion. Nevertheless it can happen that you lose or corrupt the Oracle Wallet. With Transparent Data Encryption (TDE), this is really bad luck, because you can not access your encrypted data. Losing an EUS wallet is on the other side not really an issue. You can remove the database from your EUS LDAP directory (Oracle Unified Directory OUD or Oracle Internet Directory OID) and re-register the database. Although this is the fastest solution, it has some constraints. Un-register and re-register the database, means losing the EUS mappings. Alternatively you can manually create a new empty Oracle Wallet and reset the Database password using dbca.

Ok, first lets create a new empty wallet using mkstore:

oracle@urania:/u00/app/oracle/ [TDB11A] mkstore -wrl $ORACLE_BASE/admin/TDB11A/wallet -create
Oracle Secret Store Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter password:               
   
Enter password again:               

Alternatively you can use orapki to create an empty wallet. orapki is easier to use in scripts and supports auto login local wallets with -auto_login_local:

oracle@urania:/u00/app/oracle/ [TDB11A] orapki wallet create -wallet $ORACLE_BASE/admin/TDB11A/wallet/ -pwd <password> -auto_login
Oracle PKI Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Create an entry for the Database distinguished names (DN). This step is somehow necessary because dbca -regenerateDBPassword just creates the password entry but no new dn entry:

oracle@urania:/u00/app/oracle/ [TDB11A] mkstore -wrl $ORACLE_BASE/admin/TDB11A/wallet -createEntry ORACLE.SECURITY.DN cn=TDB11A_SITE1,cn=OracleContext,dc=postgasse,dc=org
Oracle Secret Store Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:               

Create an entry for the database password:

oracle@urania:/u00/app/oracle/ [TDB11A] mkstore -wrl $ORACLE_BASE/admin/TDB11A/wallet -createEntry ORACLE.SECURITY.PASSWORD manager
Oracle Secret Store Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:               
   

Recreate the database registration password using dbca:

oracle@urania:/u00/app/oracle/ [TDB11A] dbca -silent -configureDatabase -sourceDB TDB11A \
> -sysDBAUserName sys -sysDBAPassword </password><password> \
> -regenerateDBPassword true \
> -dirServiceUserName cn=orcladmin -dirServicePassword </password><password> \
> -walletPassword </password><password>
Preparing to Configure Database
6% complete
13% complete
66% complete
Completing Database Configuration
100% complete
Look at the log file "/u00/app/oracle/cfgtoollogs/dbca/TDB11A_SITE1/TDB11A11.log" for further details.

Verify the new password in the Oracle Wallet:

oracle@urania:/u00/app/oracle/ [TDB11A] mkstore -wrl $ORACLE_BASE/admin/TDB11A/wallet -viewEntry ORACLE.SECURITY.PASSWORD
Oracle Secret Store Tool : Version 11.2.0.4.0 - Production
Copyright (c) 2004, 2013, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:               
   
ORACLE.SECURITY.PASSWORD = S6usUGSNb#P1

This password can now be used to verify the LDAP Bind with ldapsearch using the database DN and the password:

oracle@urania:/u00/app/oracle/ [TDB11A] ldapsearch -h localhost -p 1389  \
> -D 'cn=TDB11A_SITE1,cn=OracleContext,dc=postgasse,dc=org' -w S6usUGSNb#P1 \
> -b 'cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc=postgasse,dc=org' '(objectclass=*)'
cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc=postgasse,dc=org
orclVersion=102000
objectClass=top
objectClass=orclContainer
objectClass=orclDBSecConfig
objectClass=orclDBSecConfig10i
orclDBVersionCompatibility=90000
cn=OracleDBSecurity
orclDBOIDAuthentication=PASSWORD

...

Or finally check login via SQLPlus as EUS user:

oracle@urania:/u00/app/oracle/ [TDB11A] sqh

SQL*Plus: Release 11.2.0.4.0 Production on Wed Sep 14 10:22:28 2016

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options

SQL> conn soe
Enter password: 
Connected.
SQL> @sousrinf
Database Information
--------------------
- DB_NAME		: TDB11A
- DB_DOMAIN		: postgasse.org
- INSTANCE		: 1
- INSTANCE_NAME 	: TDB11A
- SERVER_HOST		: urania
-
Authentification Information
----------------------------
- SESSION_USER		: EUS_USER
- PROXY_USER		:
- AUTHENTICATION_METHOD : PASSWORD
- IDENTIFICATION_TYPE	: GLOBAL SHARED
- NETWORK_PROTOCOL	:
- OS_USER		: oracle
- AUTHENTICATED_IDENTITY: SOE
- ENTERPRISE_IDENTITY	: cn=soe,cn=People,dc=postgasse,dc=org
-
Other Information
-----------------
- ISDBA 		: FALSE
- CLIENT_INFO		:
- PROGRAM		: sqlplus@urania.postgasse.org (TNS V1-V3)
- MODULE		: SQL*Plus
- IP_ADDRESS		:
- SID			: 410
- SERIAL#		: 925
- SERVER		: DEDICATED
- TERMINAL		: pts/2

PL/SQL procedure successfully completed.

Depending on your Oracle Directory it may happen, that you run into ORA-28030. This can happen, if you password profile on the directory server has Reset Password on Next Login defined. To work around this issue you have to temporarily disable Reset Password on Next Login in the password profile. This issue is also discussed in the MOS Note 558119.1 ORA-28030 After Regenerating Wallet Password Using dbca.

DOAG Databank 2016

Just finished my presentation about Enterprise User Security at the DOAG Datenbank 2016 in Düsseldorf. It is about how to set up and use Enterprise User Security with Oracle Unified Directory. The slides are available for download  DOAG__EUS_mit_OUD_Oehrli.pdf. Thanks to Florian I can also offer some, ok one “impressions” from my presentation 🙂 As promised in my presentation, I’ll post a few more information from my engineering and tests on Oracle Unified Directory in the next weeks. All of them will be tagged with Oracle Unified Directory.

Foto_Praesentation

WALLET_LOCATION in sqlnet.ora for Container Databases

Recently I’ve setup Oracle Enterprise User Security (EUS) with Oracle Unified Directory (OUD) on my favorite linux test system. Among regular 11.2.0.4 and 12.1.0.2 databases I do also have a 12.1.0.2 Container Database. EUS work like a charm on the regular databases but not on the PDB.

SQL> conn soe
Enter password: 
ERROR:
ORA-28305: WALLET_LOCATION in sqlnet.ora file for container database is not
supported.


Warning: You are no longer connected to ORACLE.

The error seems to be a bit weird. So fare I’ve explicitly set the wallet location to make sure the wallet it somewhere I decided. I have a shared sqlnet.ora file, where I use $ORACLE_SID in the path for the different instances. An excerpt from my sqlnet.ora file

...
WALLET_LOCATION =
  (SOURCE =
    (METHOD = File)
    (METHOD_DATA = (DIRECTORY = /u00/app/oracle/admin/$ORACLE_SID/wallet)))

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)
   (METHOD_DATA=
    (DIRECTORY=/u00/app/oracle/admin/$ORACLE_SID/tde_wallet/)))
...

The action described for the Oracle Error Message ORA-28305 is clear. Remove WALLET_LOCATION from sqlnet.ora to use EUS also for Container Databases.

SQL> conn soe
Enter password: 
Connected.
SQL> @sousrinf
Database Information
--------------------
- DB_NAME		: TDB12C
- DB_DOMAIN		:
- INSTANCE		: 1
- INSTANCE_NAME 	: TDB12C
- SERVER_HOST		: o-sec
-
Authentification Information
----------------------------
- SESSION_USER		: C##SOE
- PROXY_USER		:
- AUTHENTICATION_METHOD : PASSWORD
- IDENTIFICATION_TYPE	: GLOBAL SHARED
- NETWORK_PROTOCOL	:
- OS_USER		: oracle
- AUTHENTICATED_IDENTITY: SOE
- ENTERPRISE_IDENTITY	: cn=soe,cn=Users,dc=trivadistraining,dc=com
-
Other Information
-----------------
- ISDBA 		: FALSE
- CLIENT_INFO		:
- PROGRAM		: sqlplus@o-sec (TNS V1-V3)
- MODULE		: SQL*Plus
- IP_ADDRESS		:
- SID			: 39
- SERIAL#		: 47117
- SERVER		: DEDICATED
- TERMINAL		: pts/6

PL/SQL procedure successfully completed.

The corresponding Oracle Bug 17758886 has been rejected as “not a Bug”. Oracle® Database Net Services Reference 12c Release 1 (12.1) WALLET_LOCATION does not mention PDB’s. There is only some information in the Oracle® Database Reference 12c Release 1 (12.1) Using LDAP_DIRECTORY_ACCESS with PDBs.

Conclusion

It seems, that with PDB’s it is not possible to explicitly set a wallet location. If the default location is not appropriate for your database environment, you have to use soft links use an alternative location for your wallet.

By the way, the wallet for TDE or for Secure External Password Store (SEPS) is not affected. You may still set WALLET_LOCATION for SEPS or ENCRYPTION_WALLET_LOCATION for TDE.

References

Some links related to this topic.

If time permits, I’ll write a few blog post about setting up and configuring EUS with OUD.