Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Privilege Manager for Unix 6.1 Common Documents - Administration Guide

One Identity Privileged Access Suite for Unix Introducing Privilege Manager for Unix Planning Deployment Installation and Configuration Upgrade Privilege Manager for Unix System Administration Managing Security Policy The Privilege Manager for Unix Security Policy Advanced Privilege Manager for Unix Configuration Administering Log and Keystroke Files InTrust Plug-in for Privilege Manager Troubleshooting Privilege Manager for Unix Policy File Components Privilege Manager Variables Privilege Manager for Unix Flow Control Statements Privilege Manager for Unix Built-in Functions and Procedures Privilege Manager programs Installation Packages

How Privilege Manager for Unix works

The three main Privilege Manager for Unix components are:

  • The Client: The client is effectively the user who runs a command from their local machine by simply performing commands as root using the pmrun prefix.
  • The Policy Server: The policy server checks all commands with the policy file to ensure that the user is allowed to run the command, it then passes the command on to the agent for action. The policy server also logs the output result (that is, whether the command was successfully actioned or not), whether you enable keystroke logging or not.

    If you enable keystroke logging, it creates a much more detailed set of log files. The input/output log stores everything from keystrokes to input and output data. The event log purely records all of the requests made and their result.

  • The Agent: The agent performs the commands which are issued from the policy server and passes the result back to the client.

Figure 2: Privilege Manager for Unix components

Privilege Manager for Unix comprises four main programs:

  • pmrun
  • pmmasterd
  • pmlocald
  • pmtunneld

Users submit their requests to run certain programs through Privilege Manager for Unix using pmrun. For each request, the user may specify a program name and optionally a host on which the program will run.

The configuration file policy server master daemon (pmmasterd) examines each user request and either accepts or rejects it based upon information in the Privilege Manager for Unix configuration file. You can have multiple pmmasterd daemons on the network to avoid having a single point of failure.

NOTE: All Privilege Manager administrative tools, including the configuration commands are located in the /opt/quest/sbin directory.

Policy configuration file (pmpolicy security policy)

Users submit their requests to run certain programs as root, or another privileged account, through Privilege Manager using pmrun. The policy server daemon, pmmasterd, examines each request from pmrun, and either accepts or rejects it based upon the policies specified in the policy file.

The Privilege Manager for Unix configuration file (also referred to as the pmpolicy security policy) contains the security policy that the policy server master daemon (pmmasterd) considers when it accepts or rejects user requests. The configuration file can specify constraints based on certain attributes, such as:

  • Username
  • Group membership
  • Application name
  • Application arguments
  • Environment variable values
  • Umask (file permissions)
  • Nice value (priority of jobs run)
  • Working directory from which the request may be made
  • Host from which a request can be submitted (submitting host)
  • tty from which a request is submitted
  • Host from which the request will be run (execution host)
  • A remote, dedicated host to store iologs and/or eventlogs
  • Time of day and day of week that the user is allowed to run the application
  • Exit status or output of any specified program to be run as part of the decision-making process
  • A challenge to the user to type in one or more specified user passwords (requires on-the-spot approval from those users, such as supervisors or managers)
  • Whether the program being requested has a checksum that matches the one stored for that application in the configuration file (protects against possible virus or trojan horse attack)
  • Store all information for each request in a log file
  • Record all keystrokes and/or output in a dribble file
  • Some other miscellaneous job properties

If Privilege Manager accepts the request, the Privilege Manager local daemon (pmlocald) runs the application program as the runuser selected in the policy file, piping all input/output back to the user’s terminal. In addition, you can specify in the configuration file that you want to store all information for each request in a log file, and optionally record all keystrokes, output, or both, in an I/O file for later replay. You can replay the file in real time, so you can observe the commands as they are issued.

You can restrict responses to a small designated range of reserved port numbers by setting parameters in /etc/opt/quest/qpm4u/pm.settings. This enhances the security of communications between pmlocald and pmmasterd when the two must communicate across a firewall. See PM settings variables for details.

Privilege Manager for Unix utilizes NAT (Network Address Translation) to further restrict responses to a single designated port when pmlocald and pmmasterd must communicate across a firewall.

You can issue commands either in the foreground or background. If you run them in the background, you can continue to use the same shell process to issue additional commands. See Privilege Manager shells for details.

