Category Archives: Enterprise User Security

SQL Developer 19.1 unable to use connection type ldap with OUD

Due to a tip from a work colleague, I came across a changed behaviour of the latest SQL Developer release. It affects the connection type LDAP respectively the use of an LDAP directory for the database name resolution. After specifying one or more LDAP servers it should actually be possible to select the corresponding context in the drop down list. But as of SQL Developer 19.1 this drop down list remains empty as you can see in the following images. As far as I can tell, this problem only occurs when using Oracle Unified Directory and the latest release of SQL Developer.

You can enable debugging in the SQL Developer to search for errors. But it is far easier to have a short look in the OUD access log. In the access log, you will instantly notice an error as you can see in the following excerpt of the access log.

[02/Jul/2019:04:34:51 +0000] CONNECT conn=276 from=172.20.0.1:55224 to=172.20.0.2:1389 protocol=LDAP
[02/Jul/2019:04:34:51 +0000] BIND REQ conn=276 op=0 msgID=1 type=SIMPLE dn="" version=3
[02/Jul/2019:04:34:51 +0000] BIND RES conn=276 op=0 msgID=1 result=0 authDN="" etime=0
[02/Jul/2019:04:34:51 +0000] SEARCH REQ conn=276 op=1 msgID=2 base="" scope=sub filter="(objectClass=orclContext)" attrs="cn,DN"
[02/Jul/2019:04:34:51 +0000] SEARCH RES conn=276 op=1 msgID=2 result=50 message="The request control with Object Identifier (OID) "1.2.840.113556.1.4.319" cannot be used due to insufficient access rights" nentries=0 etime=3
[02/Jul/2019:04:34:51 +0000] SEARCH REQ conn=276 op=2 msgID=3 base="" scope=one filter="(objectClass=orclContext)" attrs="cn,DN"
[02/Jul/2019:04:34:51 +0000] SEARCH RES conn=276 op=2 msgID=3 result=50 message="The request control with Object Identifier (OID) "1.2.840.113556.1.4.319" cannot be used due to insufficient access rights" nentries=0 etime=1
[02/Jul/2019:04:34:51 +0000] SEARCH REQ conn=276 op=3 msgID=4 base="" scope=base filter="(objectClass=orclContext)" attrs="cn,DN"
[02/Jul/2019:04:34:51 +0000] SEARCH RES conn=276 op=3 msgID=4 result=50 message="The request control with Object Identifier (OID) "1.2.840.113556.1.4.319" cannot be used due to insufficient access rights" nentries=0 etime=1
[02/Jul/2019:04:34:51 +0000] UNBIND REQ conn=276 op=4 msgID=5
[02/Jul/2019:04:34:51 +0000] DISCONNECT conn=276 reason="Client Disconnect"

There is an issue with an LDAP control as stated in error message: The request control with Object Identifier (OID) “1.2.840.113556.1.4.319” cannot be used due to insufficient access rights The control 1.2.840.113556.1.4.319 better known as Paged Results Control
allows the client to control the search results. In particular it is used to iterate through the search results a page at a time. And why is this of interest in connection with the SQL Developer?

When using the LDAP connection type, the SQL Developer uses an anonymous LDAP query to query the Oracle context and database name. Starting with SQL Developer 19.1, Oracle seems to use Paged Results Control, which makes sense if you have a large number of LDAP entries. By default Oracle Unified Directory does not allow the Paged Results Control for anonymous connections. Simplest solution to this problem is to allow Paged Results Control also for anonymous connections. For this you have to change the access control handler and the global act either by dsconfig or via OUDSM. The MOS Note 1932191.1 does provide the step by step solution how to modify the global act via dsconfig, OUDSM or by modifying the config.ldif. The latter is not recommended, because this requires a restart of the OUD server. Furthermore, the direct modification of config.ldif is only necessary in a few cases, e.g. when resetting the root user respectively directory manager password.

Procedure to modify the global aci via dsconfig:

  • Start dsconfig and directly modify the act of the Access Control Handler
