OAM supports UTF-8 in incoming data, and can generate HTML pages encoded with UTF-8, but what about internally? Is UTF-8 data available in plugins? In HTTP header variables? We tested 10.1.4.3 on Windows and were surprised that our UTF-8 data was being interpretted incorrectly in our managed plugins (though exec ppp plugins worked as expected).

The character Û ( U with a circumflex) has a code point value of 219 (all numbers are decimal). In UTF-8 this is encoded as the bytes 195 & 155. However, when this text reaches our plugin it appears as Û (A with tilde & single right-pointing angle quotation mark). In .NET Strings are in unicode, so we know something is happening with the identity server to re-interpret the bytes 195 & 155 as some other encoding and then to provide us that String as unicode. That encoding turns out to be Windows-1252 - the default code page on our Windows system. 195 is Ã, while 155 is ›. Luckily there is a simple workaround – we get the Windows-1252 byte value of the string and then interpet those bytes at UTF-8.

Encoding encoding_1252 = Encoding.GetEncoding("Windows-1252");
string utf8String = Encoding.UTF8.GetString(encoding_1252.GetBytes(windows1252String))

Using Reflector I can see a few calls to StringToHGlobalAnsi in the managed library, and I would guess a similar call like PtrToStringAnsi is used for converting between unmanaged and managed memory, and this may be a cause of the issue.

This issue also exists in the Access Server. If you want to send a UTF-8 attribute value in a header, OAM is smart enough to base 64 encode it (according to RFC 2047 ). So our value should be encoded useing this format "=?UTF-8?B?" base64-encoded-text "?=". Unfortunately, the text to be encoded is incorrect – the access server is B64 encoding the Windows-1252 interpretation of the UTF-8 bytes. You'll need to B64 decode the header text and then use the re-encoding code shown earlier to get the real value.

One thing to note is that if your default code page is something other then Windows-1252, you'll proably have to interpret the string using that code page.

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.

Labels: OAM Service Account Permissions OID

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