Wednesday Dec 16, 2015

Using OUD plugin for SAML authentication with OAM against users stored in SQLServer

Here is a practical example about how to use a custom OUD plugin to speed up deployment of an Identity Management solution for a fraction of the price compared to developing a custom connector:

The use-case is to enable SAML authentication as an IDP where some of the users are stored in a SQLServer database and some in AD (external users in DB, internal users in AD).

The customer is planning to have OAM authenticate the users and perform the role of a SAML IDP doing LDAP authentication for users stored in the database and Kerberos for the users stored in AD. In order to allow OAM to authenticate users that are stored in the database, OUD can be deployed as a RDBMS proxy thanks to the RDBMS workflow element feature, so that users stored in a database table are exposed as a LDAP tree that OAM will authenticate against.

Problem is with the password field in the database that is hashed in a specific way.  

The trick is to deploy a custom OUD plugin component ahead of the RDBMS workflow element. That plugin is responsible for processing bind requests only. Upon reception of a bind request against a user stored in SQLServer, the custon plugin retrieves the user entry containing hashed password and salt, accesses the plain text password provided in the bind request, and performs the password comparison based on custom logic. 

Design, dev and testing took me a couple of days, much simpler and cost effective than adding support for this new source in OAM/OIM.


Tuesday Dec 15, 2015

Oracle E-Business Suite certified with Unified Directory

