Thursday Feb 12, 2015

Sudden SSLv3-related errors in OUD explained

Starting with the January 20, 2015 Critical Patch Update releases (JDK 8u31, JDK 7u75, JDK 6u91 and above) the Java Runtime Environment has SSLv3 disabled by default. More details about this change is available at

Any attempt to connect to OUD with SSLv3 after applying the Java update above will fail with the error message below in the access logs:

[09/Feb/2015:12:51:48 +0100] DISCONNECT conn=102 reason="I/O Error" msg="Client requested protocol SSLv3 not enabled or not supported"
[09/Feb/2015:12:51:48 +0100] CONNECT conn=102 from=****:14123 to=****:1636 protocol=LDAPS

For testing purpose only, a procedure to re-enable SSLv3 is described in howewer it is time to identify the LDAP client culprit and apply the appropriate security fix so that it uses TLS.

Monday Feb 09, 2015

How to lock every account in a LDAP subtree with OUD

Let's assume a customer would like to lock every LDAP account in a given LDAP subtree stored in Oracle Unified Directory.
An account can be locked by setting the ds-pwp-account-disabled operational to true in the accounts to lock. More about account lockout and password mpolicy is available at Managing password policies

It is possible to assign the ds-pwp-account-disabled attribute to a set of accounts using virtual attributes.Virtual attributes are attribues whose values do not exist in persistent storage but are dynamically generated in some way.

OUD Collective attribute is a mean to manage virtual attributes. More about collective attributes at using-collective-attributes '

To lock every account in the oud=people,dc=example,dc=com subtree, create the following collective attribute:

dn: cn=myattr,dc=example,dc=com
objectclass: top
objectClass: subentry
objectClass: collectiveAttributeSubentry
objectClass: extensibleObject
ds-pwp-account-disabled;collective: true
subtreespecification: {base "ou=people", minimum 1}
collectiveConflictBehavior: virtual-overrides-real

Thursday Jan 22, 2015

ODSEE bundle patch available for download

ODSEE Bundle Patch has been Released for Directory Server and Directory Proxy Server. (Doc ID 1962875.1)

Search for Doc ID 1962875.1 in My Oracle Support for instructions.

Wednesday Jan 14, 2015

Configuring OUD to Support Multiple Enterprise User Security Domains

Configuring OUD to Support Multiple Enterprise User Security Domains

If your users and groups are stored in multiple domains, you must configure OUD to support multiple EUS domains. For example, a single OUD instance contains two EUS domains. One EUS domain stores users entries in Active Directory below cn=users,dc=ad1,dc=com. A second EUS domain stores user entries in a different Active Directory instance below cn=users,dc=ad2,dc=com. You must configure OUD to support each EUS domain.

To configure OUD to support multiple EUS domains:

  1. Configure OUD as if the primary domain is the single domain containing all your users and groups.

    In this example, the primary domain is dc=ad1,dc=com.

    Complete the tasks in 28.4 Oracle Unified Directory Used as a Proxy Server for an External LDAP Directory with Enterprise User Security

  2. Configure the secondary domain.

    In this example, the secondary domain is dc=ad2,dc=com.

    For this secondary domain, complete the steps in User Identities in Microsoft Active Directory

  3. Create a new naming context for the EUS domain, which is dc=ad2,dc=com in this example.

    Complete the steps in to configure Enterprise User Security for an existing Oracle Unified Directory Proxy Server instance.

  4. Update the Oracle context with the new naming context.

    1. Create an LDIF file.

      In the following myconfig.ldif example, make the following substitutions:

      • Replace dc=ad1,dc=com with the DN of your first domain.

      • Replace orclcommonusersearchbase with the users location in the secondary domain.

      • orclcommongroupsearchbase with the groups location in the secondary domain.

      dn: cn=Common,cn=Products,cn=OracleContext,dc=ad1,dc=com
      changetype: modify
      add: orclcommonusersearchbase
      orclcommonusersearchbase: cn=users,dc=ad2,dc=com
      orclcommongroupsearchbase: cn=groups,dc=ad2,dc=com
    2. Update OUD configuration using the LDIF file you created in step 4a.

      ldapmodify -h oudhost -p 1389 -D "cn=directory manager" 
      -w password -f myconfig.ldif

Friday Oct 17, 2014

