Just a quick note on some security-related things to watch out or during/after an in-place upgrade to OBIEE 184.108.40.206. These were experienced on a 220.127.116.11.3 to 18.104.22.168.0 upgrade on 64bit Linux:
1.) Application Policies:
All custom-created application policies were dropped during the upgrade, leaving only the vanilla ones. Affected file: system-jazn-data.xml.
2.) Application Roles (this one is a bit queerer):
Affected file: system-jazn-data.xml.
Unmodified vanilla roles come through the upgrade unharmed and retain all their vanilla members (users, groups and app roles alike).
Custom roles equally come through the upgrade unharmed and retain all their vanilla as well as custom members of all kinds.
The problem is with vanilla application roles which have received new/additional members when compared to a plain install:
The role itself still exists, but it loses all vanilla members and only retains custom members.
Example application role “BIAdministrator”:
Pre-upgrade members: vanilla group “BIAdministrators” (WLS-native LDAP group); group “CustomAdministrators” (custom LDAP derived group); user “cberg” (custom LDAP derived user) and several others.
Post-upgrade members: group “CustomAdministrators” (custom LDAP derived group); user “cberg” (custom LDAP derived user) – the WLS-native LDAP group has been dropped.
This wasn’t immediately visible due to the new way the members of an application role are displayed (call me old-fashioned, but I prefered the old style – the new doesn’t allocate enough screen real-estate) doesn’t really show it at quick glance and I was wondering why I got weird “Logon Failed” errors when wanting to check the RPD online while all the logs proudly proclaimed “No no, you’re definitely authenticated nicely”. WLS and EM logons oviously work since the app role concept doens’t kick in.
Hope this helps other people from wasting time.
@Borkur seems to have another nice one related to security hanging around. I’ll make sure to ask him to post his one into the comments.