Every now and then I find that I am battling permission issues in the unix environment and it usually turns out to be the permissions that are set on the directory or file.  Unix has an interesting way of handling permissions.  If you do a list command “ls -l” you will see a box of information on the left that looks like:

———- (10 dashes) If you see this, the file has NO rights (pretty rare).

The first position you will commonly see a “d” or “l”, the “d” is for directory, and “l” is for a link.

Position 2 to 4 are the owner permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 5 to 7 are the group permissions “rwx”, where “r” is read, “w” is write, “x” is execute

Position 8 to 10 are the world permissions “rwx”, where “r” is read, “w” is write, “x” is execute

You can change the permissions using the command: “chmod”

To grant the read permission you give a value of 4, write permission is 2, and execute is 1.  So if you want to grant read+write, you would do 4+2 = 6.  And when you issue the chmod you give it a number for each permission (owner, group and world), so if you wanted to give the owner, group and world read and write access to a file you would issue the command:

chmod 666 filenametochangepermissionsto

Another useful function is the chown function, which changes the owner and/or group permission.

chown user:group filenametochangeownershipto
chown -R user:group directorytochangeownershiptorecursivelyto

Peoplesoft has an interesting authentication process, and basically it goes something like this.

When you attempt to login in a 2-tier mode, for example in HR trying to log into application designer using the user “PS”, what will end up happening is it will lookup the connect id and password that is assigned in the Configuration Manager setup (pscfg). This user is a database user typically called “people”. This database user is granted select access by the grant.sql script when the system is built on the tables: psstatus, psoprdefn, psaccessprfl. In Oracle there is another table that this user can access and that is PS.PSDBOWNER (there is a public synonym so you can just look for PSDBOWNER).

The PSSTATUS table needs to have the OWNERID field set the main owner of the database. In Oracle it is by default “sysadm”, in SQL Server the default was typically “sa”, but that changed with the introduction of the access id profile, and so it would be the access id that you setup that should be in this field for SQL Server.

The PSOPRDEFN table needs to have the OPRID you are trying to log into with, and the OPERPSWD needs to be set correctly, this field is encrypted, but if you need to change it, go into SQL and update the password, and make sure you change the ENCRYPTED field to “0” zero. Then you can re-encrypt the password by running datamover in bootstrap mode and executing the command: ENCRYPT_PASSWORD *;. Also note the field SYMBOLICID, it needs to match the SYMBOLICID in the psaccessprfl table.

The PSACCESSPRFL has the fields SYMBOLICID, ACCESSID and ACCESSPSWD. The SYMBOLICID needs to match the symbolicid of the psoprdefn table entries. You can have multiple SYMBOLICID’s however, make sure they are all valid. PeopleSoft can throw errors if this table has invalid entries, or if the ACCESSID has limited access (but that is another story). The ACCESSID and ACCESSPSWD should be set to same user as the OWNERID in PSSTATUS. If you need to change these values do so in SQL, make sure you change the ENCRYPTED field to “0” zero, and then in datamover bootstrap mode execute the command: ENCRYPT_PASSWORD *;

Lastly, in Oracle, make sure that the PSDBOWNER table has one row that contains the database name, and the OWNERID as mentioned above. I always make these fields UPPERCASE as well.

If all of these entries are set correctly, you should have no trouble logging into PeopleSoft.

Note: The reason bootstrap works with a database user is that it skips over the PeopleSoft authentication and simply authenticates using the database security, however, bootstrap should be used with CAUTION.

Linux is a great platform that has many advantages over a windows based platform, and one of those advantages is PGP (Pretty Good Privacy) available on a base install. In 1991 Phil Zimmermann created the first version of PGP encryption which allows for cryptographic privacy and authentication for data communication. It is widely used for securing email, but can be used to secure texts, files, directories, hard drives, and is now being used to encrypt entire computer systems.

To use PGP, you need to create or import a certificate into the keystore. The keys can be in DSA or RSA formats and have lengths of 1024 to 4096 bits on most systems. The certificates can also be set to never expire or be set to expire within a certain timeframe.

