OAM and OSSO have been integrated in 11g R2 and the integrated product is backwards compatible to both old OAM and OSSO enabled products. Oracle is delivering on a promise to converge applications for the better. This will enable the reduction of authentication complexity.

One of the key tasks during development and deployment of OAM is running the product browser-based-setup process. It is this process that results in the initial 'oblix branch' being written to the directory service. So, when a customer wants to start again, the question is, "How do I make that setup process happen again?"

There are two browser-based-setup processes:

1) Identity System
This is the process that writes the initial o=oblix branch. To force this process again, locate the file [identity server install]/identity/oblix/config/setup.xml and locate the line indicating the current step - it should have a value of 'done'. Edit this value to 'incomplete' and save the file. Restart the webserver and identity server and navigate in a browser to /identity/oblix and request the Identity System Console. The Setup screen should appear.

Note that you can run this setup process with or without major underlying directory changes. Also note that (depending on what you are changing) you may also need to reconfigure individual software components using each one's command line configuration program (found in some form at .../oblix/tools/[setup|configure]).


2) Policy Manager (Access System)
The setup process for the Access System results in the writing of the obapp=PSC branch of the directory. To force this process find the file [policy manager install]/access/oblix/config/setup.xml and rename the file to something else. Then restart the webserver and navigate a browser to the /access/oblix. Request the Access System Console and you should see the setup button.

As on the identity side, depending on what you are doing, you may need to reconfigure the software components installed using their command line setup utilities.

That should be enough information to get you going in the right direction.

Labels: OAM setup "browser based setup"

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 ) )
-

Labels: OVD, Shadow Join

I was installing OAS 10.1.4.0.1 today as I needed to use OID for an OAM deployment. I had a brand new linux vm, all of the pre-installation check list items (kernel tuning et al) were complete and all that was left was to install the software. So, I ran the installer. It ran very, very slowly but still ran. It eventually just hung when it got down to actually copying files. There was no failure message in the log file, it just seemed to be paused. The installer appeared to still be running but nothing was happening. Being the glutton for punishment I am, I deleted everything and re-ran the installer and was met with the same result (big surprise).

I scoured metalink, but to no avail so I started poking around though and found a completely obscure line in the /etc/hosts file. The DNS server had the IP address of the new vm right, but the /etc/hosts file contained an Internet addressable IP for the new vm (weird). Anyway, removing that line and trying again corrected the problem. I probably should have checked that first; next time I will.

Labels: name resolution, OAS, OID

Many of our readers are aware that we have had the "COREid Migration Service" available for public use for the past three years. This service has been a resounding success with several high profile North American OAM customers relying on it to maintain consistency across their environments. The expression, "If it ain't broke, don't fix it." best describes our attitude towards the initial release.

But the time was right for a platform upgrade, some rebranding, and some minor issue fixes.

Stitcher lives at the same address as the original service. If it sounds like something you've been missing, check it out.

Labels: "COREid Migration Service", migration, OAM, Stitcher

Setting up IWA is a fairly straight forward task. All you need are an OAM environment, an IIS server with WebGate installed and special IWA Authentication Scheme. The IWA specific authentication scheme requires a credential mapping plugin to map the REMOTE_USER HTTP header variable set by IIS to a user attribute in the OAM user directory. WebGate even takes care of parsing the domain name from REMOTE_USER for you, what could be easier?

So assuming you followed all of hte instructions and everything is set up perfectly, or at least you think it is, what do you do if you still have a problem. Specifically, what could be wrong if are getting a credential mapping error in the web browser and the access server oblog.log file.

I recently encountered just such a problem. I used the search base and filter from the credential mapping plugin and conducted my own search against the directory as the OAM service account and it worked perfectly. This was so puzzling. I looked for trailing spaces in the credential mapping plugin because I know that can occur with resource patterns and ldap urls in other parts of Policy Manager. I finally compared a working credential mapping plugin to the IWA one. The different was in the quotation marks. The IWA credential mapping had been copied and pasted from the Metalink article discussing how to set up IWA in OAM. They were obviously from the wrong character set. Replacing the quotation marks solved the problem.

Labels: Authentication Scheme, Credential Mapping Error, Integrated Windows Authentication

The "Employees" tab of user manager can have multiple panels in it:

• The defaultPanel
  
• The Header Panel
• The Search Results panel
• Any other user defined panels

Labels: jCardPanel tab panel user manager

This is known problem but i had trouble finding the solution so here it is re-posted from the OAS release notes for HP-UX... the resolution worked perfectly BTW.

This problem occurs when you use Oracle Internet Directory as the back-end repository. To fix this problem:

1. Edit the file ldapreferentialintegrityparams.xml in the following directory:

   Identity_Server_installation_directory\identity\oblix\data\common

2. Change the value of the parameter referential_integrity_using from oblix to ds, as follows:

3. Save the file.

4. Restart the Identity Server for the changes to take effect.

   You should be able to modify the RDN attribute value without any problem.

5. If you have multiple instances of the Identity Server installed, make this change to every instance of the Identity Server.