Data Adaptation again

By Sylvain Duloutre on Oct 06, 2014

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.

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 usercn=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:

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

The list of OUD privileges is available here.

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: ( 1.3.6.1.4.1.26027.1.1.244 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.

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

Oracle Unified Directory Root DSE entry and schema

The root DSE entry (empty dn) is often used by LDAP client applications to discover directory services capabilities.  For instance, attribute namingContexts gives indications about the suffixes managed by the directoy server instance. All these attributes are flagged as OPERATIONAL, so, they should not be returned to client applications unless they are explicitely specified in the search attribute list.

OUD strictly adheres to LDAP standards so these attributes are not returned by default. In Oracle Directory Server Entreprise Edition (ODSEE), these attributes are treated as standard ones and are systematically returned to client applications. Applications depending on the ODSEE behaviour might be impacted as many of them do no specify any search attribute list. To make OUD behave like ODSEE with regards to the access of rootDSEE attributes, run the following command:

dsconfig set-root-dse-backend-prop –set show-all-attributes:true

To make OUD treat schema operational attribute like user attributes, run the following too:

dsconfig set-workflow-element-prop –element-name schema –set show-all-attributes:true

Optimized Solution for Oracle Unified Directory

Oracle Optimized Solution for Oracle Unified Directory is a complete solution – Software and Hardware engineered to work together.

It implements Oracle Unified Directory software on Oracle’s SPARC T4 servers to provide highly available and extremely high performance directory services for the entire enterprise infrastructure and applications. The solution is architected, optimized, and tested to deliver simplicity, performance, security, and savings in enterprise environments.

More details available at http://www.oracle.com/us/solutions/1571310

Installing Oracle Unified Directory in silent mode

By default, the OUD installer runs in GUI mode. Alternatively, it is possible to install and setup OUD in silent mode.

First, download the OUD bits, then run the installer in silent mode. Last but not least setup/configure OUD in silent mode as well.

To run the installer in silent mode, either run it in GUI mode on your laptop or any system with a GUI and record your answers so that you can replya them on another system in silent mode. Alternatively, you can build a response file manually for OUD.

To record your answers, run the installer with the option -record, e.g

./runInstaller -record -destinationFile /tmp/OUD.rsp

To the installer with an existing response file (silent mode)

./runInstaller -silent -responseFile /tmp/OUD.rsp

A response file template is available at the end of this post. You need to change values for ORACLE_HOME and MIDDLEWARE_HOME.

After this install, you can setup oud in cli mode (oud-setup), either interactive or in batch.

oud-setup –cli –no-prompt -D “cn=directory manager” -j $PASS_FILE -p $PORT1 –adminConnectorPort $APORT1 –noPropertiesFile
More info available at http://docs.oracle.com/cd/E22289_01/html/821-1274/ds-cli-setup.html#scrolltoc

Oracle Unified Directory 11G announced.

Oracle Unified Directory (aka OUD) is an all-in-one directory solution with storage, proxy, synchronization and virtualization capabilities.

The product can be downloaded from http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

The OUD documentation is live on OTN, at this URL. http://download.oracle.com/docs/cd/E22289_01

For more info, have a look at the official press release.