dsconfig -h oud -p 4444 -D "cn=Directory Manager" -j $PWD_FILE -X set-access-control-handler-prop
  • Select the property global-aci
  • Select remove one or more values
  • Select the # that has Authenticated users control access which contains the 1.2.840.113556.1.4.319 OID)
  • Select use these values
  • Select finish and apply any changes to the Dsee Compat Access Control Handler
  • Start again dsconfig to add the new aci for the Access Control Handler
dsconfig -h oud -p 4444 -D "cn=Directory Manager" -j $PWD_FILE -X set-access-control-handler-prop
  • Select the property global-aci
  • Select add one or more values
  • When prompted with Enter another value for the global-aci property [continue]:, enter
    (targetcontrol="1.3.6.1.1.12|| 1.3.6.1.1.13.1 ||1.3.6.1.1.13.2 ||
    1.2.840.113556.1.4.319 ||1.2.826.0.1.3344810.2.3 ||
    2.16.840.1.113730.3.4.18 ||2.16.840.1.113730.3.4.9 ||
    1.2.840.113556.1.4.473 ||1.3.6.1.4.1.42.2.27.9.5.9"
    )
    (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///anyone";)
  • Select use these values
  • Select finish and apply any changes to the Dsee Compat Access Control Handler

The entire adjustment can also be done directly with two dsconfig commands.

First remove the global-aci for userdn all: (Make sure to remove the line wraps when copy/paste the aci)

dsconfig -h oud -p 4444 -D "cn=Directory Manager" -j $PWD_FILE -X -n set-access-control-handler-prop \
--remove global-aci:"(targetcontrol="1.3.6.1.1.12 || 1.3.6.1.1.13.1 || 1.3.6.1.1.13.2 || 1.2.840.113556.1.4.319 || 1.2.826.0.1.3344810.2.3 || 2.16.840.1.113730.3.4.18 || 2.16.840.1.113730.3.4.9 || 1.2.840.113556.1.4.473 || 1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///all";)"

Add the new global-aci for userdn anyone:

dsconfig -h oud -p 4444 -D "cn=Directory Manager" -j $PWD_FILE -X -n set-access-control-handler-prop \
--add global-aci:"(targetcontrol="1.3.6.1.1.12|| 1.3.6.1.1.13.1 ||1.3.6.1.1.13.2 ||1.2.840.113556.1.4.319 ||1.2.826.0.1.3344810.2.3 ||2.16.840.1.113730.3.4.18 ||2.16.840.1.113730.3.4.9 ||1.2.840.113556.1.4.473 ||1.3.6.1.4.1.42.2.27.9.5.9") (version 3.0; acl "Authenticated users control access"; allow(read) userdn="ldap:///anyone";)"

Now the SQL Developer can load the LDAP context and database name.

The question now is whether this change is a bug or a feature. In any case, it would make sense if the SQL Developer could alternatively allow to enter the Oracle context directly and thus avoid the anonymous query.

Some links related to this blog post:

Configure Oracle EUSM to use LDAPS

With the introduction of Oracle 18c, eusm is officially designated as an Enterprise User Security Utility. It is now officially documented of the Enterprise User Security Administrator’s Guide. Before we had to be content with the somewhat sparse MOS note 1085065.1 EUSM, Command Line Tool For EUS Administration and Some EUS Good to Knows. In addition, the tool was improved with the latest release. Up to and including Oracle 12c Release 2 it was not possible to establish a secure connection with the LDAP using eusm. The tool does use SASL authentication but still required always an unencrypted LDAP connection to the directory server. For sensitiv environments with enhanced security requirements like Banks, incurrence companies etc. is the use of unencrypted network traffic a nogo. But the new documentation for eusm starts with a short paragraph “About SSL Port Connectivity through EUSM to OID”, which made me confidence.

So there are additional parameters to support SSL:

  • ldap_ssl_port ssl port of the directory server.
  • keystore path to PKCS12 format of keystore. A file path parameter takes the path to the PKCS12 format of the keystore (for example, ewallet.p12 file)
  • key_pass to control the behavior of the keystore password eg. interactive or via commandline

Initial I did get confused by the example. A file named ewallet.p12 is usually an Oracle wallet. Thats why I did start to use an Oracle wallet as keystone for eusm. But this was complete rubbish. Leaning back and thinking again helped. eusm is written in java and the parameter is named keystone. Java and keystore results in a java kestore, doesn’t it? So I was a bit more successful with my second attempt.

Configure the keystore

As soon as one realised that the required keystore file is a java keystore of type PKCS12 it is straight forward. eusm just requires the root certificate to validate the OUD certificate during the initialisation of the LDAPS connection. In an enterprise environment this certificate can be obtained from the internal certification authority. Alternatively this may also be exported from an other keystore. In my EUS test environment I do not have an enterprise CA. Therefor I have to get the corresponding certificate directly from Oracle directory server.

Login to directory server to export the certificate.

keytool -export -noprompt -rfc \
-alias server-cert \
-keystore ${OUD_INSTANCE_HOME}/OUD/config/keystore \
-storepass $(cat ${OUD_INSTANCE_HOME}/OUD/config/keystore.pin) \
-file /u01/config/oud_trusted_cert.txt

Certificate stored in file

Copy the file to the database server and import it into a java keystore. The java keytool will create a new java keystore, if you specify a keystore file which does not yet exist. Do not to specify PKCS12 as the store type. You an either specify the keystore password interactively or use -storepass to provide the password via command line. I do use the password from the keystore pin file $ORACLE_BASE/network/admin/keystore.pin.

$ORACLE_HOME/jdk/bin/keytool -import -trustcacerts \
-alias oud_root_certificate \
-storetype pkcs12 \
-keystore $ORACLE_BASE/network/admin/keystore.jks \
-storepass $(cat $ORACLE_BASE/network/admin/keystore.pin) \
-import -file /u01/oud/oud_trusted_cert.txt

Owner: CN=oud, O=Oracle Unified Directory Self-Signed Certificate
Issuer: CN=oud, O=Oracle Unified Directory Self-Signed Certificate
Serial number: c8cff33
Valid from: Thu Feb 28 06:39:40 UTC 2019 until: Sat Feb 27 06:39:40 UTC 2021
Certificate fingerprints:
MD5: E2:C2:43:8B:CD:EB:95:9E:F1:FC:D8:C3:FF:A7:91:AF
SHA1: 80:0D:9E:89:1B:BC:69:99:02:6A:E7:B5:A6:D2:63:E9:59:5A:C3:BF
SHA256: C7:14:54:1A:C3:FE:28:72:6E:B0:16:82:42:C9:6E:3B:43:BE:D6:C7:3A:31:60:1B:
60:1D:8D:5E:7F:66:D9:7B
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 1024-bit RSA key
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore

List the content of your java keystore file.

$ORACLE_HOME/jdk/bin/keytool -list \
-keystore $ORACLE_BASE/network/admin/keystore.jks \
-storepass $(cat $ORACLE_BASE/network/admin/keystore.pin)

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

oud_root_certificate, Mar 1, 2019, trustedCertEntry,
Certificate fingerprint (SHA1): 80:0D:9E:89:1B:BC:69:99:02:6A:E7:B5:A6:D2:63:E9:
59:5A:C3:BF

The method is the same if you use an enterprise certificate. You just have to use the root certificate provided by the CA.

Usage of eusm

To establish a connection via SSL, you have to enter the java keystore and the keystore password or -K when invoking eusm. The following command does list the EUS Domain. The password is omitted and has to be specified via command line.

eusm listDomains realm_dn="dc=trivadislabs,dc=com" \
ldap_host=oud \
ldap_ssl_port=1636 \
ldap_user_dn="cn=eusadmin,cn=oraclecontext" \
ldap_user_password=eusadmin \
keystore=$ORACLE_BASE/network/admin/keystore.jks -K

Enter keystore password (key_pass):
LIST OF DOMAINS IN REALM: dc=trivadislabs,dc=com

OracleDefaultDomain

This command does list all the domain mappings. The password is now specified via parameter key_pass.

eusm listMappings domain_name="OracleDefaultDomain" \
realm_dn="dc=trivadislabs,dc=com" \
ldap_host=oud \
ldap_ssl_port=1636 \
ldap_user_dn="cn=eusadmin,cn=oraclecontext" \
ldap_user_password=eusadmin \
keystore=/u00/app/oracle/network/admin/keystore.jks \
key_pass=$(cat $ORACLE_BASE/network/admin/keystore.pin)

LIST OF DATABASE SCHEMA MAPPINGS::

Mapping Name: MAPPING0
Mapping Type: SUBTREE
Mapping DN: ou=People,dc=trivadislabs,dc=com
Mapping schema:EUS_USERS
Mapping Level :DOMAIN

Below you see an excerpt of the OUD access log file. The log entry for the CONNECT command does show the LDAPS protocol.

[01/Mar/2019:14:49:12 +0000] CONNECT conn=1111 from=172.18.0.3:34126 to=172.18.0.2:1636 protocol=LDAPS
[01/Mar/2019:14:49:13 +0000] BIND REQ conn=1111 op=0 msgID=1 type=SIMPLE dn="cn=eusadmin,cn=oraclecontext" version=3
[01/Mar/2019:14:49:13 +0000] BIND RES conn=1111 op=0 msgID=1 result=0 authDN="cn=eusadmin,cn=oraclecontext" etime=0
[01/Mar/2019:14:49:13 +0000] SEARCH REQ conn=1111 op=1 msgID=2 base="dc=trivadislabs,dc=com" scope=base filter="(objectclass=*)" attrs="orclversion"
[01/Mar/2019:14:49:13 +0000] SEARCH RES conn=1111 op=1 msgID=2 result=0 nentries=1 etime=1
[01/Mar/2019:14:49:13 +0000] SEARCH REQ conn=1111 op=2 msgID=3 base="cn=OracleDefaultDomain,cn=OracleDBSecurity,cn=Products,cn=OracleContext,dc=trivadislabs,dc=com" scope=one filter="(|(objectClass=orclDBEntryLevelMapping)(objectclass=orclDBSubtreeLevelMapping))" attrs="cn,orcldbdistinguishedname,orcldbnativeuser,objectclass"
[01/Mar/2019:14:49:13 +0000] SEARCH RES conn=1111 op=2 msgID=3 result=0 nentries=1 etime=1
[01/Mar/2019:14:49:13 +0000] DISCONNECT conn=1111 reason="Client Disconnect"

Conclusion

It took way to long until eusm becomes officially available. Since it was part of the binaries already since Oracle 11c. The fact that LDAPS is finally also supported is a significant step towards general improvement of the security of databases as well directory servers. It does getting much easier to harden directory servers and limit access on the LDAPS protocol. A little unfortunate in my opinion is the Oracle documentation regarding the configuration of the java keystore. A simple example would have simplified the setup.

Some links related to this blog post:

OUD 12c – SSLHandshakeException with “no cipher suites in common”

Recently I’ve update the java installation of my Oracle Unified Directory (OUD) 12.2.1.0.3 to the latest release. Java 1.8.0 update 202 to be exact (p28916775_180202_Linux-x86-64.zip). Actually a piece of cake, I’ve done this a few times in the past. My Enterprise User Security (EUS) test environment is running in Docker. A container for the database and an other one for the directory server. Updates are usually straight forward. Stop the containers, rebuild the images with the latest software / patches and recreate the containers. But not this time. After restarting OUD, my EUS authentication seems to be broken. When trying to log in, I did get a friendly ORA-01017 error.

 SQL> connect blofeld/******** ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE.
The control of the OUD access log file did show a cipher error.
 [21/Feb/2019:06:21:27] CONNECT conn=5 from=172.20.0.3:50376 to=172.20.0.2:1636 protocol=LDAPS [21/Feb/2019:06:21:27] DISCONNECT conn=5 reason="I/O Error" msg="no cipher suites in common"

Groundhog Day? Endless loop? I knew I did fix this before. So I’ve checked again the solution in MOS Note 2397791.1 and 2304757.1. According to my understanding the java.security file did look ok. The required legacy ciphers has been enabled by removing 3DES_EDE_CBC from the list of jdk.tls.disabledAlgorithms.
I finally did several tests with different Java versions (1.8.0 update 192 and 1.8.0 update 202) and different java.security files. In the third attempt, database authentication with EUS and OUD in combination with Java 1.8.0 Update 202 also worked. The solution was rather simple. I did use the java.security file from java 1.8.0 update 192 rather than using the new version and enable 3DES_EDE_CBC. Running diff on both files has uncovered the culprits.

 diff java.security java.security_202_default 645c645 < EC keySize < 224 --- > EC keySize < 224, 3DES_EDE_CBC, anon, NULL 700c700,701 < RC4_128, RC4_40, DES_CBC, DES40_CBC --- > RC4_128, RC4_40, DES_CBC, DES40_CBC, \ > 3DES_EDE_CBC
Or just the lines with jdk.tls.disabledAlgorithms.
 jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \ EC keySize < 224, 3DES_EDE_CBC, anon, NULL
A difference due to 3DES_EDE_CBC was to be expected, since I made the comparison to the standard file java.security and there this algorithm was not yet removed. But anon, NULL

is new. The list of disabled algorithms jdk.tls.disabledAlgorithms has been altered in Java 1.8.0 update 202. I could have seen this myself if I had looked through the release notes before installing the software 🙂 . There is a java bug related to this, see JDK-8211883 Disable anon and NULL cipher suites. The problem is now that my EUS is working again, but it will use unsecure and legacy algorithms. A proper fix of this issue has to be implemented in the LDAP / EUS stack of the Oracle database binaries.

Conclusion

First of all do read the release notes before updating production environments 🙂 . As always in IT, do a little change on one side can unexpectedly break something on the other side. The solution presented here can only be a workaround, because we endanger security with legacy algorithms. Oracle should soon update the LDAP / EUS stack in the Oracle binaries.

  • Fix for Java 1.8.0 update 192 and older: Use the solution described in MOS note 2304757.1 update java.security and remove 3DES_EDE_CBC from the jdk.tls.disabledAlgorithms
  • Fix for Java 1.8.0 update 201 and newer: Use either an old java.security which does work for you EUS environment or remove 3DES_EDE_CBC, anon and NULL from the jdk.tls.disabledAlgorithms in your java.security

Links

A few links related to this post:

  • OUD 12c – EUS Integration Failing with Message “no cipher suites in common”[2397791.1]
  • OUD 11g – EUS Authentication Fails with Error Message “no cipher suites in common”[2304757.1]
  • Java 1.8.0 update 201 release notes
  • Java bug JDK-8211883 Disable anon and NULL cipher suites
  • Preview of my Docker compose files to setup an Oracle Enterprise User Security Environment on Docker GitHub oehrlis/docker

DOAG Red Stack Magazin – Oracle Unified Directory in Docker

Mid June I wrote an article for the DOAG Red Stack magazin about my work on Oracle Unified Directory in Docker. Just about the same time I did my DOAG SIG Security presentation on the same topic. In the meantime the article has been published in the latest release of the DOAG Red Stack magazin. For this reason I use the opportunity to make the PDF version of the article available on oradba.ch. The article is written in German and available as Trivadis version as well Red Stack version. Although the articles versions differ only in the number of typos and layout.

None of the articles are currently available in English. On request I will write also articles about Oracle Unified Directory in English in the future. However, currently I still have a lot of ideas for more blog posts about database security, Oracle Enterprise User Security and Oracle Unified Directory on my to-do list. And blog posts I do usually write in English… 🙂

Articles in DOAG Red Stack Magazin

A while ago I wrote two articles for the DOAG Red Stack Magazin. In the meantime both articles have been published. For this reason I use the opportunity to make the PDF versions of the articles available on oradba.ch. The articles are written in German and available as Trivadis version as well Red Stack version. Although the articles versions differ only in the number of typos and layout.

None of the articles are currently available in english. On request I will write also articles about Oracle Unified Directory in English in the future. However, currently I still have a lot of ideas for blog posts about database security, enterprise user security and unified directory on my to-do list. And blog posts I usually write in english… 🙂

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