Tuesday Jan 15, 2013

Migration Stategy to Oracle Unified Directory

Developing a good strategy is a key element of a migration from third-party directories to OUD.
For sake of simplification, migration can be broken down in 5 steps as described below:

User Data Migration

Most companies defined some custom LDAP attributes and object classes. They use them  in conjunction with standard LDAP schema. LDAP provides a standard way to define schema extensions, so migration of user data is in general quite straight-forward:  Custom schema extensions need to be added to the OUD configuration, user data are exported from the existing directory to the standard LDIF format then re-imported into OUD. 

By default, OUD schema checking is strict, some user entries may be rejected when they do not strictly adhere with the LDAP schema. In such case, either fix the data, fix the schema or relax the corresponding schema option in OUD configuration.

Migration of passwords may cause problems if they are encrypted with non-standard algorithms. I plan to cover that in a separate post soon.

Directory Metadata Migration

Most directories, including OUD, store meta data along with the User Data. This may  include access control information (aci), collective attributes, ldap sub entries etc. Each directory vendor uses its own model, so this aspect of the migration requires attention  and must be carefully planned.

Directory Configuration Migration

Each directory has its own configuration model, so the configuration must be ported to OUD. It includes the LDAP ports the directory listen on, the LDAP naming contexts exposed, database indexes, replication settings, security settings, performance setting, etc. This can be done using OUD graphical interface (ODSM) or using command line dsconfig. This is in general quite simple to migrate the directory configuration to OUD. Special care is needed to manage migration of SSL server certificates if certificate renewal is not an option.

Dealing with hard-wired dependencies in client applications

Some LDAP client application have hard-wired dependencies on a directory vendor and/or version. For instance, an application would query the directory service version string and would take some decision based on that. Some applications may also create/update directory-specific metadata. It is quite difficult to identify such issues upfront, but it is usually good policy to classify client applications based on their LDAP traffic patterns: traffic of provisioning applications should be review first, as the probabilities to have dependencies on vendor-specific interface is higher than for application doing simple authentication.

Oracle Virtual Directory (OVD), part of the  Oracle Directory Services Plus can be used to emulate directory-specific features.

Switching from existing directory to OUD

From an operational perspective, it is key to define how the actual switch to OUD will occur: Some customers would favor export and import w/o maintaining the 2 environments in sync. This seems very simple, but this methodology cannot ensure an highly-available deployment with up-to-date entries on both sides. When this is not acceptable, synchronization tools like DIP (Directory Integration Platform) which is a part of Oracle Directory Services Plus can be used to synchronize user data.

Additional options exist to migrate from Oracle Directory Enterprise Edition (DSEE) to OUD as described here.






Monday Nov 12, 2012

Enabling EUS support in OUD 11gR2 using command line interface

Enterprise User Security (EUS) allows Oracle Database to use users & roles stored in LDAP for authentication and authorization.
Since the 11gR2 release, OUD natively supports EUS. EUS can be easily configured during OUD setup. ODSM (the graphical admin console) can also be used to enable EUS for a new suffix.

However, enabling EUS for a new suffix using command line interface is currently not documented, so here is the procedure:

Let's assume that EUS support was enabled during initial setup.
Let's o=example be the new suffix I want to use to store Enterprise users. The following sequence of command must be applied for each new suffix:

// Create a local database holding EUS context info
dsconfig create-workflow-element --set base-dn:cn=OracleContext,o=example --set enabled:true --type db-local-backend --element-name exampleContext -n
// Add a workflow element in the call path to generate on the fly attributes required by EUS
dsconfig create-workflow-element --set enabled:true --type eus-context --element-name eusContext --set next-workflow-element:exampleContext -n
// Add the context to a workflow for routing
dsconfig create-workflow --set base-dn:cn=OracleContext,o=example --set enabled:true --set workflow-element:eusContext --workflow-name exampleContext_workflow -n
//Add the new workflow to the appropriate network group
dsconfig set-network-group-prop --group-name network-group --add workflow:exampleContext_workflow -n

// Create the local database for o=example
dsconfig create-workflow-element --set base-dn:o=example --set enabled:true --type db-local-backend --element-name example -n

