Wednesday Oct 22, 2014

OUD and Referral Management with AD

Oracle Unified Directory(OUD) can be configured as a proxy to Active Directory (AD).
For instance, it is possible to define a Remote LDAP Extension in OUD pointging to Root Catalog of AD 2008.

Searches to AD would return referrals, so the appropriate OUD Network group can to be modified to  follow referrals automatically with the command below:

/dsconfig -h localhost -p 4444 -D "cn=directory manager" -j ~/.pwd  -X -n set-network-group-qos-policy-prop --group-name network-group --policy-type referral --set referral-policy:follow

In some cases, a ldapsearch with a basedn which is not local to the root catalog still returns referrals to another AD Server. 
OUD reports the following error: 

SEARCH operation failed
Result Code:  1 (Operations Error)
Additional Information:  Unable to process the operation because a referral leading to an unknown or disabled ldap-server was received

This error is specific to AD because AD builds referrals as follow: ldap://,DC=example,DC=com. does not systematically correspond to a LDAP host declared in the OUD proxy configuration. For security reasons, OUD follows referrals to hosts explicitely declared as LDAP server extensions in the OUD proxy configuration.

To make sure OUD is able to chase referrals, define a new ldap-server-extension with remote-ldap-server-address property set to and remote-ldap-server-port set to 389. In this case, creation of a proxy workflow element is not required for this ldap-server-extension. More on ldap-server extensions at

Thursday Oct 02, 2014

Using OUD Transformations to expose Operational attributes as Regular ones

Some (badly written) LDAP client applications expect to get operational attributes along with regular attributes when they search the directory w/o specifying attributes explicitely. The LDAP standards specify that operation attributes have to be explicitely requested in the search request. Alternatively, the special character + can be used to retrieve all the operational attributes w/o specifying explictely one by one.

OUD adheres to the LDAP standard, so operational attributes must be explicitely specified in a search request.
A specific option to facilitate migration from other directories can be used to expose schema related attributes (objectclasses, attributeTypes) as regular attributes. This option is described in one of my posts at

However, others operational attributes are not exposed. Don't worry, OUD transformations framework can help you to solve this specific integration problem:

Say you have an client application that expects the (operational)  pwdChangedTime attribute to be returned systematically as a user attribute.

First, setup a OUD proxy. The client application in question will point to that proxy, but others applications will not be subject to the (non-standard) directory server behaviour.

Then create a Add Outbound Transformation as below:

dsconfig create-transformation \
          --set client-attribute:pwdChangedTime=%pwdChangedTime% \
          --type add-outbound-attribute \
          --transformation-name Mymap \ 

Then put that transformation to a transformation workflow element:

dsconfig create-workflow-element \
          --set enabled:true \
          --set next-workflow-element:userRoot\
          --set transformation:myMap \
          --type transformations \
          --element-name myTransfo \ 

Insert your transformation workflow element to the appropriate workflow:

dsconfig set-workflow-prop \
          --workflow-name workflow1 \
  --set workflow-element:myTransfo \ 

Update the OUD Proxy schema, so that the pwdChangedTime is no longer declared as Operational. All you need to do is remove the  Usage DirectoryOperation and the NO-USER-MODICATION flag. Either modify the schema via LDAP or use the procedure below:

stop the OUD proxy
copy default schema
cp <OUD_HOME>/config/schema/01-pwpolicy.ldif <OUD_PROXY_INSTANCE>/OUD/config/schema
edit <OUD_PROXY_INSTANCE>/OUD/config/schema and change the pwdChangedTime definition as below:

 attributeTypes: ( NAME 'pwdChangedTime'
  DESC 'The time the password was last changed' EQUALITY generalizedTimeMatch
  ORDERING generalizedTimeOrderingMatch SYNTAX
  X-ORIGIN 'draft-behera-ldap-password-policy' )

restart the OUD proxy

At that stage, pwdChangedTime will be returned by a LDAP search with attribute list set to * or empty. 

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


Tuesday May 05, 2009

etime granularity in access logs

Unlike DS, DPS 6.3 etimes in the access log are in millisecs.

For sake of performance, DPS uses a timeThread that gets the time regularly (every 500ms only in DPS 6.3)  instead of performing a system call each time the current time is needed so etimes shown in access logs may be biased to a large extend and show 0ms when the effective etime is < 500ms. Conversaly , etimes may show a value of 500ms when the effective time is smaller.

TimeThread -----T1-----T2-----T3-----T4----T5    with (Ti- T()i-1)) = 500ms
DPS time retrieval example 1 |   |   => real value = 5ms, computed value is T2-T2 = 0
DPS time retrieval example 2    |       |   => real value = 15ms, computed value is T3-T2 = 500ms

The time "granularity" can be changed to accommodate with your needs in DPS 7.0 (available soon) but you can get a fix earlier (RFE 6601029) by contacting the Sun support team.

Tuesday Feb 17, 2009

DSEE 6.3.1 has been released

Sun Directory Services Enterprise Edition (DSEE) 6.3.1 has been released.
Release notes and download informations are available at

Wednesday Jan 21, 2009

DPS 6.3 properties that require server restart

The list of  DPS 63 config changes that require a restart is part of Admin guide.  Chapter 18: Directory Proxy Server Instances / Configuring Directory Proxy Server Instances /  Configuration Changes Requiring Server Restart

This list will be greatly reduced in the next release (7.0) 

Friday Dec 19, 2008

DIT changes with dn virtual transformations

Here is a summary of a common deployment scenario with Sun Directory Proxy Server:

