Oracle Unified Directory supports some degree of virtualization and Oracle is planning to eventually retire OVD. As of this post, OUD 11.1.2.2 supports directory virtualization, but not databases or flat files (without the use of heavy custom plugin development).

In this post, we are going to walk through configuring OUD to join AD; we want to see an OUD user’s profile which also has all of that same user’s attributes from AD.

Our starting point will be as follows for the two directories:

OUD Instance

Directory Server OUD instance.

Base DN: dc=acme,dc=com
Admin: dc=Directory Manager
Host: oud.test.com:1389

AD Instance

Domain: ADFOREST
Base DN: dc=adforest,dc=demo
Admin: administrator@ADFOREST
Host: ad.test.com:389

As you can see, we have one user, “Alex Stanciu” that has an account in both directories. We want to create a view that shows both of these sources combined.

Create OUD Proxy Server Instance

In order to accomplish this, we’ll need to create an OUD Proxy Server instance, so go ahead and set one up by running

$ORACLE_HOME/oud-setup-proxy

Use the defaults in the screen except on the Configuration Options. Select “Configure Later” so we get a blank proxy instance with nothing pre-configured:

Since I already have an OUD instance with my dc=acme,dc=com directory, this will be a second instance, so it will put it in $MW_HOME/asinst_2 and the ports will be 2389 and 5444, for the directory and admin respectively.

Once this instance is up and running, connect to it using ODSM (available on your adminserver: http://host:7001/odsm). Open the Configurations tab and make sure to click the Core Configurations button (Last on the right of Naming Contexts):

A lot of the configurations will need to change (Workflows and Workflow Elements are in this section).

Conceptual Overview

I want to take a moment to explain what we’re going to do, so you’re not just following steps.

In OUD, when a connection comes in, it’s handled by a configured Network Group, the default being “network-group”. Inside the Network Group, you can specify a Workflow, and inside a Workflow, you can select Workflow Elements. Workflow Elements then use or reference other objects, for example Server Extensions, which we’ll use.

In our use case here, we’re going to use these objects (this order is also their hierarchy):

Extensions We’ll create two LDAP Server Extensions, each one simply holds the server hostname and port with some other performance tuning options. 

Object Description
Network Group This this the main entry point. We’ll use the default ‘network-group’.  and choose a Workflow that we’ll have to create
Workflow We’ll create a workflow that that uses one or more Workflow Elements which we’ll create
Workflow Element: Proxy LDAP This is the proxy object that will read data from a source directory and pass it back to the client, through the workflow. . Here we specify things like the BaseDN, but the host name of your source directory needs to be referenced as a Server Extension
Workflow Element: Join This element will join together our LDAP Proxy elements and this is the Workflow Element we’ll be using in the Workflow entry. Unfortunately, this element cannot be created in the ODSM UI; we’ll have to do it via the command line. Once created, though, it will show up in the object tree in the Configuration tab.

We’ll have to start creating these objects at the bottom of the hierarchy, working our way up.

LDAP Server Extension

  • Create a new LDAP Server Extension:

  • Specify OUD hostname and port and whatever else your environment needs

  • Repeat for the AD Connection
  • Proxy LDAP

  • Now we’ll create the Proxy LDAP Workflow Elements
  • Enter the properties for OUD first
  • Repeat for AD
  • Workflow & Workflow Elements

    Before we attempt to join these two Proxy LDAP workflow elements together, we should verify that they work and are setup properly. We’ll create 2 Workflows and add them to the default network-group:

  • Create a new Workflow:
  • Enter the info for OUD
  • Repeat for AD
  • Edit the default ‘network-group’
  • Add the two Workflows we just created
  • Go over to your Data Browser and you should see both directories listed as two separate roots
  • If you get an “Unprocessed Continuation Reference(s)” error, please see this post on how to resolve!

    Creating the Join

    Now that we know our back end connections are working, we just need to join them. We do this by creating one Join Workflow Element and two participants. Unfortunately, ODSM does not support the creating/modification of these types of elements in its GUI, so we need to go to the command line. Go into your Proxy’s instance/OUD/bin directory; since I have both the Directory Server and the Proxy on the same box, my path is $MW_HOME/asinst_2/OUD/bin

  • Create the Join Workflow Element. I named mine “Join-WE” and chose “dc=joined,dc=com” as my new BaseDN of the two directories joined. Please make sure to read the two sub-bullet points before committing the change:
    ./dsconfig create-workflow-element --set enabled:true --set join-suffix:dc=joined,dc=com --type join --element-name Join-WE
  • When you run the command, it will take you to this confirmation screen:
    We need to change the dn-attribute property, remove the existing values and add “uid”, “cn” and “samaccountname”
  • Here’s what mine looks like after the change:
  • [/li_item]
  • Create the first, primary Join Participant. Note the references to the existing LDAP Proxy Workflow Element:
    ./dsconfig create-join-participant --element-name Join-WE --set participant-dn:dc=acme,dc=com --set participating-workflow-element:OUD-ProxyWE --set primary-participant:true --type generic --participant-name jp-oud
  • Create the second Join Participant. In this step, we also specify the join criteria: I want to join on OUD’s uid attribute an AD’s sAMAccountName:
    ./dsconfig create-join-participant --element-name Join-WE --set participant-dn:dc=adforest,dc=demo --set participating-workflow-element:AD-ProxyWE --set primary-participant:false --type generic --participant-name jp-ad --set participants-join-rule:jp-oud.uid=jp-ad.samaccountname
  • Update the Network Group

    Now that we have all our pieces in place, we need to do two things. Create a Workflow that uses the Join Workflow Element we just created and add this Workflow to our Network Group.

  • Create a new Workflow using these options
  • Edit the ‘network-group’ to use our “JoinWF” Workflow

Finished

That’s it! If you browse to your directory connecting to the virtual Base DN, “dc=joined,dc=com”, you should see your OUD tree and users who have matching uids/samaccountnames will have all their Active Directory attributes as well. As you can see in my screenshot below, the user has AD attributes like sAMAccountName, distinguishedName, userPrincipalName, etc…

And for reference, here’s the same user in OUD without the proxy:

Next Steps

What we’ve done so far is great if you just need to browse for data and get aggregated attributes. If you need to authenticate users, however, further work is involved in configuring how bind operations will function. I will outline that process in my next post. The link to that will be here when it’s up.