Securing PS_HOME on Windows
When securing PS_HOME on Windows, you have these options:
Multiple administrator user accounts.
Local user accounts.
Multiple Administrator User Accounts
This method of securing PS_HOME on Windows offers the ability for many administrator user accounts to share the same PS_HOME while managing separate PS_CFG_HOMEs. This method is most appropriate for a production environment.
In this configuration, you install PeopleTools on a server machine, and share the PS_HOME installation location as read-only. Domain administrators may then map to this network drive, and invoke PSADMIN to create and start domains.
Once you have set up a secure PS_HOME, domain creation and the various prerequisites for setup are the same as before. For example, database connectivity must be available on the machine on which the domain will boot. The server where PS_HOME is located acts as a read-only file server for the domains.
To illustrate this procedure, two user accounts are used.
An administrator on Machine, having read-write access to PS_HOME.
An administrator on Machine2, having read-only access to PS_HOME. A restricted user.
In this scenario, one administrator installs PeopleTools, and a second user, with a more limited set of privileges, creates and administers domains.
The steps for User2 on Machine2 can be applied to multiple users. Any number of users can map to a single read-only PS_HOME.
Note: This information applies to PeopleTools installations on drives assumed to be formatted as NTFS.
To install PS_HOME and restrict privileges:
While logged in as User1 on Machine1, run the PeopleTools installation program.
Choose Application Server and Batch Server installation options.
File Server is optional, depending upon whether or not it is required.
Ensure that you install PeopleTools such that PS_HOME is not the top most directory on the drive.
Note: This is essential if you plan on accessing PS_HOME as a mapped drive.
After the installation has completed, set privileges on the PS_HOME directory tree, using Windows File Sharing.
Using Windows Explorer, select the high-level directory (as in D:\PTInstalls), right-click, and select Sharing and Security.
On the Properties, Sharing tab, click Share this folder.
Click Permissions, and for the Group of Everyone, check the Allow checkbox for Read, make sure the Allow checkbox for Change is not selected, and click Apply and/or OK.
Verify that the folder has been shared by making sure the ‘hand’ icon appears on the folder in Windows Explorer.
To set up access to a secure PS_HOME:
Sign in as User2 on Machine2.
Map a network drive to the shared PS_HOME.
Verify that you cannot add, modify, or delete any content below the mapped location.
This ensures that PS_HOME is read-only. If you can delete or change content in the mapped location, it is possible that User2 is an administrator on Machine1. User2 must not be an administrator on Machine1 for these security measures to be effective.
If User2 cannot see the shared location there may be a problem with the share or the local network. Make sure the machine can be pinged.
Configure Oracle ProcMGR service to allow the User2 account to access PS_HOME.
This is necessary because by default the Oracle ProcMGR service uses the Local System account.
Select Start, Programs, Administrative Tools, Services, and double-click on the Oracle ProcMGR service.
On the General tab, stop the service, and set the Startup type to Manual.
On the Log On tab, select the This account radio button, and enter the logon information for User2.
Note: Do not start the service yet.
Set the TM_TUXIPC_MAPDRIVER user variable for User2.
This environment variable must be set to contain any mapped drives required by the domain processes, such as the drive where PS_HOME is located. Use the following format:
If multiple mapped drives are required, use a semicolon to separate the values, similar to the way directories are expressed in the PATH environment variable.
Note: Depending on your network, use either the DNS name or the IP address to specify the machine name.
Note: If the Oracle ProcMGR needs to run unattended, where no user is signed in, set the TM_TUXIPC_MAPDRIVER environment variable as a system environment variable instead of a user environment variable.
Start the Oracle ProcMGR service.
Once started, you can start PSADMIN as you normally would.
Local User Accounts
Using local user account to secure PS_HOME is a machine-bound solution that you may consider during an initial demo, development, or testing environment, where PS_HOME and PS_CFG_HOME reside on the same machine. In this method, only one machine and one domain account is required.
In this scenario, PeopleTools is installed by a user with administrative privileges. In the context of this scenario, this refers to the network domain user, a user that is a member of an existing network domain of users.
Application server domains are administered by a second user with a more limited set of privileges. This second user is created on the local system and only has access to resources on that machine.
In the following procedure, these user types are represented as:
User1 is an administrator on Machine1 and belongs to the network domain named COMPANY.
Guest2 does not have administrative privileges on Machine1 but can sign on to Machine1. Guest2 is a Restricted User.
Setting up a secure PS_HOME and restricting privileges:
While logged in as User1 on Machine1, install PeopleTools to the server using the install program.
Choose Application Server and Batch Server installation options. File Server is optional depending upon whether or not it is required.
Ensure that you install PeopleTools such that PS_HOME is not in the top directory level on the drive. For example, an ideal location would be C:\PTInstalls\PT8.52.
While logged in as User1 on Machine1, create the Guest2 user account.
Create a new user with at least the following attributes:
Select Restricted user on the Group Membership tab.
De-select the User must change password at next logon checkbox.
See Microsoft Windows documentation for more information related to creating users on Microsoft Windows.
Verify that the user is a Restricted User by highlighting the user ID and clicking on the Properties tab.
You may need to exit and re-enter the User Accounts dialog to see the new user added.
Make the PS_HOME directory tree read-only.
Open Windows Explorer and navigate to and select the PS_HOME directory location.
Open the Properties dialog and click on the Security tab.
Deny Write access to all Local Users.
To configure access PS_HOME:
Setup the Oracle Proc MGR Service to allow the IPC resources to be created using the restricted user ID (Guest2).
This is necessary because by default the Oracle PRocMGR service uses 'Local System' account which provides greater access to the PS_HOME than desired.
Select Control Panel, Administrative Tools, Services.
Double click on the Oracle ProcMGR and change the Startup Type to Manual.
Change the user and password with which the service is started to match the new local user that you created earlier (Guest2).
Note: Do not start the service, just click OK.
Log off and sign on to Machine1 as Guest2.
In most cases, any error messages that you see when re-signing on can be ignored as they are associated with signing on with restricted permissions.
Verify that you cannot delete, update, or add any content to PS_HOME.
Before creating a domain your database connectivity must be setup within the restrictions of the guest2 local user account that you have created.
Start PSADMIN, and create a new domain, and confirm that the domain boots.
Install PIA on a separate machine, and verify that you can signon through PIA.
Because PIA is not within the scope of the secure PS_HOME, PIA should be installed on an additional machine. This is necessary because PIA needs write access to various locations within PS_HOME.