Troubleshooting OUD/EUS integration: Invalid username/password; logon denied

Oracle's Enterprise User Security (EUS) enables you to store user identities in LDAP-compliant directory service for Oracle Database authentication.

Enterprise User Security enables you to centrally manage database users across the enterprise. Enterprise users are created in LDAP-compliant directory service, and can be assigned roles and privileges across various enterprise databases registered with the directory.

Users connect to Oracle Database by providing credentials that are stored in Oracle Unified Directory. The database executes LDAP search operations to query user specific authentication and authorization information.

Here are steps to troubleshoot EUS when the "Invalid username/password; login denied" is reported to DB users by EUS:

First, this error is reported in 2 cases:

  • the DB is not able to find a LDAP user that corresponds to the provided name on the DB side, 
  • the user password is invalid.
Assuming the password is correct, follow the procedure below to identify the root cause:

#1 Check EUS configuration

The database reads its configuration from the entry cn=common,cn=products,cn=oraclecontext,$BASEDN:

  • The location of users and groups is configured in the attributes orclcommonusersearchbase and orclusercommongroupsearchbase. They are referred to as users and groups containers.
  • The username supplied to sqlplus must correspond to the value of orclcommonnicknameattribute in the user entry. For instance, if I connect to sqlplus using sqlplus joe/password, and orclcommonnicknameattribute=uid, then the database will look for an entry containing the attribute uid=joe.
  • The user entry DN must start with orclcommonnamingattribute. For instance, if orclcommonnamingattribute=cn, the user entry must be cn=joeuser,<orclcommonusersearchbase>.

You can read the configuration using the following command:

$ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -b cn=common,cn=products,cn=oraclecontext,$BASEDN  "(objectclass=*)" orclcommonusersearchbase orclcommongroupsearchbase orclcommonnicknameattribute orclcommonnamingattribute
dn: cn=Common,cn=Products,cn=OracleContext,dc=eusovd,dc=com
orclcommonusersearchbase: ou=people,dc=eusovd,dc=com
orclcommongroupsearchbase: ou=groups,dc=eusovd,dc=com
orclcommonnicknameattribute: uid
orclcommonnamingattribute: cn

#2 Check the User Entry

You  must ensure that there is an LDAP entry in the user container that matches the username supplied by SQL+. Target LDAP entry must be an instance of inetorgperson and contain the attribute defined in orclcommonnicknameattribute:

$ OracleUnifiedDirectory/bin/ldapsearch -h $LDAPSERVER -p $PORT -D $DN -w $PWD -b ou=people,$BASEDN  "(uid=joe)"                         
dn: cn=joe,ou=people,dc=eusovd,dc=com
userPassword: {SSHA}DdW5je5GCUnT2jVTeMdfPR9NWwkBt40FwWImpA==
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: top
uid: joe
cn: joe
sn: joe

#3 Check the User-schema mappings

If the user entry exists and can be read by the database entry, the problem can be that there is no user-schema mapping. EUS maps the LDAP user entry to a database schema following a mapping rule that is defined in Enterprise Manager console. The mapping associates either a user DN to a schema or all users of a subtree to a schema. It can be defined at the domain level or at the database level.

#4 Check the global schema associated with the user

If there is a user-schema mapping, ensure that the schema has the CONNECT privilege.

The global schema was defined using the following commands:

SQL> CREATE USER global_ident_schema_user IDENTIFIED GLOBALLY;
User created.
SQL> GRANT CONNECT TO global_ident_schema_user;

Wednesday Nov 06, 2013

New Oracle White Paper about Directory Services Integration with Database Enterprise User Security

I've written a new Oracle White Paper about Directory Services Integration with
Database Enterprise User Security based on 2 recent posts, and

The official document is available at

Friday Aug 30, 2013

Migrating SSL Certificates to OUD

By default, self-signed certificates are automatically asssigned to OUD instances.

In some cases, you might want to reuse a DSEE server certificate for the new OUD instance, so that the migration is transparent for SSL clients. Note that this might require installation of the OUD instance on the same box as the DSEE depending on SSL certificate options used.

If you want to have your OUD instance reuse the SSL servert certificate,  perform the following steps

1. export the DSEE server certificate to a PKCS12 file (e.g dsee.p12) as described in the ODSEE admin guide
    The exact procedure may depend on the DSEE release. On DSEE 6.x, DSEE 7.x and ODSEE, run the command below:

    dsadm export-cert -o dsee.p12  <instance_path> defaultCert

