Resources Missing After Upgrade

It is unlikely that many will have this problem, but if you do this could save some time and headache troubleshooting...

When you upgrade from 7.x to 10.1.4.0.1 the resources on policy domains and policies go missing. It appears that the only known fix for this is to manually recreate this data using the UI after the upgrade.

The other approach would be to proactively take them out of the directory server before you do the upgrade and then simply add them back afterward.

The resources themselves are still there after the upgrade. All that is really missing is the pointer from the resource action object to the resource.

These can be found by performing an ldapsearch with the following criteria:

search base: obapp=PSC,OU=oblix root,DC=,DC=com
filter: (&(objectClass=oblixWRSCAction)(obResourceID=*))
attributes: obResourceID

This will return all of the objects that have this value set.

After the upgrade run the same search and compare the results. Those values should be missing. If so, prepare an LDIF file to update the entries.

An LDIF entry to fix the missing obResourceID could take this form...

dn: obname=,obname=,obapp=PSC,OU=oblix,DC=,DC=
changetype: modify
replace: obResourceID
obResourceID:

replace the tags with the appropriate value for your environment based on the LDIF you extracted.

Simple Mode Root CA Strikes Again

We discussed the expiration of this cert already in this post. I never thought i would see this problem again. Ahhh, was i wrong. When upgrading from COREid 7 to OAM 10, the 10.1.4.0.1 upgrade drops the old (now expired) root CA over the updated ones.

If you keep the faith and keep going the 10.1.4.3 patch set replaces it with the new one that is good until 2024.

transfilter.dll disappears and won't load

I just had the most frustrating experience. I am in the midst of upgrading OAM 7.x to 10.1.4.3. I had all the components upgraded to 10.1.4.0.1 so I got backups taken. Afterwards one of the webpass instances did not work. Upon further inspection transfilter.dll was actually removed form the file system. Strange, but no problem, i grabbed a copy from another 10.1.4.0.1 webpass.

The transfilter.dll still didn't get loaded by IIS and it still did not work. I ended up trying numerour different things. I added and re-added transfilter.dll to the Default Web Site multiple times. I uninstalled 10.1.4.0.1 and re-upgrade; still go the same behaviour. I uninstalled webpass alltogether (purged registry, etc) and installed 10.1.4.0.1 instead of upgrading an old one; still got the same behaviour.

I had given up home when i decided to try adding transfilter.dll at "Web Sites" instead of "Default Web Site". Low and behold it took and loaded. Then I tried moving it back to "Default Web Site" and it worked there too. I was back! Frustrated, but back.

I have no idea what caused transfilter.dll to disappear in the first place. I have no idea why it would not load in IIS after it was replaced. I have no idea why moving it in IIS fixed the problem. I am thankful though and if this strange occurence ever recurs I will have a strategy.

SAML Back Inside?

What's old is new again. Remember SAML Service in CoreID 5x? Sounds like OIF will be merged back into OAM in a future release.

OAM 11g R1

AuthN and AuthZ responses support much more options for returning user data. It appears that the need to create plugins to return more complex data has been eliminated.

Will your OAM installation fail in July 2010?

Is your OAM installation setup in simple mode? Then chances are your installation is going to break on July 25, 2010. You may have heard a faint ticking every time you got near one of your OAM machines, but never had a chance to figure out where this impending failure was going to come from. As you know,
according to Mayan Calendar, in 2012in simple mode OAM generates certificates for you using the simpleCA root CA (tools\openssl\simpleCA). This root certificate is also used to complete the chain of trust when establishing SSL connections.

But did you know that root CA certificates expire? The OAM certificate expires Jul 25 18:03:57 2010 GMT after which your OAM components will no longer be able to communicate with each other

How do I fix this?

Luckily the fix is extremely easy.

If you have an account for support.oracle.com, log in and search for ID 811105.1, which will instruct you to download a new cacert.pem and place it in all your simpleCA folders. Don't forget to include any AccessSDK installations, and make sure the new cacert.pem has the correct permissions.

If you don't have an account with support.oracle.com, then the release notes (bug 8556756) for OAM have instructions for extending the life of the Simple mode certificate. Once extended you can copy the new cacert.pem everywhere that it's needed and restart all components.

How do I know if I am affected?

You can browse to tools\openssl and use the openssl command to check the expiration date of the certificate.

openssl.exe x509 -in simpleCA\cacert.pem -noout -enddate

notAfter=Jul 25 18:03:57 2010 GMT

Oracle says the expiration date is July 5th, 2010 in their release notes. What is the real date?

Yes it does say that and we're not sure why. Feel free to update your cacert.pem prior to July 5th - no need to wait until the last minute.

What errors might I see if I did nothing?

WebGate protected pages will say they can't contact the access server.

You may see webgate errors like

2010/07/26@18:03:00.718000 3728 3240 CONN_MGMT ERROR 0x00001C08 \Oblix\coreid\palantir\aaa_client\src\watcher_thread.cpp:84 "NAP initialization failed"

2010/07/26@18:03:00.718000 3728 3256 CONFIG INFO 0x0000182C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:865 "ObAccessException_ENGINE_DOWN" raw_code^301

or if your certificate permissions are wrong

2010/07/26@18:04:59.796000 3712 300 ACCESS_SDK FATAL 0x0000181C \Oblix\coreid\palantir\access_api\src\obconfig.cpp:422 "ObAccessException_NOT_INITIALIZED" raw_code^204

2010/07/26@18:04:59.796000 3712 300 ACCESS_GATE FATAL 0x00001520 \Oblix\coreid\palantir\webgate2\src\iisentry_web_gate.cpp:183 "Exception thrown during WebGate initialization" Error^Oracle AccessGate API is not initialized.

UTF-8 and Oracle Access Manager

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.