Managing a Secure PS_HOME on Windows
When deploying a secured PS_HOME environment on UNIX, keep the items in this section in mind. Depending upon your domain configuration and usage pattern, you may need to unlock specific subdirectories of PS_HOME.
This page explains mapped drives (Windows share drives) and the use of UNC paths for PeopleTools application server, Process Scheduler server, and search servers. When a PeopleTools domain is started on a Windows machine, it runs under the user for whom the ProcMGR Windows service has been configured. As such, the domain processes inherit the privileges of that user and not the user logged on to the system.
By default, the ProcMGR runs as the Local System account. While the Local System account has most privileges on the local host, it can't usually access UNC paths or mapped drives.
Note: ProcMGR is the Windows service that is responsible for allocating resources to Tuxedo domains.
Accessing UNC Paths and Mapped Drives
To allow PeopleTools domain processes to access UNC paths or mapped drives, it is necessary to start the ProcMGR service using an account that has access to these resources. This is typically a Windows domain account. A domain account refers to an account that logs a user ID on to both a machine and the corporate network. This account has been created by the network administrator. An example of such an account would be BIGCOMPANY\TSawyer.
The ProcMGR should be configured to start as the domain account. On the Log On tab of the service configuration dialog, click This account:, and enter the credentials of the domain account.
If you plan to use UNC paths to access PS_HOME you must start PSADMIN using a UNC Path. For example:
With the ProcMGR service set to a domain account, you can use PSADMIN to create and configure domains as if PS_HOME were on the local file system.
Additional steps are required if you plan on using a mapped drive for your PS_HOME or PS_CFG_HOME. These additional steps are required because Windows services do not recognize mapped drives. However, Oracle Tuxedo provides a mechanism by which the ProcMGR service is permitted to access network drives, which involves defining any mapped drives using an additional environment variable, TM_TUXIPC_MAPDRIVER. If this environment variable has not been set, the domain processes will be unable to recognize the network drives.
To make sure that the TM_TUXIPC_MAPDRIVER variable is visible to the ProcMGR service, it is necessary to set it globally, as a System environment variable. For example, set TM_TUXIPC_MAPDRIVER to:
Important! The mapped drive cannot point directly to PS_HOME. The mapping must point to the parent directory above PS_HOME. For example, if PS_HOME is N:\\10.233.238.123\PTInstalls\pt850, TM_TUXIPC_MAPDRIVER should point to N:\\10.233.238.123\PTInstalls. PTInstalls is the parent directory of \pt850, which would resolve to N:\pt850.
Note: When mapping network drives to the PS_HOME is located, make sure to select Reconnect at logon.
Note: The working directory for psadmin.exe, must always be mapped to a letter drive, such as C:, D:, N:, and so on. When starting psadmin.exe, you must do so from the command line (or script) by referencing the full mapped working directory, such as \\ptinstalls\pt851\APPSERV\psadmin.exe. Launching psadmin.exe outside the current working directory (as in, using Start, Run) will cause psadmin.exe to function incorrectly. This restriction is imposed by Tuxedo.
When logging on with user accounts Oracle ProcMGR service should be set to Manual instead ofAutomatic. Failure to do so may result in your domain account becoming locked. If set to 'Automatic' the service may continually attempt to start with an expired password causing the network to lock out the domain user account due to successive failed retries.
Note: On Windows servers, it is recommended to have the Windows user logged in running PSADMIN be the same user that runs the ProcMGR service.
See PeopleTools Installation guide for Oracle.
The TM_TUXIPC_MAPDRIVER environment variable needs to be maintained consistent with the mapped drives upon which you access PS_HOME. If the drive mappings change, then you need to make sure the new values are specified in TM_TUXIPC_MAPDRIVER. If the drive mapping represented by the TM_TUXIPC_MAPDRIVER does not exist, the ProcMGR service will fail to start.
If the PS_HOME used by your domains is on a network drive, you may notice a delay with starting a domain. This is a result of the binaries being loaded from across the network versus from the local disk. This can cause an initialization timeout.
If you notice domain start failures, check for the following message in the Tuxedo log for the domain:
tmboot.16020.15792.-2: CMDTUX_CAT:1859: ERROR: Server process ID 12668 failed to initialize within 60 seconds
In such cases, increase the timeout values in the domain’s environment variables to accommodate for the slower start time. Use the Edit environment settings option on the Quick Configure menu to modify environment variables.
TM_BOOTTIMEOUT : TM_RESTARTSRVTIMEOUT :
For more information on editing domain environment variables, see Setting Domain-Level Environment Variables.
For PeopleSoft systems, the Oracle ProcMGR service (tuxipc.exe) is responsible for starting Tuxedo domain processes on Windows. By default, domain processes run as the same user ID that the service is running as. In a default installation, the service is configured to log on to Windows as the Local System user. Microsoft does not support assigning network privileges to the Local System user for security reasons, but the Local System user otherwise has full administrative access to the local system.
In this configuration, PeopleTools domain processes also run as the Local System user, which presents several potential issues, including:
PeopleTools domain processes are unable to access network resources.
PeopleTools domain processes run with more privileges than are necessary. A compromised PeopleTools process will have full access to the local system and could potentially be used to gain unauthorized access to the local system.
All PeopleTools domain processes on the system run as the same user ID
These problems are not present on UNIX systems where domain processes are always started as the user that runs tmadmin (by way of PSADMIN for PeopleSoft installations) to boot the domain. UNIX systems therefore support multiple domains, each running under different user IDs, with only the desired local privileges, and with no undesirable restrictions to network resources.
For Windows platforms, you can use the Oracle Tuxedo TM_CPAU (Create Process As User) environment variable to achieve behavior similar to UNIX systems. If TM_CPAU is set to YES before tuxipc is started, tuxipc creates an Oracle Tuxedo process that belongs to the user who initiated tmboot. If tuxipc boots as a service, go to Start, Control Panel, System, Advanced, Environment Variables and set system variable TM_CPAU =YES on the dialog box and reboot the Oracle ProcMGR service. If the Oracle ProcMGR service (tuxipc.exe) is started with the TM_CPAU=YES environment variable set, then domain processes will run as the user ID used to run tmadmin (PSADMIN) to boot the domain.
Using the TM_CPAU environment variable enables a variety of configuration options, including:
The ProcMGR service can be run as the Local System user, but domain processes can be run using a minimally privileged user. This reduces the chance of a compromised PeopleTools process being used to gain unauthorized access to the system.
The ProcMGR service can be configured to log on to Windows using a minimally privileged user ID and PeopleTools processes can run as a user with more privileges than the Tuxedo user ID. For example, the Tuxedo user ID could have read-only access to PS_CFG_HOME, but the PeopleTools user could have read-write access. The Tuxedo user ID does not actually require read-access to PS_HOME. When CreateProcessAsUser runs, access to the executable to start is evaluated using the user ID that the process will run as.
A single Windows system can be used to host multiple PeopleTools installations that are each administered by a different user. A non-administrative user ID used to boot one domain will have no privileges to processes started with a different user ID.
Domain processes can be identified and managed in Windows Task Manager by a non-administrative user.
For more information, see Oracle Tuxedo documentation: "File Formats, Data Descriptions, MIBs, and System Processes Reference."