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.

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.