Note: By default, the alias of the DSEE server cert is defaultCert. Use the appropriate alias in case you choosed to use another value.

2. copy the PKCS12 file to <OUD_INSTANCE>/config

3. create a pin file containing the pkcs12 file password e.g. in the <OUD_INSTANCE>/config directory

At that stage, the DSEE server certificate can be imported in the OUD instance in 2 different ways:
- either configure a PKCS12 OUD keystore pointing to the file exported from DSEE
- import the DSEE certificate to the default JKS OUD keystore

To configure a OUD PKCS12 keystore, perform the following steps:

4.1 Configure the PKCS12 keystore

dsconfig set-key-manager-provider-prop \
         --provider-name PKCS12 \
         --set key-store-file:config/dsee.p12 \
         --set key-store-pin-file:config/ \
         --set enabled:true \

4.2 Configure the LDAPS connection handler to use the pkcs#12 keystore

dsconfig set-connection-handler-prop \
         --handler-name LDAPS\ Connection\ Handler \
         --set key-manager-provider:PKCS12 \

To import the DSEE certificate key pair to the existing OUD JKS keystore, perform the following steps:

5.1 Locate the JAVA_HOME of the jvm used by OUD

    The version of the JVM used is displayed at startup in the OUD error log

5.2 Run the following command to import the DSEE certificate

