Tuesday Jan 14, 2014

Transition from DSEE to OUD: Top 5 tips

The ds2oud tool can be used to migrate DSEE configuration to OUD. However, a few additional OUD configuration changes might be required on a case by case basis to provide seamless transition for applications.

Here are the top 5 differences spotted during real transition projects and how to address them:

#1 Syntax checking

DSEE does not check attribute value syntax. OUD does, so attribute values must conform to the attribute syntax defined in the schema. For instance, an attribute with Boolean syntax can hold TRUE or FALSE values only. Ideally, data should be fixed by the customer. However, this is not always possible and takes time. Furthermore, somne client application may rely on the incorrect data.

To disable attribute value syntac checking on OUD, the invalid-attribute-syntax-behavior property in the global configuration  can be changed to 'warn' or accept

#2 Structural objectclasses

Every user entry must have exactly one STRUCTURAL object-class to conform to Directory Standards. If a ODSEE entry has 0 or more than one structural object-class, the entry would be rejected during an import. ODSEE does not differentiate between the two object-class types, so this kind of schema inconsistency is commonly found in real deployments. It is recommended that you fix such user entries on the ODSEE side before transitioning to OUD.

Alternatively, you can disable this schema checking  as described in https://blogs.oracle.com/sduloutr/entry/cohabitation_odsee_oud_schema_checking

# Schema and root DSE access

The root DSE entry (empty DN) and the schema entry (cn=schema) contains several operational attributes. DSEE systematically returns these attributes even when the client application does not list them explilcitely in the search attribute list. This does not conform to the LDAP standard. By default OUD does not return them. However, it is possible to configure OUD to behave like DSEE using the procedure described in https://blogs.oracle.com/sduloutr/entry/oracle_unified_directory_root_dse

#4 Unindexed searches

By default, OUD does not allow unindexed searches as they may impact overall directory services performances. DSEE does.
It is recommended to limit the number of unindexed searches by creating additional indexes. However, unindex searches are valid patterns in some specific situations.
It is possible to grant unindexed search privilege on a per user account basis as described in https://blogs.oracle.com/sduloutr/entry/cohabitation_migration_odsee_oud_privileges

#5 Anonymous access

By default, DSEE accepts requests with DN and no passsword. Such requests are processed as anonymous.
By default, OUD rejects such requests. This behaviour can be changed by setting the property bind-with-dn-requires-password to false in the global OUD configuration

Don't forget to have a look at the additional OUD KM notes available on OTN . They can be accessed as described in https://blogs.oracle.com/sduloutr/entry/how_to_subscribe_my_oracle

Wednesday Dec 04, 2013

Using OUD as an OIF Federation Store

Schema extensions and specific index settings are required to use OUD as an OIF Federation Store.
These files are currently not part of the OIF delivery, so here are the files:

First, import the userFedSchemaOUD.ldif schema
Then update OUD configuration (mostly OIF-specific index creation) with the command below:
${ORACLE_HOME}/OUD/bin/dsconfig <conn params> -n -X -F userFedIndexOUD.commands

(configuration commands assume default OUD database settings. Change db name if needed in the command batch file)

Wednesday May 02, 2012

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

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


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