Good ol' Oblix schema alive and well in OAM11g

While preparing to install OAM 11g, some of us were curious whether all the "ob..." attributes would remain intact or if they would be renamed with, for instance, an "orcl..." prefix. It struck one of my colleagues that the "ob" attributes would survive, if only to facilitate a workable upgrade path or to ease product development.

Whatever the case, it turns out that the attributes we've all known since the days of NetPoint and COREid have endured and can be found in OAM 11g after all.

During the LDAP pre-configuration step - one of the many, many steps required to get OAM installed - an LDAPConfigPreSetup.sh script is run, which performs the following:

• Creates the Roles and Reservation User containers in OID, if they do not already exist.
• Loads Identity product specific schema into the Directory

The LDIFs used to load the schema into OID contain all the old Oblix attribute names, and in my environment they are found in [MW_HOME]/Oracle_IDM[x]/oam/server/oim-intg/schema.

• OID_oblix_pwd_schema_add.ldif
• OID_oim_pwd_schema_add.ldif
• OID_oblix_schema_add.ldif
• OID_oblix_schema_index_add.ldif

This is great, because it should mean that we can count on using familiar attributes like obuseraccountcontrol and obusersessiontimeout.

Some things just don't change...at least not for another 6 months or so...

VDE Shadow Object LDIF

If you are using the OVD Shadow Joiner feature then you will need to add the vdeShadowObject object class to the directory hosting the shadow objects. Here is a little LDIF file for just such a need...

# Description: contains vdeshadowobject vdeprimaryref for use with shadow joiners
#
dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.17119.1.0.1 NAME 'vdeprimaryref' DESC 'This attribute contains an MD5 hash of a primary adapter' EQUALITY 'caseIgnoreMatch' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' X-ORIGIN 'user defined' )
-

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: vdeprimaryref
-

# ObjectClass Definitions
dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.17119.1.1.1 NAME 'vdeShadowObject' DESC 'This object is used by VDE Shadow Joiner to store a shadow object to a primary entry in another directory. This objectclass normally used in conjunction with the extensibleObject object class to hold local attributes. vdeprimaryref is a hash of a DN that points to a primary object in an alternate adapter.' SUP top AUXILIARY MUST ( vdeprimaryref ) MAY ( description ) )
-

Can't See Workflow

Successful migrations of Oracle Access Manager (formerly COREid) configuration data rely heavily on consistent directory naming of entries between envionments. It is not enough for configuration data objects to share the same user friendly names, they must have the same RDN (Relative Distinguished Name) values in the directory server. This forms the basis of clean migrations. As well, objects must share the same properties. If this setup is performed in advance of using the COREid Migration Service or alternatively, corrected in a pre-existing environment using the COREid Migration Service migrations will run smoothly. The situation described below illustrates how having inconsistent environments can cause problems.

Have you ever copied a workflow definition from one environment to another and had the workflow not appear in the Oracle Access Manager (formerly COREid) Workflow applet? You double check the target directory server and indeed all of the entries are there so you wonder what could possibly be happening.

If this sounds familiar, then this is likely highlighting a difference between your two environments that you might not know existed. The problem is probably related to when your environments were first built manually independent of one another.
The cause is that there are different objectclasses associated with the tab_id that the workflow is meant to manage.

For instance say in the development environment the Employees tab (default user tab in Oracle Access Manager) has associated with it structural objectclasses of user and oblixOrgPerson. But in the quality assurance environment where you migrated the work flow to it has objectclasses of user, obligOrgPerson and auxCompanyPerson.

This provides an obvious barrier to performing clean migrations between environments. The way to correct this problem is to make the objectclasses look the same. The best way to do this is to get one environment in a pure state (i.e. contains all of your active development) and then migrate it to the other environments. This way all of the environments will be the same and ready to migrate information from one environment to another.

Create Clean Schema File from AD/AM

Have you ever wanted to get a nice clean schema file containing all of your custom attirbutes and object class entries but exluding the special microsofty attributes from and AD/AM (or AD) instance so that you can archive it off into a source control system or just simply migrate it to another environment? You dread the task becuase you never took the time to automate it so you always edit the file by hand. Well here is a simple regex that you can use to clean up the file after you extract it. The regex as written works in editplus (by far the best editor I have ever used, come on buy it, you know you want to), but can can be easily tweaked to work in other editors, scripts, etc.

Anyway, there are three steps...

1. Extract your data... here is the ldifde way
   

   ldifde -f {filename} -s {server} -t {port}
   -d "CN=schema,CN=configuration,CN={adam_guid}"
   -r {custom object searhc filter}

2. Prune the unwanted attributes
   In the following section it should all be read as a single regex (ignore line breaks). It should be used in a substitution statement where nothing is substituted for the match.
   

   ^(distinguishedname|instancetype|whencreated|whenchanged|
   usncreated|usnchanged|name|objectguid|schemaidguid|objectcategory|msds-intid)
   ::? [^\n]*\n( [^\n]+\n)*

3. Replace the AD/AM GUID to make it really easy to import into a target environment change the GUID in the file to something easy to type that is not repeated elsewhere in the file.