To List Keys in the Keystore:
pgp –list-keys

To Generate a new key:
gpg –gen-key

To Import an existing key:
gpg –import ~/keyfilename.gpg

To Import an existing key secret key:
gpg –allow-secret-key-import –import ~/secretkeyfilename.gpg

When you need to export the data, you will need to remember that there is two parts to the key, the public key, and the secret key. When a client wants to encrypt data for you they will require the public key.

To Export an existing key and secret key:
gpg –output keyfilename_public.gpg –armor –export keyname
gpg –output keyfilename_secret.gpg –armor –export-secret-key keyname

To Encrypt/Decrypt a file, remember the passphrase used, if forgotten your data will remain encrypted forever.

To Encrypt a file:
gpg -c filenametoencrypt (you will be asked for the passphrase to encrypt with).
Non-Interactive:
gpg –yes –passphrase={YourPassPhrase} -c filenametoencrypt

To Decrypt a file:
gpg filenametodecrypt (you will be asked for the passphrase used to encrypt with).
Non-Interactive:
gpg –yes –passphrase={YourPassPhrase} filenametodecrypt

It really amazes me how many times I find at client sites Application Servers that randomly won’t start. There are a combination of issues that can cause the problem, but typically I find the problem to be related to this group of tables.

PSSTATUS – this table has a field called OWNERID, which needs to make the schema owner in Oracle, and should match the ACCESSID in SQL Server.

PSACCESSPRFL – this table has the fields SYMBOLICID, VERSION, ACCESSID, ACCESSPSWD, ENCRYPTED. The accessid should match the OWNERID from PSSTATUS table, and the password would be the password at the database level for the schema/accessid user. If you change this to an unencrypted value you will want to change the accesspswd to an unencrypted value and set the encrypted field to 0, and then run datamover and do the encrypt_password *; statement to reencrypt the passwords. You will also notice the SYMBOLICID field, this is associated to the SYMBOLICID field on the PSOPRDEFN table. VERSION can be reset using the VERSION Application Engine. I recommend that there only be one entry in this table, sometimes having multiple entries can cause problems if the accessid/password are invalid for the environment, because PeopleSoft has a tendency to expect only one entry in this table.

PSOPRDEFN – this is your primary parent information table for security. Make sure that the password is set correctly, if you reset it to a clear text entry, you can reencrypt it using the encrypt_password *; command in datamover. Make sure you set the encrypted field to 0 (zero) before running datamover. You will also want to make sure that the SYMBOLICID matches that of the PSACCESSPRFL table. Lastly, make sure that the ACCTLOCK is set to 0 for the user trying to start the Application Server. You will also want to make sure it has a Permission List that allows it to start the application server.

PS.PSDBOWNER – In Oracle there is another table in the PS schema that contains the Database Name and Owner, make sure these are set correctly.

Make sure that the connect id user often known as “people” is setup in your database and it has been granted select access to the tables: PSACCESSPRFL, PSSTATUS, PSOPRDEFN.

Lastly, make sure that the USERID matches your user that you want to start the Application Server from PSOPRDEFN, and that the password is set correctly, and make sure that the CONNECT ID user / password is correct in the configuration files of the application server.

The typical 2-tier connect takes the userid and authenticates it against the PSOPRDEFN table using the connect id user, which in turn allows a connection to be made to the database using the symbolicid associated with the PSOPRDEFN table, which is tied to the accessid on the PSACCESSPRFL table. So once authenticated that system is actually running the session as “accessid” but controlled by the PeopleSoft security assigned to the user.

Google Chrome

Google Chrome: Security

At one of my client sites they are constantly doing security changes, and for some reason recently several users complained that they could not access Oracle PeopleSoft via the Chrome browser.  It was returning

Error 312 (net::ERR_UNSAFE_PORT): Unknown error.

After doing some trusty Google Searches, I found this simple solution:

Right click on your Icon (shortcut) to run Chrome and go to properties, and on the Target line add the parameter:

--explicitly-allowed-ports=xxxx,yyyy,zzzz

where xxxx, yyyy and zzzz are ports that you want to allow.  This will solve the problem.