The policy file is:

  • Located on the policy server daemon host
  • Created in pm.conf

    By default, the policy file is named pm.conf and is located in the directory specified by policyfile. If the full path name for the pm.conf file is not specified in policyfile, the path is relative to policydir.

  • Owned by root

Only root can have write permission for the configuration file. Otherwise, a user might gain illegal access to the root account through modification of the file. To prevent someone from replacing the entire /etc directory or its contents, both / and /etc have permission modes that do not allow users to modify them.

The configuration file contains statements and declarations in a language specifically designed to express policies concerning the use of root and other controlled accounts.

For example, if your policy is: Allow user robyn to run the /bin/passwd program as root on the galileo machine Monday through Friday, during office hours (8:00 a.m. to 5:00 p.m.), add the following to your policy file:

weekdays={"Mon", "Tue", "Wed", "Thu", "Fri"}; if (user=="robyn" && command=="passwd" && host=="galileo" && timebetween(800, 1700) && dayname in weekdays) { runuser="root"; runcommand="/bin/passwd"; accept; }

NOTE: Do not use a leading zero for any time between 00:00 and 9:59 a.m. For example, when specifying 7:00 a.m., use 700 rather than 0700. Specify 12:30 am as 30 or 2430. Privilege Manager interprets numbers with leading zeroes as octal numbers: 0700 octal is 560 decimal, which is not a valid time.

Policy group

A policy group is a group of one or more policy servers – one primary server and any number of secondary servers. You can configure multiple policy servers in a policy group to share a common configuration for load balancing and redundancy.

Policy servers are responsible for evaluating the security policy and accepting or rejecting the agent request based on the constraints in the security policy. A policy group is one or more policy servers which have been configured to share a common policy.

Figure 3: Policy group

When the first policy server in the group is configured, it becomes the primary policy server and sole member of the policy group. To support load balancing and redundancy, you may add secondary policy servers to the policy group.

If a policy server becomes unavailable for any reason, hosts joined to the group will find the next available server in the policy group to service their requests. Any failover is transparent to the hosts, as the same policy is enforced by all policy servers within the policy group.

The primary policy server hosts the master copy of the policy from which the secondary servers receive updates. You can initiate changes to the policy from any policy server using the pmpolicy command. Once completed, the changes are committed to the master copy, and policy servers are automatically updated.

NOTE: See pmpolicy for more information about the syntax and usage of this command.

Planning Deployment

Before you run the installer, consider the following questions:

  1. Which machines in your network will run policy servers?

    If you only plan to use one policy server for an entire network, it should be the most reliable and secure machine.

    NOTE: You can specify multiple policy servers to avoid having a single point of failure.

    If more than 150 users will be using a single pmmasterd for validation, you will want to have multiple policy servers to avoid a UNIX network resource bottleneck. Plan to have a maximum of 150 users validating at a single policy server.

  2. Which machines will be managed hosts?

    Only those hosts running the local daemon (PM Agent package) may receive and run Privilege Manager for Unix requests. See pmlocald for details.

    One Identity recommends that you initially specify one policy server and three or four local hosts when you first install and experiment with Privilege Manager for Unix.

  3. What level of protection do you require?

    If you require greater protection, you can select an encryption level such as AES, or a dedicated encryption system such as Kerberos. When configuring Privilege Manager in interactive mode, you are asked if you are using Kerberos. If you are using Kerberos, Privilege Manager automatically uses Kerberos for encryption.

    You can configure the policy file to require a checksum match to authorize program execution. If configured in the policy, Privilege Manager runs the program only if its checksum matches that configured in the policy file. By default, it uses a CRC algorithm, but you can configure the MD5 algorithm instead by setting the keyword checksumtype to MD5 in pm.settings.

  4. Which port numbers should pmmasterd and pmlocald use to listen for network requests?

    Choose numbers that do not conflict with other numbers in the /etc/services file. Ensure these entries are propagated to all machines accessing Privilege Manager.

  5. Which directory should contain the Privilege Manager log files?

    By default, the log files are placed in /var/adm or /var/log depending on the host architecture. The installer allows you to change the directory by specifying command line options to the Privilege Manager daemons. The partition needs to contain enough space for log files to increase in size.

Documents connexes