Oracle Unified Directory 11gR2 Patchset 3 ( is now certified for use with Oracle E-Business Suite Release 12.2.

Oracle Unified Directory 11gR2 Patchset 3 ( (along with Directory Integration Platform 11gR1 Patchset 7 ( can be integrated with Oracle Access Manager 11gR2 Patchset 3 ( as a single sign-on solution. For availability and other information on Oracle Unified Directory, refer to the articles listed in the documentation section below.

  • My Oracle Support Knowledge Document 2003483.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Unified Directory 11gR2 
  • My Oracle Support Knowledge Document 1576425.1 - Integrating Oracle E-Business Suite Release 12.2 with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate
  • My oracle Support Knowledge Document 1388152.1 - Overview of Single Sign-On Integration Options for Oracle E-Business Suite
  • Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management 11g Release 2 (11.1.2) (E27301-04)
  • Oracle Fusion Middleware Installation Guide for Oracle Unified Directory 11g Release 2 (11.1.2) (E23737-02)
  • Oracle Fusion Middleware Installing Oracle Unified Directory 11g Release 2 (11.1.2) (E56132-02)
  • Oracle Fusion Middleware Installation Guide for Oracle Identity Management 11g Release 1 ( (E12002-13)
  • Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory 11g Release 2 (11.1.2) (E22648-02)
  • Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform (E56469-01)
  • Oracle Fusion Middleware Patching Guide 11g Release 1 ( (E16793-28)
  • Thursday Sep 10, 2015

    Migration from OID to OUD: Adapting EUS metadata

    Enterprise User Security is an important component of Oracle Database Enterprise Edition. It enables you to address administrative and security challenges for a large number of enterprise database users by centralizing users and roles in a LDAP directory.

    It is possible to use either Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) as LDAP repository for EUS.

    To migrate from OID to OUD, 
    - enable EUS support in OUD
    - copy your user and groups in <your_context)
    - copy across EUS metadata (in cn=oracleContext,<your suffix)

    EUS metadata as stored in OID must be slighly adapted before being impoorted to OUD otherwise the DB won't be able to authenticate against OUD and will raise the following error:

    ORA-28043: invalid bind credentials for DB-OID connection

    Migrating the DB entry from OID to OUD requires some specific steps for SASL/DIGEST-MD5 authentication. In OID, the password hash used for SASL/DIGEST-MD5 authentication is stored in authpassword;oid, with the {SASL/MD5} prefix.
    In OUD, this must be stored in orclcommonrpwdattribute with the {SASL-MD5} prefix.

    For instance:

    In OID:
    ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(cn=orcl11g)" authpassword
    dn: cn=orcl11g,cn=oraclecontext,dc=example,dc=com
    authpassword;oid: {SASL/MD5}ola+G+GFsSeiu6QcRiAh9g==
    authpassword;oid: {SASL/MD5-DN}3UeqmU5Axd+XVAM9Lxf28g==
    authpassword;oid: {SASL/MD5-U}BD6uyBcSiFbGtlPzq6TtUA==

    In OUD:
    ldapsearch [conn details] -b cn=oraclecontext,dc=example,dc=com -s one "(objectclass=orcldbserver)" orclcommonrpwdattribute
    dn: cn=orcl11g,cn=OracleContext,dc=example,dc=com
    orclcommonrpwdattribute: {SASL-MD5}ola+G+GFsSeiu6QcRiAh9g==

    Monday Jul 20, 2015

    OUD Directory Server vs Replication Server: Who Cares ?

    Oracle Unified Directory replication model relies on 2 logical components, Directory Servers and Replication Servers. Directory Servers contain user data, pushes changes to replication changed and get updates from replication servers. Replication Server stores replication changes, they receive changes to directory servers and forward them to the rest of the topology.

    By default, you don't need to care about Replication Servers. Replication Servers and internal components managed automatically: a Replication Server is autimatically configured in each OUD DIrectory Server process when replication is configured.

    OUD Replication Server and Directory Servers are NOT equivalent to DSEE Suppliers and Consumers. By default, every replicated OUD is a Read-Write Supplier/Master.

    When do you need to know about replication servers? - Primarily, when full network connectivity cannot be guarantied across every instance as every Replication Server must be able to communicate to each other. - Optionally, Replication Servers and DIrectory Servers can be separated to optimize resource usage in large OUD topologies (10's of instances) - To enable external changelog service on a standalone OUD instance (for instance in a test environment) as a Replication Server is required is such case.


    Tuesday May 19, 2015

    Oracle Unified Directory 11gR2 PS3 available for download

    The Identity Management 11gR2 PS3 release, including OUD 11gR2 PS3 is available on eDelivery.  
    To download OUD, go to
    and select OUD 11gR2 PS3 

    R2PS3 documentation is available at

    Certification Matrix is available at

    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

    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;

    Monday Oct 06, 2014

    Data Adaptation again

    Yet another common usage of OUD Transformations to transparently adapt some values during provisioning:

    In this real use case, ODIP (Oracle Directory Integration Platform) is used to synchronize some SQL tables with OUD.
    The country every user is living in is stored in an Oracle DB and is synchronized by DIP into the LDAP country attribute.
    Unfortunatelly, the country name format expected by the applications on the Directory side differ from the one used on the DB side.

    In this case, country name is stored in full in the DB (e.g. USA, FRANCE, ITALY) when apps that contact OUD expect standard country short form e.g. US, FR, IT.  For administrative and political reasons within the enterprise, it is not possible to create a additional mapping table in the RDBMS that could be used by a SQL JOIN to return the correct values.

    OUD Tranformation Framework can be used to address that integration problem: a so-called add inbound tranformation is invoked when a new entry is created and value mapping is applied on the incoming add request before it is processed by the OUD database engine. For sake of peformance, this transformation can be configured to trigger on udates originated from DIP only, using the network group mechanism.

    To create a transformation that maps USA to US and France to FR, do the following:

    First create the transformation with the appropriate mappings:

    dsconfig create-transformation \
    --set source-attribute:country=%country%(US,USA)(FR,France)(IT,Italy) \
    --type add-inbound-attribute \
    --transformation-name mapCountry \
    --set conflict-behavior:virtual-overrides-real 

    Then stash this transformation to a Transformation Workflow element to be inserted ahead of local DB (userRoot):

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

    Then put the Transformation Workflow Element to the appropriate workflow so  that it can be invoked:

    dsconfig set-workflow-prop \
              --workflow-name userRoot1 \
              --set workflow-element:mapCountry

     At that stage, appropriate values are automatically stored in OUD.

    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. 

    Wednesday May 02, 2012

    Cohabitation/Migration ODSEE->OUD: privileges

    OUD provides a privilege subsystem, which can be used to define capabilities that will be granted to users. The privilege subsystem works in conjunction with the access control implementation in the process of determining whether a user will be allowed to perform a certain operation.

    In general, default OUD access control settings are stricter than ODSEE. Appropriate privileges must be added to achieve behavior that is equivalent to that of ODSEE. For instance, by default, OUD ACIs don’t allow users to reset another users’s password. Alternatively, it is possible to disable the privilege subsystem.

    By default, normal users are not granted any of the privileges listed above. Therefore, if a user should be allowed to perform any of the associated operations, they must be granted the appropriate privileges. This can be done by adding the ds-privilege-name operational attribute to the user's entry. ds-privilege-name is a multivalued attribute, and if a user is to be given multiple privileges, then a separate value should be used for each one. When the virtual attribute subsystem is in place, it should also be possible to grant privileges to groups of users automatically by making ds-privilege-name a virtual attribute in those user entries.

    As an example, the following modification can be used to add the proxied-auth privilege to the user cn=Proxy User,dc=example,dc=com:

    dn: cn=Proxy User,dc=example,dc=com
    changetype: modify
    add: ds-privilege-name
    ds-privilege-name: proxied-auth

    Granting privileges explictely to users may not be the optimal solution when OUD and ODSEE cohabit in a replication topology as the OUD-specific ds-privilege-name would be replicated by to ODSEE, so privileges can also be assign implicitely to a set of user based on group membership for example, using the notion of virtual attribute. I'll cover Virtual attribute in a subsequent post.

    Alternatively, It is possible to disable those privileges leading to aci behavioral differences between OUD and ODSEE. For instance, the  unindexed-search privilege can be disabled  so that users can perform un-indexed searches. A privilege (unindex search checking in the example below) can be disabled using the following command:

    set-global-configuration-prop  --add \
    disabled-privilege: unindexed-search -n

    The list of OUD privileges is available here.

    Cohabitation/Migration ODSEE->OUD: schema checking

    By default, OUD schema scheck is stricter than ODSEE.  Schema checking is key for data sanity, however this might cause some trouble when "incorrect" data have to be imported into OUD or when incorrect data are replicated from ODSEE.

    Generally speaking, it is not recommanded to disable schema checking and the data should be fixed whenever possible before import and on the ODSEE side when ODSEE and OU cohabit in the same replication topology. In some cases, this is not possible, so some specific checks can be disabled to accomodate with common inconsistency:

    Structural object class unicity

    Per LDAP standard, every LDAP entry must contain exactly one structural object class.  In many deployments, some LDAP entries contain 0 or more than 1 objectclass and several LDAP server implementations do not enforce this. By default OUD does. Such check can be relaxed w/o know adverse effect by using the command below:

    dsconfig set-global-configuration-prop --set \
    single-structural-objectclass-behavior:accept -n

    Attribute type names containing invalid characters

    A few customers defined their own attribute types, using forbidden characters, e.g undercores, or leading digit in attribute names and/or in attribute type extensions (e.g 4you;x_bad_extension). Such check can be relaxed using the command below:

    dsconfig set-global-configuration-prop --set \
    allow-attribute-name-exceptions:true -n

     Zero-length attribute value

    Zero-length attribute values (that is, an empty string) is technically not allowed by the revised LDAPv3 specification, but some environments may require it for backward compatibility with servers that do allow it. Empty string can be explicitely allowed on a per LDAP syntax basis, using the example below for DirectoryString syntax:

    dsconfig set-attribute-syntax-prop --syntax-name Directory\ String \
    --set allow-zero-length-values:true -n

    Monday Apr 30, 2012

    Cohabitation/Migration ODSEE->OUD: dn-based search resource limits

    Oracle Unified Directory 11g Release 1 (11.1.1) provides a mechanism to replicate data between Oracle Directory Server Enterprise Edition and Oracle Unified Directory. Depending on the ODSEE features used, the OUD configuration may need to be adapted to provide the same service transparently to client application.

    Both ODSEE and OUD provide ways to control ressources used by a directory user. The following limits are provided by OUD at the global configuration level:

    • ds-cfg-size-limit specifies the maximum number of entries that can be returned to the client during a single search operation.
    • ds-cfg-time-limit specifies the maximum length of time that should be spent processing a single search operation
    • ds-cfg-lookthrough-limit specifies the maximum number of entries that the Directory Server should "look through" in the course of processing a search request. This includes any entry that the server must examine in the course of processing the request, regardless of whether it actually matches the search criteria.
    • ds-cfg-idle-time-limit specifies the maximum length of time that a client connection may remain established since its last completed operation

    The corresponding configuration attributes in ODSEE are search-size-limit, search-time-limit, look-through-limit, idle-timeout.  Such configuration mapping is automatically provided by tools like ds2oud.

    Server limits for search operations can also be controlled using special operational attribute values assoaicted with the user binding to the directory. These attributes are stored as part of the directory data, so they are replicated between ODSEE and OUD.  Attribute names (and sometimes values) vary so the OUD configuration need to be extended to deal with that:

    DSEE entries may contain the following resource limit attributes: 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 (02-config.ldif) must be modified so that each DSEE attribute name related to resource limits is declared as an alias name for each corresponding OUD attribute. An alias can be declared in an attributeType declaration as below:

    attributeTypes: ( NAME ( 'ds-pwp-password-policy-dn' 'alias-for-ds-pwp-password-policy-dn')

    On DSEE, -1 is used to disable a resource limit. On OUD, 0 is used. One way to address this difference is to create a virtual attribute on OUD to override the content of the OUD attribute when the value of the DSEE attribute is equals to -1. A virtual attribute must be created for the 4 attributes mentioned, as described below:

    dsconfig create-virtual-attribute --name "mapping nsSizeLimit "
    --type user-defined --set attribute-type:ds-rlim-size-limit \
    --set filter:”(nsSizeLimit=-1)” \
    --set conflict-behavior:virtual-overrides-real \
    --set value:"0"
    --set enabled:true
    dsconfig create-virtual-attribute --name "mapping nsTimeLimit " 
    --type user-defined --set attribute-type:ds-rlim-time-limit \
    --set filter:”(nsTimeLimit=-1)”\
    --set conflict-behavior:virtual-overrides-real \
    --set value:"0"
    --set enabled:true
    dsconfig create-virtual-attribute
    --name "mapping nsLookthroughLimit" 
    --type user-defined 
    --set attribute-type:ds-rlim-lookthrough-limit 
    --set filter:”(nsLookthroughLimit=-1)”
    --set conflict-behavior:virtual-overrides-real
    --set value:"0"
    --set enabled:true
    dsconfig create-virtual-attribute --name "mapping nsIdleTimeout " \
    --type user-defined --set attribute-type:ds-rlim-idle-time-limit \
    --set filter:”(nsIdleTimeout=-1)”\
    --set conflict-behavior:virtual-overrides-real \
    --set value:"0"
    --set enabled:true

    More information about account-based resource limits is available here.


    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.

    A mirror of this blog is available on Wordpress here.


    « February 2016