July’s Critical Patch Update from Oracle includes CVE-2011-2241, which affects OBIEE versions 10.1.3.4.1 and 11.1.1.3. No details of the exploit other than it “allows remote attackers to affect availability via unknown vectors related to Analytics Server.” It is categorised with a CVSS score of 5 (on a scale of 10), with no impact on Authentication, Confidentiality, or Integrity, and “Partial+” impact on Availability. So to a security-unqualified layman (me), it sounds like someone could remotely crash your NQSServer process, but not do any more damage than that.

This problem, which in essence is bad behaviour from Informatica bringing down Oracle, is a good illustration of unintended consequences of an apparently innocuous security setting. Per our company’s security standards, database passwords expire every 90 days. When this happens users are prompted to change their password before they can continue logging into Oracle. This applies to application user IDs too. It appears that Informatica 8.6.1 HF6 (part of OBIA 7.

Troubleshooting EBS-BI integrated authentication can be a tiresome activity, so here’s a shortcut that might help. If you suspect the problem lies with EBS then you can leave OBIEE out of the equation. Login to EBS Use FireBug or Fiddler2 to inspect web traffic as follows: Click the BI link from EBS Should be first a request to EBS server, which returns 302 and redirects to http://<bi server>:<port>/analytics/saw.dll?Dashboard&acf=101507310 Record the value of acf (eg 101507310)

JMX OBIEE’s Systems Management functionality exposes performance counters and the application’s configuration options through Java MBeans and optionally a protocol called JMX. It’s extremely useful, and is documented pretty widely : JConsole / JMX JConsole / JMX – followup Oracle BI Management / Systems Management MBeans PerfMon OBIEE MBeans and OC4J OBIEE performance monitoring and alerting with jManage In this article I’m going to discuss the use of JMX to access these counters remotely, and a possible security issue that’s present in the BI Management Pack manual.

This error caught me out today. I was building a Linux VM to do some work on, and for the life of me couldn’t get the OBIEE Admin Tool to connect to the BI Server on the VM. The error I got when trying to define a DSN on the Windows box was: [nQSError: 12008] Unable to connect to port 9703 on machine 10.3.105.132 [nQSError: 12010] Communication error connecting to remote end point: address = 10.

Oracle Application Server (OAS) is the Web and Application server typically deployed with OBIEE. There are several settings which by default may be viewed as security weaknesses. Whether realistically a target or not, it’s good practice to always be considering security and lock down your servers as much as reasonably possible. I adopt the default stance of having to find a reason to leave something less secure, rather than justify why it needs doing.

October’s Oracle Critical Patch Update Advisory has been released. There are two vulnerabilities (CVE-2009-1999, CVE-2009-1990) listed under Oracle Application Server for “Component” Business Intelligence Enterprise Edition and one (CVE-2009-3407) for “component” Portal. CVE-2009-1999 is OBIEE and “Fixed in all supported versions. No patch provided in this Critical Patch Update.”. CVE-2009-3407 looks like only OAS (not OBIEE), up to versions 10.1.2.3 and 10.1.4.2. CVE-2009-1990 is OBIEE and is the main vuln of interest.

The Critical Patch Update Pre-Release Announcement for October has been published. The pre-release is advance notice of the affected software prior to release of the quarterly Critical Patch Update. It is published on the Thursday prior to the patch releases (which was postponed by a week because of OOW). It looks like if you’re running OBIEE 10.1.3.4.0 or 10.1.3.4.1 through OAS 10.1.2.3.0/10.1.3.4.0/10.1.3.5.0 then you should check back next Tuesday 20th for details.