October Patch Updates Breaks Shared Services. 126.96.36.199.x
Blog > October Patch Updates Breaks Shared Services. 188.8.131.52.x
Date: October 28, 2020
Article by: Jeff Henkel
Well it’s always fun with EPM, and October’s latest patch updates brings an issue with Shared Services. If you apply the October updates, be aware that Shared Services will stop working in your EPM 184.108.40.206.x environment. The following patch for oracle_common is needed to bring things back to working:
Unable To Access Shared Service Console After Weblogic October Patch Is Applied Error “The required application module ‘cas.containers.tadpole’ is not configured” (Doc ID 2613736.1)
The cause of this issue is a change in the ODI logging parsing mechanism, as explained here:
This issue is only noticed on Oracle Fusion Middleware deployments where the underlying Oracle Diagnostic Logging (ODL) component is based on 220.127.116.11.
The ODL 18.104.22.168.0 LoggingConfigurationImpl method uses an older parsing mechanism when reading the logging.xml configuration file rather than the one used in the FMW 22.214.171.124 ODL implementation.
The WLS PSU aligns with the newer implementation.
The application of the patch should probably be done on all EPM servers in the environment, though technically only Foundation Services requires it.
Also, if you’re on the 11.2.x version, then this shouldn’t apply, since that code-line should already be using newer ODL code.
If you should have any questions or concerns with patching your EPM environment, let us know, we’re here to assist as always!
More Fun With Patching: Oracle Critical Patch Update for October 2020
Blog > More Fun With Patching: Oracle Critical Patch Update for October 2020
Date: October 21, 2020
Article by: Jeff Henkel
It’s the end of another quarter, and with it comes Oracle’s latest security patch updates. In particular, there appear to be a number of items for Hyperion in this month’s rendition.
Looking at the above, of particular concern is the Hyperion Essbase component which has an exploit with a base score of 9.8. This signifies a risk to the server since it can be exploited fairly easily, based upon the attack complexity rating. Digging further, the recommendation is to patch the Essbase side of the components to at least Essbase 126.96.36.199.040, and Essbase Administration Server to 188.8.131.52.037.
The second item on the list UI and Visualization addresses an issue with the Workspace, and the recommended patch is 184.108.40.206.825.
While the other items may be a concern, their lower scores make them less of an immediate issue for customers and can most likely be addressed at a later patching time.
Of course an Oracle Security release wouldn’t be complete without WebLogic patching as well. The current version has updates for both 11.1.2.x customers and 11.2.x customers. In the case of 11.2.x customers this is the customary CPU patch for WebLogic, and for 11.1.2.x customers it is both a full WebLogic Server patch and a CPU patch.
As always, if you need assistance applying Oracle patching, let iArch Solutions assist, we’re here to help!
There are times when the realities of product design meet the harsh world of security requirements. This seems to happen more and more often, and one of the more glaring culprits is UAC.
We here at iArch Solutions are great proponents of security, and take the role of securing environments very seriously. We are also specialists in EPM and this product suite presents challenges with UAC. One of those challanges is the pesky need to run a lot of processes with elevated security. This is something that Microsoft’s UAC is designed to prevent.
So, what exactly is UAC?
UAC is an access control that aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation. In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system. In other words, a user account may have administrator privileges assigned to it, but applications that the user runs do not inherit those privileges unless they are approved beforehand or the user explicitly authorizes it.
Why, does EPM not like it?
Well, as noted in the definition above, the UAC code is designed to keep processes (and the service level accounts running them) from acting as administrators without confirmation. For server-side software, perhaps running behind-the-scenes processes at 2 AM, this confirmation can be an issue. Some of the items that UAC might flag are:
· Running an Application as an Administrator
· Changes to files in folders that standard users don’t have permissions for (such as %SystemRoot% or %ProgramFiles% in most cases)
· Running Task Scheduler
· Backing up and restoring folders and files
All of the above are components and/or items that EPM software frequently activate. With the end result that Oracle has plastered their EPM documentation with explicit statements requiring that it be disabled:
In both the of above instance, this verbiage is not limited to simply installing and configuring the code-line. These are vendor stated requirements to ‘install, configure and run’ the EPM System products.
How does one disable it?
So, with the above stated, how does one disable it? Oracle has been helpful in the EPM 220.127.116.11 install guide and offered directions here. Those steps used to work pretty regularly in Windows Server 2008 R2, and sometimes in Windows Server 2012.
In newer versions, the above might not be enough. You may also find a need to edit the registry at the following key by setting the EnableLUA value 0:
In closing, I feel I’d be remiss if I didn’t touch on the security ramifications of all of this. Essentially, the UAC process is good security. It is designed to prompt users (and this concept of user is important here) to confirm when changes to important system items are made. This prevents things from happening to their PCs without their knowledge. All client based operating systems do this…Mac, Windows, etc.
The concept of UAC becomes more problematic in a server based architecture. This is because most server based processes are not actively monitored, and administrators are not manning data centers, hands hovering over mouse buttons, ready to engage and resolve UAC prompts.
So, as architects we must understand that server-based architectures are different, and we are responsible for designing the surrounding security architecture (network, OS, physical, virus, malware, etc.) in such a fashion that UAC is a non-issue. If there’s already a hacker in your datacenter, on your server, executing code, and UAC is your last line of defense…well, you’ve got bigger problems.
In the meantime, Oracle EPM doesn’t really care about your security stance around UAC. It’s going to need to be turned off to work properly.