// Create a workflow element in the call path to the user data to generate on the fly attributes expected by EUS
dsconfig create-workflow-element --set enabled:true --set eus-realm:o=example --set next-workflow-element:example --type eus --element-name eusWfe
// Add the db to a workflow for routing
dsconfig create-workflow --set base-dn:o=example --set enabled:true --set workflow-element:eusWfe --workflow-name example_workflow -n
//Add the new workflow to the appropriate network group
dsconfig set-network-group-prop --group-name network-group --add workflow:example_workflow -n 

// Add the appropriate acis for EUS
dsconfig set-access-control-handler-prop \
          --add global-aci:'(target="ldap:///o=example")(targetattr="authpassword")(version 3.0; acl "EUS reads authpassword"; allow (read,search,compare) userdn="ldap:///??sub?(&(objectclass=orclservice)(objectclass=orcldbserver))";)'
dsconfig set-access-control-handler-prop \
      --add global-aci:'(target="ldap:///o=example")(targetattr="orclaccountstatusevent")(version 3.0; acl "EUS writes orclaccountstatusenabled"; allow (write) userdn="ldap:///??sub?(&(objectclass=orclservice)(objectclass=orcldbserver))";)'

Last but not least you must adapt the content of the ${OUD}/config/EUS/eusData.ldif  file with your suffix value then inport it into OUD.


Tuesday Aug 07, 2012

OUD 11gR2 documentation available on OTN

Following the annoucement of  the R2 release, the Oracle Identity Management 11g R2 (11.1.2) is now available on OTN here.

Documentation for Oracle Unified Directory (OUD) 11gR2 (11.1.2) is available here.

Certification matrix is available at  http://www.oracle.com/technetwork/middleware/id-mgmt/identity-accessmgmt-11gr2certmatrix-1714221.xls

Saturday Jun 09, 2012

New convenient Information Center about OUD in My Oracle Support

A new "Information Center" dedicated to Oracle Unified Directory is available from the Oracle Support Site. This page provides you with all the useful links and news related to the product, including technical articles, docs, licensing info and the latest patches available. To access it, log into MOS (My Oracle Support) at http://support.oracle.com,  search for 1418884.2 doc id in the search field on the front page, then click on the "Information Center : Overview Oracle Unified Directory (OUD)" link.

Friday Jun 08, 2012

OUD 11gR1 Certification Matrix

For those of you who needs the Oracle Unified Directory Certification Matrix and have hard times to find it, here is THE link:  Certification Matrix

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

Thursday Apr 19, 2012

Optimized Solution for Oracle Unified Directory

Oracle Optimized Solution for Oracle Unified Directory is a complete solution - Software and Harware 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

Wednesday Feb 08, 2012

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


Tuesday Jun 07, 2011

ODSEE 11.1.1.5.0 released

Oracle Directory Server Enterprise Edition 11gR1 PS1(11.1.1.5.0) aka 7.1 using old Sun versioning is available for download at http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

The corresponding doc set is available at http://download.oracle.com/docs/cd/E20295_01/index.htm

For questions, please use the OTN dedicated forum at http://forums.oracle.com/forums/forum.jspa?forumID=877&start=0

Wednesday Jan 19, 2011

ODSEE directory documentation moved

All the Directory documentation moved from docs.sun.com to Oracle Technology Network documentation
over the weekend.  Here is the new link.


Monday Jan 26, 2009

Forum about LDAP, Sun Directory, Proxy Server and Virtual Directory

If you have some questions about Sun Directory Server Edition, Directory Proxy and Virtual Directory or you want to share best practices, don't hesitate to use the Sun Developer Forum dedicated to these products.

See you there!

Friday Jan 23, 2009

Fail-over based on the directory server operational state

DPS 6.x load-balancing / fail-over can be configured to stop sending traffic to a specific directory server instance in maintenance, even when that instance is up and running. For instance, you may want to remove a directory server instance from the mesh while an import or re index is in progress.

DPS 6.x periodically checks each ds server for availability by issuing (amongst others) a search request. A directory server instance is considered unreachable when that search fails or does not return any entry. By default, the search request hits the rootDSE entry. It can be configured to hit an entry in cn=config or cn=monitor to take into account the directory server operation state.

For more info, look at dpconf properties monitoring-search-filter and monitoring-entry-dn in the ldap data source object.

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 http://docs.sun.com/app/docs/doc/820-2763/gbong?l=en&a=view

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 http://docs.sun.com/app/docs/doc/820-2765/virtual_transformations?a=view

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.
About


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.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
9
10
11
12
13
14
16
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today