JAVA_HOME/bin/keytool -v -importkeystore -srckeystore <Path to PKCS12 cert file exported from DSEE>  -srcstoretype PKCS12 -destkeystore <OUD_INSTANCE_DIR>/OUD/config/keystore  -deststoretype JKS

    When prompted, specify the JKS pin (available in <OUD_INSTANCE_DIR>/OUD/config/  and the PKCS12 pin you used to export the DSEE server cert

5.3 Check import

    To list the content of the OUD JKS keystore, use the following:

    JAVA_HOME/bin/keytool -list -keystore <OUD_INSTANCE_DIR>/OUD/config/keystore

Enter keystore password:

Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries

defaultcert, Aug 29, 2013, PrivateKeyEntry,
Certificate fingerprint (MD5): 10:63:DC:B5:6B:C8:F3:A0:6B:A7:23:9E:0B:EA:9C:30

server-cert, Aug 29, 2013, PrivateKeyEntry,
Certificate fingerprint (MD5): BE:C9:F3:8A:49:98:96:15:EF:AC:B4:08:6F:76:FB:05

By default, the DSEE server cert alias is defaultcert.
By default, the OUD server cert alias is server-cert.
By default, OUD let java  automatically choose the best server-cert amongst those present in the keystore. If you want to force the use of  one certificate, do the following:

dsconfig set-connection-handler-prop \
         --handler-name LDAPS\ Connection\ Handler \
         --set ssl-cert-nickname:defaultcert \


Tuesday Aug 27, 2013

OUD&EUS Take 2: DB Accounts Proxy-ed by OUD into existing Directories

This post is the second one of a serie focusing on Enterprise User Security (EUS) and Oracle Unified DIrectory (OUD).

Enterprise User Security (EUS), an Oracle Database Enterprise Edition feature, leverages the Oracle Directory Services and gives you the ability to centrally manage database users and role memberships in an LDAP directory. EUS reduces administration costs and increases security.

DB Accounts Proxy-ed by OUD into existing Directories

Most enterprises already have existing corporate directories in place, and prefer the EUS implementation. An EUS implementation leverages the existing directory infrastructure and user information base without putting in place synchronization between directories. In this way, OUD acts as a real-time interpreter for Oracle database information requests to user data.

Using OUD enables the database to interact with third-party directories. OUD leverages existing user and group information in the existing third-party directory infrastructure by forwarding LDAP requests and responses back and forth to the third-party directory holding user data. User data, database meta-data such as DB registration information, user/role Mappings, and other EUS specific meta-data are stored locally in OUD, without requiring any schema changes to store EUS configuration in the existing third-party directory.

As of release 11gR2PS1, OUD is certified with EUS to support Active Directory, Oracle Directory Server Enterprise Edition, and Novell eDirectory. Working with these products, OUD eliminates user data duplication and synchronization and consequently lowers total cost of ownership (TCO).

1. Centralizing Accounts into Microsoft Active Directory

You can integrate Active Directory for password-based authentication or integrate Active Directory with Kerberos authentication.

Active Directory Integration for Password-based authentication

Such a scenario requires deployment of an additional component: the OUD Password Change Notification plug-in (oidpwdcn.dll). Microsoft uses a proprietary implementation to hash passwords in Active Directory that is incompatible with the Oracle DB requirements. The OUD Password Change Notification plug-in is notified when a password change occurs, and stores hashes in Active Directory. The oidpwdcn dll must be installed on every Active Directory domain controller.

Active Directory Schema extension is required to store the hashed passwords.

The database establishes a connection to OUD. OUD retrieves user data (users and groups) from Active Directory. User passwords are retrieved from the hashed password stored by the OUD Password Change Notification plug-in. EUS metadata are stored and retrieved from OUD.

The database version must be 10.1 or later as earlier versions use a different and incompatible password format.

Figure 2: EUS Account management with Active Directory

Active Directory Integration with Kerberos Authentication

In this scenario, Kerberos is used for DB authentication. EUS with DB Kerberos authentication does not require any changes to the database beyond standard EUS configuration. The database establishes a connection to OUD. OUD looks up the requested DB information in Active Directory. All database clients must be Kerberos-enabled to use this option. This capability is only supported with DB version 10.1 or higher.

The database establishes a connection to OUD. OUD retrieves user data (users and groups) from Active Directory. EUS metadata are stored and retrieved from OUD. Access to the hashed user password is not required, so no schema extensions and no Password Change Notification dll have to be deployed on Active Directory.


Figure 3: EUS Account management with Kerberos and Active Directory

2. Centralizing Accounts into ODSEE

The database establishes a connection to OUD. OUD retrieves user data (users and groups) from Oracle Directory Server Enterprise Edition (ODSEE) . EUS metadata are stored and retrieved from OUD.

This integration does not require any changes in the database (beyond what is usually required for EUS, nor for database clients that use username/password authentication.


Figure 4: EUS Account management with DSEE

3. Centralizing Accounts into Novell eDirectory

The database establishes a connection to OUD. OUD retrieves user data (users and groups) from Novell eDirectory. EUS metadata are retrieved from OUD.

This integration does not require any changes in the database beyond what is usually required for EUS, nor for database clients that use username/password authentication.

Using Novell eDirectory doesn’t require an Oracle password filter. You have to enable Universal Password in eDirectory, and allow the administrator to retrieve the user password. Refer to Novell's eDirectory documentation on Password Management for more information.

This configuration can only be used with DB versions 10.1 or higher due to incompatible password formats in earlier DB versions.


Figure 5: EUS Account management with DSEE


Wednesday Sep 12, 2012

Fuzzing for Security

Yesterday, I attended an internal workshop about ethical hacking. Hacking skills like fuzzing can be used to quantitatively assess and measure security threats in software.  Fuzzing is a software testing technique used to discover coding errors and security loopholes in software, operating systems or networks by injecting massive amounts of random data, called fuzz, to the system in an attempt to make it crash. If the program contains a vulnerability that can leads to an exception, crash or server error (in the case of web apps), it can be determined that a vulnerability has been discovered.

A fuzzer is a program that generates and injects random (and in general faulty) input to an application. Its main purpose is to make things easier and automated.

There are typically two methods for producing fuzz data that is sent to a target, Generation or Mutation. Generational fuzzers are capable of building the data being sent based on a data model provided by the fuzzer creator. Sometimes this is simple and dumb as sending random bytes, swapping bytes or much smarter by knowing good values and combining them in interesting ways.

Mutation on the other hand starts out with a known good "template" which is then modified. However, nothing that is not present in the "template" or "seed" will be produced.

Generally fuzzers are good at finding buffer overflow, DoS, SQL Injection, Format String bugs etc. They do a poor job at finding vulnerabilites related to information disclosure, encryption flaws and any other vulnerability that does not cause the program to crash.  Fuzzing is simple and offers a high benefit-to-cost ratio but does not replace other proven testing techniques.

What is your computer doing over the week-end ?

I am Sylvain Duloutre, I work as a Software Architect in the Oracle Directory Integration Team, the customer-facing part of Directory Services & Identity Management Product Development, working on Technical Field Enablement.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« March 2015