OBIEE Lockdown - Part 1

Security Recommendations in Oracle Business Intelligence Installations

There are three key security recommendations for installing and securing OBIEE in your enterprise environment.

1.       Be serious about password management.

It is important to lock down the OBIEE environment and changing default passwords after installation.

The passwords for weblogic user should not be simple to guess or widely distributed. The best practice is to have different passwords throughout the environments. Moreover, I’d recommend replacing “weblogic user” with another obfuscated username. The username and password combination should be different throughout the environments (at least the password).

Change the default passwords for the RPD, as everyone knows “Admin123.”  If you are promoting an RPD, your password for Dev, Test, and Prod RPDs should be different as well to avoid a possibility of a developer making changes in a wrong environment.

Do not use the administrative account to present reports to the users and avoid providing it to users, there is high risk of breaking/deleting something by accident. Consider automating deployments to avoid having to deal with passwords manually.

2.       Take the authentication and authorization outside of OBIEE

Use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only does it improve user experience by removing the need to memorize yet another username/password, but it also saves time for the development team. Remember: They are not in the user management business. Another great use case is the ability to push this functionality further by automating users’ authorization by managing LDAP groups’ memberships and mapping them to the OBIEE’s application roles.

3.       RPD Security Objects

Unfortunately, the Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit the RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, there are limited built-in options to audit or keep track of the RPD development changes. One must rely on a custom developed solution if this functionality is important. An easy and practical option is to keep an XLS spreadsheet of the major development milestones. It’s simple; however, its disadvantage is, that there is an overhead associated with maintaining it, especially during active development periods. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track deltas. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.

OBIEE MUDE

It's been a while since I last put up any substantial post so I thought maybe it was time to leave you with a brain dump of what I've (been attempting to) achieved over the past month.

Two major things stand out;
1. MUDE - Multi User Development Environment.
2. Integration with SVN Subversion.

The first was a no-brainer really, a few too many developers in the repository at once, lots of half finished code, the nightmare of promoting the repository to production based on what was complete or mostly complete. Definately time for MUDE.

For those of you unaware of MUDE and what it is, not many I'm sure, it is a method of segregating the repository into various projects, where each project is self contained and has all the component parts required to function. The projects can be checked out to a local install by developers where they work, in isolation, before merging their changes back into a central repository.

MUDE

To setup MUDE you need three things; a bi server, a shared directory on that server and a full local install of OBIEE.

On the server create a shared directory and ensure that all your users have sufficient priveleges to merge changes back.
The MUD Administrator then copies in the Repository required and this will become the MUD master against which all changes are published.
The repository is opened offline and divided into projects - again by the MUD Administrator.

On the client side the users open the OBIEE administration tool and in the Tools --> Options --> Multiuser Tab, point the where the MUD master shared directory (\\server\muddir) is and describe the environment (eg DEV Machine)

When a developer wants to work they will start the OBIEE administration tool on their local installation. From the File menu they will then select Multiuser and then checkout. Select the project, as setup by the MUD Administrator, on which you want to work and open.

The local repository consists of only those details required to make the top level components in the repository work. The project may not have specified the physical layer to include and this will be added at checkout by the MUD process.

The developer, using their local install, will make changes and test outputs against their local answers queries for that project.

Once changes are made the operator has several options;
1. Discard changes - revert to how things were.
2. Refresh subset - pick up any changes in the master MUD repository that have occured since the checkout, that affect this project.
3. Compare to original - show what has changed.
4. Publish to Network - promote changes back to the MUD Master repository.

When you publish back to the MUD Master repository, a merge takes place and if conflicts arise, you need to resolve them by selecting what goes through for publication.

The MUD Master repository will then be uploaded through EM and changes promoted up through your environments.

Just bear in mind the following;

You may require named user plus licensing to be financially viable
MUD is more complex than online development, but makes sense when you know how it works
MUD Administrator divides main repository into projects; self-contained RPD subsets
Master repository is then published to a network share
Projects are then worked on independently, and then merged back into the master RPD
Uses the repository compare and merge features under the covers
Works best when each developer has a full OBIEE “Sandbox” environment to develop with and unit test their work License considerations

Integration with SVN follows.

MUD - Multi User Development (option file)

Recommendation - Each user of MUD ie. those that will check out projects, make changes and check those changes in, should have a full (simple) install on their local machine.

Before going 'big-bang' on MUD, try all the features in a simple and controlled manner.

Pay particular attention to creating the (hidden) repository.opt file and using the correct options. This has a big impact on the way you will work.

1. The MUD options are set in a file that you create in the MUD shared directory.
2. The filename should be be the same as the MUD master repository ie. if your MUD master is called BIREP.rpd, then your options file should be called BIREP.opt.
3. The file attributes should be set to hidden using the file properties dialog box.
4. As an additional step you may want to disallow edit permissions to all users (beyond a nominated set of administrators).

Note: Any options not explicitly set are considered to be turned off by default.

The contents of the opt file are as below:
[Options]
BuildNumber = Yes
Enforce Build Number = 11.1.1.7.0
Enforce MUD Protocol Version Number = 1
Prevent Rpd Upgrade = Yes
Admin = weblogic;joebloggs
Mandatory Consistency Check = Yes
Equalize During Merge = Yes

To turn an option off either, remove it from the file or set the value from Yes to No.

BuildNumber = Yes - when set to Yes this displays the build version of the administration tool in MUD history.

Enforce Build Number = 11.1.1.7.0 - When set this means that only users with an exact match of Administration Tool version can make changes. To unset this option remove it from the opt file.

Enforce MUD Protocol Version Number = 1 - This option will only allow those users with an exact match of MUD version number to perform changes. Remove this option to disable the enforcement.

Prevent Rpd Upgrade = Yes - Only users with an exact match of repository version can perform changes using MUD. It is possible for later versions (client side) to check out and make changes to the repository and potentially (though unlikely) make changes incompatible with the current master MUD repository . Set to No or remove to disable this option.

Admin = weblogic;joebloggs - This is the list of MUD administrators, seperated by semicolons. Only administrators listed here can delete MUD history.

Mandatory Consistency Check = Yes - A full consistency check is performed at publish to network. All errors in the repository will need to be fixed before publishing completes. Set to No or remove to disable this option.

Equalize During Merge = Yes - A equalisation process takes place during the merge process, potentially affecting performance. The equalization process ensures that objects in the two repositories that have the same name but different upgrade ids are treated as the same object, preventing unintended renaming during the merge.