security

Uncategorized

I often get to hear the following question concerning OBIEE agents:

“Why can’t we send out personalized content (filtered data / row-level security) to non-OBIEE users by simply using their email address residing in the data?”

Killer answer: Security!

Think about it: If you use “Get Recipients from the Analysis used in the Agent Condition”, it will actually perform a complete login with authentication + authorization through the security realm and only the fetch the data.

Now imagine that you bypass this “because it’s so convenient to just have the email in the data”. And now imagine me doing this:

update MYTABLE set EMAIL = ‘uber.h4xx0r@somenastyplace.thief’;
commit;

I think this should be answer enough as to why you do NOT want to be able to do this.
At all.

Uncategorized

When hooking up OBIEE 11g to an LDAP, make sure to check some factors on the LDAP side of things as well. Not all errors have to come from your configuration in WLS:

  1. LDAP users intended to replace “OracleSystemUser”, “weblogic” and “BISystemUser MUST” all reside in the same base DN that’s used to search for users in the LDAP config
  2. They also MUST all be of the same objectClass as the one referenced in the LDAP config
  3. Creating “technical users” to distinguish them from “human users” and putting them in different branches and / or storing them as different object classes (e.g. “account” or rather than “person”)

First thing you should get is an LDAP browser with which to connect to the LDAP server to check validity of the connectivity ccount (i.e. the “Principal” for LDAP connectivity) as well as structures and object types. This will save you a lot of pain and suprising behaviour due to “ceative” LDAP management.

Cheers!

Uncategorized

I recently deployed a new RPD to one of my BI servers and after restarting the coreapplication, wasn’t able to log on anymore – the login process hung at “Singing in…” indefinitely.

After some investigation, I found out what had happened:
1.) The new RPD used connections to a datasource situated on a different database (other than the primary DWH) which were utilised in new initialization blocks which fired upon login (no “deferred execution”).

2.) The TNSNAMES on the BI server machine had contained all necessary connectivity information until the night before, but had been reset to a default configuration during the night for some reason and only retained the primary DWH.

3.) This caused the login process to hang indefinitely without any meaningful errors being logged and hence nothing was visible in Enterprise Manager.

4.) Restoring the TNSNAMES with all relevant DB entries removed the error and login was possible again.

Conclusion: never assume that your infrastructure setup is a “given” and won’t change.

Cheers,
Christian

Uncategorized

Hi guys,

Just quickly to let you all know. I’m not cutting you out of the loop by not writing on the details, but if I’d have to document all tests I run and all issues I find, I will still be here next month.

Bottom line:
– watch out for 10.1.3.4.0 with 734908
– watch out for 10.1.3.4.0 with 844119
– watch out for 10.1.3.4.1

With those three versions be VERY careful that you test each and every report you have running against Essbase.

I will update you as soon as I can with a finalized overview. Probably only once Oracle has come back…