LDAP entries are grouped by location in the DIT, e.g user entries are located under ou=north,ou=people,dc=company, dc=com or  ou=south,ou=people,dc=company, dc=com or ou=east,ou=people,dc=company, dc=com or ou=west,ou=people,dc=company, dc=com based on user physical location.

Later, for sake of simplicity, the DIT is flatten so that every user entry is stored immediatly under ou=people, dc=company, dc=com

New applications are aware of the DIT structure change but DPS is used so that legacy applications expecting the location container node can operate w/o problem.

The dn mapping needed can be achieved by using virtual data transformations as described  in

Let's assume that
- you have a data view DV1 with viewBase (suffix) set to dc=company,dc=com.
- entry location (north, east,...) is always available in each entry in attribute 'location'
- entry uid=\*,ou=(north|south|east|west),ou=people,dc=company,dc=com mapped to uid=\*,ou=people,dc=company,dc=com

You have to create a virtual data transformation on the 'dn' for data view DV1. For inbound traffic (requests), the proxy must get rid of the ou=(north|south|east|west) node. For outbound traffic (responses), the proxy gerenates a (fake) ou=(north|south|east|west)  from the content of the 'location' attribute of each entry.

Here is the dpconf command to do that:

dpconf add-virtual-transformation -h <host> -p <port> -d <proxy manager> DV1 mapping attr-value-mapping dn internal-value:uid=\\${uid},ou=people view-value:uid=\\${uid},ou=\\${location},ou=people

Note: you might have to escape some characters (e.g $) in the command below depending on the command interpreter you are using. In the example above, I used \\$ instead of plain $.
Note2: dn patterns used in virtual transformations must not contain the data view viewBase (dc=company,dc=com in this case) as it is implicit.

Wednesday Sep 10, 2008

RootDSE entry management with DPS 6.x

By default, the rootDSE entry is managed/returned by the directory proxy itself and reflect proxy LDAP capabilities. Such behaviour is mandatory whenever virtualization is in use so that underlying data layout is hidden from the client applications.

In some specific cases, it might be interesting to configure DPS to fetch the rootDSE entry from the directory server(s) itself. Here is the procedure:
1- Create a data view (rootDSE) with view base set to "" and associate a data source pool containing the directory servers holding the rootDSE entry to be returned.
2- Change the DPS routing policy to manual.
3- Make sure the rootDSE exclusion base property do not contain "". If so, remove that value.

At that point, requests to rootDSE are redirected to the rootDSE data view.

Notice: If multiple directory servers are associated with the rootDSE data view, make sure they have identical rootDSE entries otherwise the rootDSE entry returned to clients may vary over time because of the load-balancing policy. This is likely to confuse client applications. There might be also a mismatch between rootDSE content and proxy capabilities (e.g supported extended operations or supported LDAP controls), so make sure to change the proxy configuration (e.g list of forwarded controls) to reflect the rootDSE entry content.

Friday Jul 25, 2008

Virtual Directory Use Case: Entry aggregation from 2 sources

Let's keep track of the common virtual directory configuration below people ask me every week or so:

Use case description:
  • User entries stored in a LDAP directory server, e.g uid=sylvain, ou=people,
  • Additional user attributes stored in Active Directory. Corresponding entry is cn=sylvain, cn=users,dc=sun, dc=com
  • user credentials identical on both sides (same password)
  • Aggregated entries containing the merge of LDAP and AD available as uid=sylvain, ou=people,

Sun Directory Proxy configuration:
  • Create a LDAP data view, LDAP1, viewBase set to ou=people,, pointing to the LDAP data source
  • Create a LDAP data view, LDAP2, viewBase set to ou=people,, dataSourceBase set to cn=users,dc=sun,dc=com, pointing to the AD server
  • Create a Join data view, JOIN, viewBase set to ou=people,, primary view set to LDAP1, secondary data view set to LDAP2
  • Make sure to mark LDAP1 and LDAP2 as non 'routable' so that the join data view providing aggregated view only can be exposed to the proxy clients. Otherwise, a search to ou=people, may be routed to the 3 data views, leading to duplicate entries to be returned.

With the configuration above, the proxy automatically rewrites DNs when appropriate. However the proxy would bind as uid=sylvain,cn=users,dc=sun,dc=com when it needs to contact the AD source. The naming attribute is wrong, so a dn transformation needs to be configured on the LDAP2 data view to map dns like uid=\*,ou=people, to cn=\*, ou=people, Mapping of the static portion of the dn is done automatically.

To create the dn transformation, use

dpconf add-virtual-transformation JOIN mapping attr-value-mapping dn view-value:uid=${uid} internal-value:cn={$uid}
(quotes may be needed depending on the command interpreter you are using)

For more details, refer to the proxy documentation.

Monday Apr 14, 2008

Sun Directory Masters Event 2008

The Sun Directory Masters Event 2008 took place in the Sun Grenoble Engineering Center on April 3-4, 2008. The goal of the Directory Masters Event is to promote the sharing of knowledge and best practices, bring together a well known global technical community, enabling sales and deployments of the Sun Java System Directory Server Enterprise Edition 6.x product.

The Directory Masters event targets three specific audiences with one unified theme of designing, implementing and managing Directory Services solutions. All target audiences were drawn from Sun and partner personnel (sales, service, and pro services).

I gave 2 presentations, one covering Sun Directory Proxy Server 6.x and a second one, more technical, on Virtual Directory capabilities of the product along with some "real" virtual use cases!


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.


« February 2015