Thursday Apr 17, 2014

Provisoning to OUD using the OIM connector for OUD

OIM provides an extensive list of connectors, including a connector to Oracle Unified Directory (OUD). OIM Connector for OUD is described at

The Lookup.LDAP.UM.ProvAttrMap lookup definition maps process form fields with OUD target system attributes. This lookup definition is used for performing user provisioning operations.

For the default user fields that you can specify or modify values during provisioning operations , see Section, "User Fields for Provisioning an OUD Target System."

For example, the Process Form Field "Common Name" is mapped on cn on the OUD side.

Some specific Process Form Fields are mapped differently. For instance the "Login Disabled" Process Form Field is mapped to the __ENABLED__ keyword in the default mapping file. __ENABLED__ does not directly correspond to any OUD attribute. It is a keyword that is associated with an effective OUD attribute in the OUD Connector configuration, as described in The OUD attribute used to store account state is specified  by the enabledAttribute. By default, it is set to ds-pwp-account-disabled.

The same indirection mechanism apply to the NsuniqueID and Password Process Form Fields mapped to __UID__ and __PASSWORD__ that are provisionned to the OUD attributes defined by uidAttribute and passwordAttribute (entryUUID and userPassword by default).

Tuesday Apr 15, 2014

An additional log file for OUD: server.out

The server.out file stored in <OUD_Instance>/OUD/logs may contain useful pieces of information logged very early in the OUD bootstrap process, e.g. before the logging subsystem is initialized.

This file is overriden at each restart.

The start-ds output is sent to standard output as well.  You are welcome to re-direct that output to
any log that you like overwriting the existing one or appending if you prefer.  For instance, you can redirect logs like these into their own date and time specific output file so that you can  examine each start and stop output independently.

Tuesday Apr 08, 2014

OUD External change log and rootDSE search

Some LDAP client applications perform subtree searches with search base set to the rootDSE (empty DN).
Oracle Unified Directory (OUD) nicely routes the search to every top level suffix automatically.

When the replication is enabled, OUD automatically publicizes all changes that have occurred in a directory server database in the cn=changelog suffix. This is particularly useful for synchronizing the LDAP directory with other subsystems.  The cn=changelog suffix may contains millions of changes depending on the modification rate on the replication topology and the change retention policy (purge delay).

Subtree searches with search base set to the rootDSE are routed to the cn=changelog suffix as well as long as the replication is enabled. In general, this is not a problem in testing/stagging area, because the changelog is almost empty. However, in production, this may have big impact on performances as this suffix may contain many entries. Furthermore, custom  indexes corresponding to client access pattern do not exist on that suffix, so they can't be used to speed up entry processing.

In order to address that problem, you can disable the so-called external changelog, without disabling the underlying replication changelog used by the replication. To do so, run the following command on the OUD servers for each user suffixes:

dsconfig -h <hostname> -p <admin port>  -D "cn=directory manager" -w <admin password> -n \
  set-external-changelog-domain-prop \
  --provider-name "Multimaster Synchronization" --domain-name <your suffix>  \
  --set enabled:false

Note: some provisoning apps may require the external changelog to synchronize with external systems. If so, keep the external changelog enabled on a couple of OUD servers and reserve them for these apps.

Monday Mar 24, 2014

Deploying the IAM Suite and OUD with the Deployment Wizard

