This type of error happens when the database is not able to find its credentials in its wallet. To troubleshoot, first check which wallet is picked by the database, then make sure that the wallet contains the DN and password for the database.

Enable the database logs to find the wallet location
Edit $ORACLE_HOME/network/admin/sqlnet.ora and add the following lines:

I am often involved in customer issues involving EUS and OUD, and wanted to share some tips and strategies that could help in this type of situation.

As I am working mainly on OUD, the first thing that I usually check is OUD access log. It is enabled by default and located in $OUD_INSTANCE/OUD/logs/access. This file contains a trace of all the operations received by OUD and is often a great help in understanding where the problem lies.

I usually configure OUD so that it also logs internal operations and LDAP controls:

To debug an EUS issue, I perform the failing EUS command and look at the logs generated by this command in OUD access log. For instance, I run sqlplus joe/password and check that the command triggered operations on OUD server:

if the command does not produce any log, this means that the authentication failed before the database actually contacted the OUD server. In this case, the root cause is likely to be a configuration issue on the database side (for instance the DB points to another LDAP server, or was not able to find its own DN/password in its wallet…)
The next debugging step will be to enable the logs on the database.

if the command produces logs in OUD, then the DB correctly points to OUD but there is either a communication issue (SSL, DB authentication…) or an EUS configuration issue (not able to find a user-schema mapping, unable to access the user’s password…)
Usually the last LDAP operation can provide hints on the root cause. For instance, if the user could not be associated to any shared schema, the last LDAP operation will be a SEARCH with a filter (objectclass=orcldbEntrylevelMapping) or (objectclass=orcldbSubtreelevelMapping) that does not find any entry (nentries=0).

After you have identified if the issue happens between the sql client and the DB or between the DB and OUD, you can also have a look at OUD Admin guide, which provides a checklist with common configuration issues in the Troubleshooting section of Chapter 31: Integrating Oracle Unified Directory with Oracle Enterprise User Security.

EUS does not support nested groups. This means that an enterprise role is granted to a user only if the user is a direct member of the group. But it is possible to leverage the LDAP_MATCHING_RULE_IN_CHAIN feature of active directory.

If you perform a ldapsearch against AD with a filter like this: (member:1.2.840.113556.1.4.1941:=cn=myuser,cn=users,dc=example,dc=com)
then AD will return all the groups the user myuser belongs to, including the nested groups.

The trick here is to transform the search filter performed by EUS (member=cn=myuser,cn=users,dc=example,dc=com) into a search with the matching rule (member:1.2.840.113556.1.4.1941:=cn=myuser,cn=users,dc=example,dc=com). This is done by creating a transformation in OUD proxy that operates on the member attribute in a search filter, and inserting this transformation in the processing.

EUS allows to define enterprise roles or proxy permissions and assign them to all the members of a given group. The issue is that EUS supports only static groups (it expects the groups to have the objectclass “groupofuniquenames” or “groupofnames”), and eusm will fail to grant an Enterprise Role to a dynamic group with the following error:

$ eusm grantRole enterprise_role=my_role domain_name=OracleDefaultDomain realm_dn=dc=example,dc=com group_dn=cn=dyngroup,ou=groups,dc=example,dc=com ldap_host=$OUD_HOST ldap_port=1389 ldap_user_dn="cn=directory manager" ldap_user_password=$PWD
EUSException: There is no such group in directory

Enterprise Manager will also fail with this type of message, even though the group exists:

Configure Domain : OracleDefaultDomain - Errors
my_role - cn=dyngroup,ou=groups,dc=example,dc=com : EUSException: There is no such group in directory

OUD provides a nice feature to workaround this issue: Virtual Static Groups. You need to create a virtual static group that will appear as a static group to Enterprise User Security, but mirrors a dynamic group.

For instance, perform a ldapmodify with the following ldif to define a virtual static group for your group cn=dyngroup:

During an EUS authentication, Oracle Database connects to OUD server using a simple bind over SSL. The username and the password are stored in the database wallet (default location is $ORACLE_BASE /admin/<ORACLE_SID>/wallet), and can be read using the mkstore command:

Starting with JDK 7u75 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. If your OUD server is running with JDK 7u75 or higher, you may experience issues with EUS when trying to authenticate:

The proper method to fix this issue is to apply patch 19285025 on the database, which will fix the LDAP library used to perform the connection between the database and OUD and use another algorithm.

A quick workaround is to edit the file $JRE_HOME/lib/security/java.security and remove “SSLv3” from the line defining jdk.tls.disabledAlgorithms (on the machine where OUD runs, for the java version used by OUD), then stop and restart OUD. This will allow OUD to use SSLv3. Note that this workaround should not be applied in production as SSLv3 is obsolete and should not be used anymore. The correct fix is to patch the database.

Enterprise Manager Cloud Control is a web-based interface that allows to administer Enterprise User Security. When connecting to OUD server, the interface may complain about an invalid password even though the credentials are correct.

The same problem happens with eusm 12c (the command-line tool delivered with Oracle Database):

The connection method between Enterprise Manager Cloud Control and OUD (or eusm 12c and OUD) is using SASL/DIGEST-MD5 authentication instead of a simple BIND. SASL/DIGEST-MD5 requires the password to be stored in a reversible password storage scheme, which means that the additional configuration steps are also needed: