Many organizations that we visit have installed Oracle Primavera P6 using the defaults, including passwords that have since never been changed. This is great for when we turn up on site as we can access all their Primavera P6 data immediately and discover what’s really going on. Sadly, it’s also great for anyone with a more malicious intent. Here we look at how to help Primavera P6 Administrators make their site more secure and provide more protection to their organization’s P6 data.
The Primavera P6 Database Users
The default Primavera P6 install creates two database users used by the client and web applications to access the P6 database. In addition, there is a third user that actually owns the P6 database objects including procedures, functions, indexes and tables. The following table provides the default names for each user according to the database type. Whatever the type of database in use, the password is always the same as the username ouch!.
|Object Owner||Owns all the tables, synonyms, functions and procedures that make up the P6 database||ADMPRM$PM||ADMUSER||sa|
|Private User||Owns all the tables, synonyms, functions and procedures that make up the P6 database||PRVPRM$PM||PRIVUSER||privuser|
|Public User||Used by the P6 Client and Web Application to get hold of the private user’s password||PUBPRM$PM||PUBUSER||pubuser|
The Oracle XE database is a free express edition database that is based on the full Oracle database offering. The SQL Server database is of course Microsoft SQL Server. All these users are created during the installation of the Primavera P6 database.
How Primavera P6 Data Is Accessed
Both the P6 Client and the P6 Web application require a real user to supply their Username and Password to login. The Public User and it’s password is supplied to these P6 applications when the connectivity information is first created. The application first logs in as the Public User to the database. This user has access to one table called PUBUSER. There is usually just one row containing the name of the Private User and an encrypted version of it’s password.
The P6 application decrypts the private user password and uses it to log in as the Private User. It then has access to all the tables in the P6 database. Having got to this point, it verifies the credentials originally supplied by the user against P6 tables or by using LDAP if it has been configured. The P6 application will make changes to data in the P6 database as the Private User.
Someone who knows the username and password of the Public User will only be able to gain read-only access to the P6 PUBUSER table. The idea behind the Public User is that even though it’s database username and password can be public knowledge, it still isn’t enough to gain access to any real P6 data. Anyone who knows the password of either the Private User or the Object Owner has access to all the data in the P6 database.
We recommend the password for the Private User and the Object Owner is changed on all existing Primavera P6 systems so that it doesn’t match the username. When it comes to new installations, we also recommend using different database usernames for these two users as well as different passwords. The Public User could be treated the same, but we don’t believe it makes for a much more secure environment.
Having changed the password for the Object Owner, there is one more action that can help further secure your P6 database. The Object Owner isn’t really used during normal operation of Primavera P6. It really only comes in to play when installing or upgrading the database. When doing these tasks, it needs to be endowed with the DBA Role. Most of the time it simply doesn’t need all that power. Oracle themselves provide a script that can be ran against the Object Owner. We’ve changed it by commenting out the granting of the *create session* privilege, because nobody needs to even connect as the Object Owner during regular operations.
You’ll have to swap ADMUSER in the following script for the name of your Object Owner if it is different.
REVOKE DBA FROM ADMUSER;
Grant select on SYS.V_$TRANSACTION to ADMUSER;
Grant unlimited tablespace to ADMUSER;
–Grant create any job to ADMUSER;
Grant select any table to ADMUSER;
Grant select any dictionary to ADMUSER;
One more thing we would recommend to change in the above, is to give the QUOTA Unlimited to the Primavera Tablespaces instead of granting unlimited tablespace.
A Secure Summary
Here is a summary of what can be done to make your Primavera P6 installation a little more secure.
- Create new Primavera P6 databases using different database users to the P6 defaults.
- Change passwords for the Object Owner and Private User at the very least.
- Revoke the privileges of the Object Owner as per the script, so they can’t connect and can’t change anything.
For more Primavera P6 articles click here