Identity & Access Management suite R2 PS2 ( ships with a new deployment tool to automate the installation and configuration of products related to the IAM suite. This tool is named Oracle Identity and Access Management Deployment Wizard.

This tools automates the installation, configuration and integration of WebLogic Server, SOA Suite, Oracle Identity Manager, Oracle Access Management, Oracle Unified Directory, Oracle HTTP Server and Webgates. The tool allows you to select one of three deployment topologies: OIM, OAM or OIM integrated with OAM and OUD.

More details about this wizard on at

Friday Feb 28, 2014

Oracle Unified Directory (OUD) Forum on OTN

Friendly reminder, feel free to post OUD-related questions on the OUD Forum available at

Tuesday Feb 18, 2014

Lessons from the Field: A directory transition from DSEE to OUD 11gR2PS1

I was recently involved in a LDAP directory services transition project, from DSEE to OUD 11gR2PS1, for a large manufacturing enterprise. Directory service is medium-sized with a few of million LDAP entries, and is accessed by a wide range of services and applications, ranging from Corporate Directory to Identity Store for Identity Management and user management for intranet and extranet portals.

Here is an overview of the steps we followed and the issues we addressed during this project to successfully transition the infrastructure to OUD.

1. Transition Assessment

Putting in place a sound methodology and design is a key success factor for a directory migration, regardless the final migration options selected.
This assessment was conducted over a period of 3 weeks and included the following:

- Identification and formalization of the main drivers and requirements for transition
- Inventory of the current directory infrastructure, including identification of the application portfolio accessing the directory
- Identification of transition options compatible with requirements
- Estimation of transition effort
- Identification of training requirement for the staff and skills required during the transition, especially people with business knowledge of the data stored in the directory.

For this project, the 4 main drivers to migrate to OUD were:

    - native support of EUS (ability to store Oracle DB accounts used by Enterprise User Security) as deployment of EUS was a Corporate decision
    - smooth integration and official support of OUD with the Oracle Identity stack, especially OIM and OAM
    - superior scalability, able to deliver SLA required by new services to be rolled out in the coming years
    - support for global account lockout

About 10,000 applications word-wide access the directory. Among them, 10 were identified as critical for the transition, mostly provisioning applications.

Figure 1: Existing DSEE topology with 4 masters, 6 read-only replicas in each DC + 2 read-only replicas in remote branches

OUD provides several options to transition from DSEE. For this project, the DSEE and OUD topologies have to cohabit for 6 months in production as transition was planned incrementally on a geo basis. Furthermore, client applications heavily relies on password policy, so strong data consistency is required across the 2 topologies during transition. Based on that, tightly-coupled cohabitation via the replication gateway was selected. In addition to that, this strategy provides smooth and incremental transition without interruption of service.

Transition analysis and design was conducted over a period of 1 week. The goal of this critical phase was to adapt schema, configuration and data to OUD, define and automate procedures to deploy an OUD directory server able to deliver a service equivalent to existing DSEE servers in staging area. Business knowledge of directory data was really important during this phase. Transition of the replication topology was also addressed during this phase.

4 OUD servers have been deployed as a directory backbone. Actual roll-out of other OUD servers (20+ servers all over the world) will be performed incrementally over the next months.

2. Transition Analysis and Design

Transition analysis and design heavily relied on the transitioning tools provided with OUD. Transitioning to OUD implies adapting ODSEE configuration (and sometimes the data) to the OUD format.
The OUD delivery provides tools to automatically adapt ODSEE configuration and data. The few configuration elements that can't be adapted automatically are identified by the OUD diagnostic tools and require manual adaptation.

The work was broken down into the following steps:

  1. - Diagnose the DSEE deployment
  2. - Migrate the schema, configuration and data to a reference OUD instance
  3. - Validate configuration and settings
  4. - Deploy additional OUD instances in a replicated topology
  5. - Upgrade 2 DSEE masters in place to ODSEE 11gR1 PS2
  6. - Deploy Replication Gateway to make the link between the 2 topologies
  7. - Use T2P procedure (Test to Production) to roll out server configuration  in production


2.1 Diagnosing the DSEE deployment

OUD ships with the ds2oud tool able to diagnose DSEE configuration, schema and existing user data. You can use this tool to identify areas that are likely to require special attention during the transition.
Many of the differences spotted by this tool can be automatically migrated, especially those related to schema and server configuration. Others issues, related to advanced server configuration and user data requires manual intervention as they often require business knowledge or architectural decisions.

In order to run this tool, you must have administrative access to one running DSEE instance. For sake of security, one additional DSEE master server was deployed specifically for that purpose so that production systems are not impacted at all by this diagnostic phase.

2.2 Migrating the schema, configuration and data to a reference OUD instance

LDAP Schema
LDAP schemas were compared first. Custom schema extensions were properly imported to the OUD side. However, we faced a couple of issues with some experimental schemas, e.g. RFC 2307: OUD ships with the latest versions of the RFCs, but in this case, DSEE was using an older and incompatible version of the schema. A huge amount of existing LDAP entries were relying on the older schema, so we decided to use this old schema on OUD too.

Server Configuration
We also used ds2oud to migrate the server configuration. The -F option is used to produce a batch file containing a list of configuration changes to be applied to the OUD directory server. This batch file was reused to setup subsequent OUD servers during server roll-out.

Global parameters, database suffixes, indexes, global password policy were migrated automatically.

Note: Support of global password policy and account lockout during cohabitation of DSEE and OUD via the replication gateway requires that DSEE use the 'DS6' password policy mode. For this deployment, the DSEE topology was already using this mode, so no additional action was required on that side.

User Data
For this project, most of the transition effort was related to user data migration: LDAP was deployed more than 15 years ago. LDAP entries were provisioned over time by a huge variety of applications. The number of provisioning applications is now quite limited. However, it appeared that about 5% of the LDAP entries did not strictly conform to the LDAP schema and/or to the LDAP standard.  By default, OUD strictly enforce the LDAP standard and the LDAP schema, including attribute value syntax check. DSEE does not check attribute value syntax.

Based on that, it was decided to use that transition project to conduct a detailed data assessment and sanitization. This assessment was completed over the 1 week period as originally planned. However, it required involvement of additional stakeholders to figure out whether entries that did not match the LDAP schema were correct or incorrect from a business and application perspective.

Here are a few road blocks hit and addressed:

- Most LDAP entries contained more than one structural LDAP object class
    This non-standard setting is accepted by ODSEE but by default, it is rejected by OUD. That check was relaxed on OUD because applications creating these entries could not be modified.
- Some entries contained attribute type extensions (e.g criteria:criteria;x-custom-extension) that violate LDAP standards because they contain underscores.
    That check was relaxed on OUD as well
- Some DNs and telephoneNumber attributes contain incorrect values
    These values were cleaned up on DSEE.

Directory Metadata
The transition strategy chosen is based on the replication protocol. It provides strong data consistency and all data including directory metadata are replicated back and forth between DSEE and OUD.
For that project, directory metadata, mainly access controls, could be replication w/o any problem, However, we had to adapt directory metadata related to account-based resource limits settings:

Some DSEE entries contain the following resource limit attributes, namely nsSizeLimit, nsTimeLimit, nsLookThroughLimit, nsIdleTimeout. Corresponding attributes on OUD are ds-rlim-size-limit, ds-rlim-time-limit, ds-rlim-lookthrough-limit,ds-rlim-idle-time-limit. In order to replicate the functionality correctly, the OUD schema was modified so that each DSEE attribute name related to resource limits is declared as an alias name for each corresponding OUD attribute.

2.3 Validating OUD Configuration and Settings

A few OUD servers were deployed in staging area and configured as defined above. Then traffic from key customer applications identified during the transition assessment was redirected to the OUD infrastructure.

This phase is very important to validate the changes above and identify behavioral differences between OUD and DSEE that are not always detected automatically. We detected a few problems that required additional configuration changes on the OUD side. These changes were added to the list of configuration to be applied to OUD servers.

Here are a few road blocks hit and how we addressed them:

- Few applications were performing unindexed operations. By default, OUD reject such searches.
     For technical reasons, it was not acceptable to create the appropriate indexes to suppress unindexed searches: For this project, we recommend to disable privileges leading to aci behavioral differences between OUD and ODSEE.
- Attributes present in the rootDSE and in the schema are flagged as operational, so they are not returned to client applications unless they are explicitly specified in the search attribute list. On ODSEE, these attributes are systematically returned.        
    Client applications relied on the DSEE behavior; we had to modify the OUD configuration so that rootDSE entries are returned like user attributes
- By default, in OUD, unauthenticated users are not granted access to cn=schema nor the rootDSE.
    Appropriate access controls was added to OUD

2.4 Deploy additional instances in a replicated topology

In such medium/large replication topology, it is advisable to separate the directory server and replication server instances into separate JVMs, and to limit the number of replication servers:

- 4 instances having both Directory server and Replication Server roles are deployed, 2 in each data center.
- The number of directory server instances serving search operations could be reduced to 4 due to superior OUD performances. 
- 2 replication groups are defined so that DSs in one data center preferably connect to a RS within the same data center.
- 2 directory servers deployed in remote branches are configured as read-only replicas to conform to corporate rules. These 2 servers can connect to replication server from either data center to receive updates.

Note: Unlike DSEE topology, every directory server running in the main data centers are read-write master. The corresponding servers in DSEE handled a limited write traffic that was redirected to DSEE masters via referrals. The new OUD topology eliminates the need for referrals.

Figure 2: New OUD topology with 4 RS+DS, 4 DS in each DC + 2 read-only DS in remote branches

3 Deploying the OUD topology

The main outcome of the transition analysis and design phase is a collection of commands to be applied to set up an OUD directory server instance.
Additional OUD directory server instances were setup then configured. The Test to Production feature provided by OUD is used to clone configurations to pre-production environment.

Data are exported from DSEE (with the --opends flag) to preserve replication metadata, so that replication can be established between the 2 environments. Data are imported in a single OUD directory server, then replication was enabled between servers and database files are copied to the other servers. In the customer environment, this initialization strategy was preferred over an over-the-network full initialization.

The minimum version required for tightly coupled coexistence is ODSEE 11g Release 1 (11.1.1) for the ODSEE master that communicates directly with the replication gateway. However, the rest of the ODSEE topology does not need to be uniformly based on this version and remain in 6.x, so we upgraded 2 DSEE masters to the latest ODSEE 11gR1 PS2 ( Instances were automatically upgraded in place without having to copy, export or import anything. An alternate solution would have been to deploy 2 new ODSEE 11g instances as replication gateway companion.

At that stage, 2 replication gateways are deployed as described in the OUD administration guide. This is the recommended setting to avoid single point of failure.

Backup strategy was adapted to reflect the new hybrid topology: In a replicated environment involving ODSEE and OUD, you must perform regular backups on the ODSEE side and on the OUD side. A backup must always be restored in the topology it is associated with.

Figure 3: Cohabitation DSEE/OUD

The current plan is to keep the DSEE-OUD cohabitation for 6 months as applications are progressively redirected to OUD.

4 Conclusion

Tightly coupled coexistence of OUD with ODSEE is achieved by deploying OUD and ODSEE in a replicated topology using the “Replication Gateway”. The replication gateway provides out-of-the-box live transition without service interruption.
This enables you to run OUD and DSEE in parallel in a mixed environment so that you can transition to OUD over time, validate your upgrade strategy application by application, and most importantly, without downtime.

Migration tools shipped with OUD addresses most of the transitioning issues. However, data cleaning and/or manual adaptation is sometimes required during this process, so some time should be allocated to address that during the transition analysis and design.

Tuesday Feb 04, 2014

Binding a server to privileged port on Linux w/o running as root

This is applicable to any service using privileged ports (< 1024), for instance to run a HTTP server on port 80 or a LDAP directory server on port 389.

  • Running the server as root is not a recommended option for security reasons.
  • Using iptables to map privileged port (e.g. 389) to non-privileged port is a well-know method.
  • Updating the Linux config to put 389 on the non-privileged port list is another option.

There is another option that I use frequently, based on setcap to run OUD on port 389 in my labs:

This solution requires install and modification of a java 7 JVM specifically for OUD use.

Such configuration has security implications, as anyone running that JVM has the right to bind on privileged ports (settings are JVM wide, not restricted to a specific jar file/application), so the jvm access should be restricted to the appropriate user only (the one allowed to start OUD)

Here is the procedure:

  1. download patchelf sources from here and compile them on target Linux.
  2. install setcap package on Linux if needed
  3. install a java 7 SDK on target system e.g. /space/java/jdk1.7.0_45
  4. restrict access to that jvm (java and jre) to the appropriate user only (the one used to start OUD).
    Put in place additional security if needed.
  5. as root, run the following commands to allow java to bind as priviledged ports

    setcap cap_net_bind_service=+epi <JAVA_HOME>/bin/java
    setcap cap_net_bind_service=+epi <JAVA_HOME>/jre/bin/java

  6. - change java dynamic library loading strategy as default strategy is not compatible with setcap

    patchelf --set-rpath <JAVA_HOME>/jre/lib/amd64/jli <JAVA_HOME>/jre/bin/java
    patchelf --set-rpath <JAVA_HOME>/lib/amd64/jli <JAVA_HOME>/bin/java

  7. - Modify jvm used by oud

    edit and modify property e.g
    run dsjavaproperties

  8. - start OUD with standard start-ds command.

Monday Jan 27, 2014

OUD 11gR2PS2 ( available

Oracle Unified Directory 11gR2PS2 ( is available for download at Other IdM R2PS2 components are available at

Documentation for Oracle Unified Directory (OUD) 11gR2PS2 ( is available at

Certification matrix is available at

Wednesday Jan 22, 2014

Migrating DSEE database indexes to OUD

Many DSEE customers declare database indexes by writting directly to the DSEE server configuration. For instance, the following LDIF sniplet creates a presence & equality index for attribute employeeNumber in the userRoot database

dn: cn=employeenumber,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
objectClass: top
objectClass: nsIndex
cn: employeenumber
nsSystemIndex: false
nsIndexType: pres
nsIndexType: eq

It is not recommended to update the OUD configuration directly as this is not a public interface and internal configuration representation may be subject to change. It is recommended to use the dsconfig command line tool. Here is the command equivalent to the index creation above:

dsconfig -h localhost -p <admin port> -D "cn=directory manager" -j <password_file> -X -n \
  create-local-db-index \
  --backend-name userRoot \
  --index-name employeenumber\
  --set index-type:presence\
  --set index-type:equality

More about OUD index creation and management is available at  and

Monday Jan 20, 2014

Using OUD as a WebLogic Authentication Provider

Each WebLogic security realm must have at least one authentication provider configured. The default authentication provider (defaultAuthenticator) uses an embedded LDAP directory server to store user credentials & group membership.

Using an external authentication provider

The file-based embedded LDAP store does not scale when the number of users and group to manae grow. However, many customners favoir a centralized administration for users and groups, so you can declare an external authentication provider. The default authenticator is kept for "emergency" only to store Weblogic administrator in case the external authenticator cannot be reached as it is possible to control authenticator priority and criticality.

OUD as a Weblogic authentication provider

Such use case is certified since WebLogic 10.3.5; OUD can be used to store users and groups. Furthermore, it is possible to export existing users & groups from embedded LDAP to OUD for seamless transition.

When OUD is used an an external authentication provider, it is recommended to disable user lockout provided by WebLogic and rather rely on the password policy provided at the OUD level.

Configuring OUD as an authentication Provider

  1. In the Weblogic Console, go to Security Realms/ RealName/ Providers/ Authentication Page
  2. Click New to add a new Authentication Provider
  3. Enter a name for the provider and choose IplanetAuthenticator as the type
  4. Click OK
  5. In the Security Realms / RealName / Providers/ Authentication page, click the name of the provider you created, and select the Configuration / Provider Specific page
  6. Configure connection attributes for OUD and search bases as appropriate
  7. Update the field labeled GUID Attribute at the bottom of the page to value entryuuid
  8. Click Save

Reusing existing users & groups from embedded LDAP

To export users and groups from embedded LDAP:

First, modify credentials of the embedded LDAP server: Click <Domain> under Domain Structure on the left panel. On the right panel, click Security tab then Embedded LDAP tab, change credentials, Save and restart WebLogic

Then, perform a LDAP search on the Weblogic port as cn=admin using above credentials e.g.

ldapsearch -p 7001 -D "cn=admin" -w <password> -b "ou=myrealm,dc=<domain>" "(|(objectclass=wlsUser)(objectclass=groupOfURLs)(objectclass=groupOfUniqueNames))

Here is an exemple of entries:

dn: cn=Administrators,ou=groups,ou=myrealm,dc=dom memberURL:ldap:///ou=groups,ou=myrealm,dc=dom??sub?(&(objectclass=per son)(wlsMemberOf=cn=Administrators,ou=groups,ou=myrealm,dc=dom))
: groupOfURLs cn: Administrators

dn: uid=weblogic,ou=people,ou=myrealm,dc=dom
: inetOrgPerson
: organizationalPerson
: person
: wlsUser
: weblogic
: {ssha}5ZFkp4qHIzfrGe8AV3naJOndwzTXC2W/
wlsMemberOf: cn=Administrators,ou=groups,ou=myrealm,dc=dom

By default, user entries are stored in oud=people while groups are stored in ou=groups in the embedded LDAP server. As you can see, the search base in the LDAP URL defining dynamic groups (e.g. Administrators) is incorrect as it searches user entries in the group container. This must be changed prior to importing entries in OUD to the following value:

memberURL:ldap:///ou=people,ou=myrealm,dc=dom??sub?(&(objectclass=per son)(wlsMemberOf=cn=Administrators,ou=groups,ou=myrealm,dc=dom))

To import entries in OUD,

  1. extend OUD schema with wlsUser objectclass and wlsmemberOf attribute
    attributeTypes: ( NAME ('wlsMemberOf') SYNTAX`.1466. X-ORIGIN 'WLS')
    objectclasses: ( NAME 'wlsUser' SUP top MAY (wlsMemberOf) X-ORIGIN 'WLS')
  2. Create suffix holding oud=<myreal>,dc=<domain>
  3. Allow pre-encoded password import in OUD
    dsconfig set-password-policy-prop --policy-name Default\ Password\ Policy --set allow-pre-encoded-passwords:true
  4. Allow multiple structural objectclasses per entry in OUD
    dsconfig set-global-configuration-prop --set single-structural-objectclass-behavior:accept
  5. Import entries in OUD using dsimport

Optimizing Group membership evaluation

Weblogic can determine group membership based on a configurable attribute present in user entries. If not set in the provider specific configuration (User Dynamic Group DN property), it determines membership by evaluating the URLs present in the dynamic group.

This property can be set to isMemberOf as this attribute is provided OOTB by OUD. It can also be set to wlsMemberOf when every dynamic group used is based on this attribute.

Tuesday Jan 14, 2014

Transition from DSEE to OUD: Top 5 tips

The ds2oud tool can be used to migrate DSEE configuration to OUD. However, a few additional OUD configuration changes might be required on a case by case basis to provide seamless transition for applications.

Here are the top 5 differences spotted during real transition projects and how to address them:

#1 Syntax checking

DSEE does not check attribute value syntax. OUD does, so attribute values must conform to the attribute syntax defined in the schema. For instance, an attribute with Boolean syntax can hold TRUE or FALSE values only. Ideally, data should be fixed by the customer. However, this is not always possible and takes time. Furthermore, somne client application may rely on the incorrect data.

To disable attribute value syntac checking on OUD, the invalid-attribute-syntax-behavior property in the global configuration  can be changed to 'warn' or accept

#2 Structural objectclasses

Every user entry must have exactly one STRUCTURAL object-class to conform to Directory Standards. If a ODSEE entry has 0 or more than one structural object-class, the entry would be rejected during an import. ODSEE does not differentiate between the two object-class types, so this kind of schema inconsistency is commonly found in real deployments. It is recommended that you fix such user entries on the ODSEE side before transitioning to OUD.

Alternatively, you can disable this schema checking  as described in

# Schema and root DSE access

The root DSE entry (empty DN) and the schema entry (cn=schema) contains several operational attributes. DSEE systematically returns these attributes even when the client application does not list them explilcitely in the search attribute list. This does not conform to the LDAP standard. By default OUD does not return them. However, it is possible to configure OUD to behave like DSEE using the procedure described in

#4 Unindexed searches

By default, OUD does not allow unindexed searches as they may impact overall directory services performances. DSEE does.
It is recommended to limit the number of unindexed searches by creating additional indexes. However, unindex searches are valid patterns in some specific situations.
It is possible to grant unindexed search privilege on a per user account basis as described in

#5 Anonymous access

By default, DSEE accepts requests with DN and no passsword. Such requests are processed as anonymous.
By default, OUD rejects such requests. This behaviour can be changed by setting the property bind-with-dn-requires-password to false in the global OUD configuration

Don't forget to have a look at the additional OUD KM notes available on OTN . They can be accessed as described in

Monday Jan 13, 2014

How to Subscribe My Oracle Support(MOS)'s "Hot Topics" via E-Mail for OUD and DSEE topics. (Doc ID 1391461.1)

Users can add a subscription which will email a digest of newly published KM articles, service request updates and bugs to particular categories or products. Subscriptions are unique to users' selected Knowledge User Template, which is set in users' profile. 

To subscribe to the Hot Topics, follow the instructions below:

  1. Go to My Oracle Support(MOS)
  2. Select "Settings" under tab "More..." located on top middle side.
  3. Select "Hot Topics E-Mail" from 'Settings' menu available on left side.
  4. You will be presented with new screen(see below image).  Make appropriate selections regarding frequency, format, and other item as per your preference. Be sure to tick the "On" button for "Turn Hot Topics E-mail".
  5. Click "Add" button under "Include Specific Products" section.
  6. A new pop-up comes up.  Enter "Oracle Directory" in "Product" pull-down menu and select "Oracle Directory Server Enterprise Edition".
  7. Tick the boxes for the types of notifications you'd like to receive. (Knowledge Articles, Alerts, Bugs, select Bug levels- for example, All Bugs, etc.)
  8. Click button "OK" if you are done or "Apply" button if you want to add another product.
  9. Enter "Oracle Unified" in "Product" pull-down menu and select "Oracle Unified Directory", tick interested 'Include' list and click button "OK".
  10. Click button "Save" once done.  Note that these settings can be updated at any time by following above steps.

Wednesday Dec 18, 2013

Using OUD with Oracle Directory Integration Platform (DIP)

This post will guide you through configuring OUD as a DIP backend instead of OID.
Such deployment is supported since DIP  (PS6).

1- Install OUD and configure 1 suffix to be synchronized, e.g. dc=example,dc=com

ADMIN="cn=Directory Manager"
echo $PASSWD > "$PW_FILE"
oud-setup --cli --hostName "$HOST" --ldapPort $PORT --ldapsPort $SPORT --adminConnectorPort 4444 --rootUserDN "$ADMIN" --rootUserPasswordFile "$PW_FILE" --generateSelfSignedCertificate --enableStartTLS --baseDN dc=example,dc=com --addBaseEntry --ldifFile /home/sylvain/lib/ldif/Example.ldif --no-prompt --noPropertiesFile 

2- Configure a suffix holding DIP configuration

DIP stores its configuration in cn=Products,cn=oracleContext.
You can create and initialize a local backend holding this suffix with the commands below:

dsconfig create-workflow-element --set base-dn:cn=Products,cn=oraclecontext --set enabled:true --type db-local-backend --element-name myNewDb --hostname $HOST --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll --no-prompt
dsconfig create-workflow  --set base-dn:cn=Products,cn=oraclecontext  --set enabled:true  --set workflow-element:myNewDb  --type generic  --workflow-name workFlowForMyNewDb  --hostname "$HOST"  --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll  --no-prompt

dsconfig set-network-group-prop  --group-name network-group --add workflow:workFlowForMyNewDb --hostname $HOST --port $APORT --bindDN "$ADMIN" --bindPasswordFile "$PW_FILE" --trustAll --no-prompt

then create top entry:

ldapmodify -a -p $PORT -h $HOST -D "$ADMIN" -w "$PASSWD" <<EOF
dn: cn=Products,cn=oraclecontext
objectClass: top
objectClass: container


3- Enable changelogs

DIP stores its configuration in cn=Products,cn=oracleContext.OUD uses OUD changelogs for both data anc configuration to detect changes efficiently.

dsreplication enable-changelog --no-prompt --baseDN "dc=example,dc=com" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll

dsreplication enable-changelog --no-prompt --baseDN "cn=Products,cn=oraclecontext" --hostname "$HOST" --port $APORT --bindDN "$ADMIN" --adminPasswordFile "$PW_FILE" --trustAll


4- Grant access to synchronized data

ldapmodify -h localhost -p 1389 -D "$ADMIN" -w "$PASSWD" <<EOF
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///dc=example,dc=com")(version 3.0; acl "Entry-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; )
add: aci
aci: (targetattr="*")(version 3.0; acl "Attribute-level DIP permissions"; allow (all,proxy) groupdn="ldap:///cn=dipadmingrp,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext"; allow (all,proxy) groupdn="ldap:///cn=odipigroup,cn=DIPadmins,cn=Directory Integration Platform,cn=Products,cn=oraclecontext";)


Note: Make sure to enable LDAPS port (LDAP over SSL) if you plan to synchronize userPassword with DIP as this is required for obvious security reasons.


5 - Install DIP

The procedure is described in Make sure to Install DIP only (do not run the Configure procedure as it is OID specific)

Wednesday Dec 04, 2013

Using OUD as an OIF Federation Store

Schema extensions and specific index settings are required to use OUD as an OIF Federation Store.
These files are currently not part of the OIF delivery, so here are the files:

First, import the userFedSchemaOUD.ldif schema
Then update OUD configuration (mostly OIF-specific index creation) with the command below:
${ORACLE_HOME}/OUD/bin/dsconfig <conn params> -n -X -F userFedIndexOUD.commands

(configuration commands assume default OUD database settings. Change db name if needed in the command batch file)

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


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.


« April 2014