Setting Permissions for your Oracle Access Manager Bind Account in OID

The bind account that OAM uses to connect to OID directory services needs to have full rights over the portion of the DIT that you intend to manage with OAM.

It is considered a best practice to avoid using the root user (cn=orcladmin) who has rights over the whole context and the rest of the server. It's also a good practice to avoid the use of cn=orcladmin,cn=users,dc=company,dc=com to preserve it for general context administration.

An efficient way of making sure your new OAM service account has the right stuff is to set the user up with the same group memberships as the context administrator account (that's the cn=orcladmin,cn=users,... guy).

ldapsearch -h hostname -p 389 -D cn=orcladmin -w [password] -x -b "cn=groups,cn=OracleContext,dc=company,dc=com" "(uniquemember=cn=orcladmin,cn=users,dc=company,dc=com)" uniquemember

# OracleContextAdmins, Groups, OracleContext, company.com
dn: cn=OracleContextAdmins,cn=Groups,cn=OracleContext,dc=company,dc=com
uniquemember: cn=orcladmin
uniquemember: cn=oraclecontextadmins,cn=groups,cn=oraclecontext
uniquemember: cn=orcladmin,cn=users,dc=company,dc=com
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com

# OracleUserSecurityAdmins, Groups, OracleContext, company.com
dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext,dc=company,dc=com
uniquemember: cn=orcladmin
uniquemember: cn=oracleusersecurityadmins,cn=groups,cn=oraclecontext
uniquemember: cn=orcladmin,cn=users,dc=company,dc=com
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com

# iASAdmins, Groups, OracleContext, company.com
dn: cn=iASAdmins, cn=Groups,cn=OracleContext,dc=company,dc=com
uniquemember: cn=orcladmin
uniquemember: cn=ias & user mgmt application admins,cn=groups,cn=oraclecontext,dc=company,dc=com
uniquemember: cn=iasadmins,cn=groups,cn=oraclecontext
uniquemember: cn=orcladmin,cn=users,dc=company,dc=com
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com
... etc.

which gives you a good starting point for a file of modifications to add your new account into the right groups to achieve general context admin rights without having to fuss with ACLs.


# OracleContextAdmins, Groups, OracleContext, company.com
dn: cn=OracleContextAdmins,cn=Groups,cn=OracleContext,dc=company,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com
-

# OracleUserSecurityAdmins, Groups, OracleContext, company.com
dn: cn=OracleUserSecurityAdmins,cn=Groups,cn=OracleContext,dc=company,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com
-

# iASAdmins, Groups, OracleContext, company.com
dn: cn=iASAdmins, cn=Groups,cn=OracleContext,dc=company,dc=com
changetype: modify
add: uniquemember
uniquemember: cn=ovd.service,ou=service,dc=company,dc=com
uniquemember: cn=oam.service,ou=service,dc=company,dc=com
-

You get the idea... (there are more than are listed in this post)

I'm sure there are other ways. This has worked well for me.

OAM and OSSO Integrated in 11g

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.

Forcing OAM Browser Based Setup

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.

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

OAS 10.1.4 Installation Hangs

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.

Introducing Stitcher - OAM Configuration Migration Solution

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.

Credential Mapping Error

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.

Panels in User Manager's Employees tab

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

The header panel, the defaultPanel and any user defined panels appear under "obpanelid=Employees, obapp=userservcenter, o=Oblix,<Config Base>" in the LDAP as "obpanelid=<some timestamp as ID>".

The header panel has its obpaneltype value as "headerPanel".

The value of "defaultPanel" for obpaneltype is for the default user profile panel. The user can change its name from "defaultPanel" to any other value, but the obpaneltype remains "defaultPanel".

Ever wondered what the third panel type, obpaneltype of jCardPanel? Its the panel for the search results!

Just because it does not show up as a "panel" on Identity System console can sometimes create confusion. For example when once because of some buggy horizontal migration, we eneded up with two objects with obpaneltype=jCardPanel and any change we attepted on the user manager tab profile, resulted in the error "This panel is already configured". From the Identity System console we could not see any duplicate panel information, it was only when we looked closely in LDAP, we saw two objects with obpaneltype=jCardPanel. Once we deleted the un-needed object and restarted ois server, things started working.