Setting up non-root user Ids for the command line interface

RSCT and RMC security authorization support manages user access based on individual resource classes and single nodes, for example, user access can be restricted to a specific RMC resource class on a particular node within the cluster. This level of authorization setting is complex and requires a clear understanding of the nature of each individual RMC resource class.

Therefore, you must create roles for a System Automation for Multiplatforms operator and a System Automation for Multiplatforms administrator with general settings that allow non-root users to manage all resource classes from any node that is defined within the cluster. Use the following procedure to create these two roles:
  • sa_admin for an administrator
  • sa_operator for an operator

The roles are described in more detail in the section: http://www.ibm.com/support/knowledgecenter/en/SSRM2X_4.1.0/com.ibm.samp.doc_4.1/sampugbug_limit_non-root.html

System Automation for Multiplatforms version 4.1.0.4 or higher provides the script samnonrootuser to perform this non-root user setup. The script requires an existing user, and then adjusts file permissions and ACL files to define the user as either 'sa_admin', or 'sa_operator'.

If the installed System Automation version is lower than 4.1.0.4, the manual setup as described below has to be performed :

To create the roles, perform the following steps (note that root authority is required). This example shows the commands that you must run in a Linux® environment:
  1. Create the user IDs that are authorized to manage System Automation for Multiplatforms on all nodes:
    # /usr/sbin/useradd ernie
    # /usr/sbin/useradd bert
  2. Create a group for the user IDs on all nodes:
    # /usr/sbin/groupadd sagroup 
  3. Add the group to the user IDs on all nodes:
    # /usr/sbin/usermod –G sagroup ernie 
    # /usr/sbin/usermod –G sagroup bert
    Note: Make sure to set the following environment variable for all users of System Automation for Multiplatforms on all nodes (peer domain scope):
    CT_MANAGEMENT_SCOPE=2
    You can set the variable permanently if you set it in the user profile.
  4. Change the group ownership of the file /var/ct/IBM.RecoveryRM.log.

    The file is used to track the System Automation for Multiplatforms history. All commands that modify the resources of the automation manager (IBM.RecoveryRM) are logged to that file.

    By default, the file is owned by the user group root:
    -rw-r--r--  1 root root   204 Oct 4 22:00 /var/ct/IBM.RecoveryRM.log
    Change the group ownership to sagroup:
    /bin/chgrp sagroup /var/ct/IBM.RecoveryRM.log
    Change the file permission to 664:
    # /bin/chmod 664 /var/ct/IBM.RecoveryRM.log  
           -rw-rw-r-- 1 root sagroup 204 Oct 4 22:00 /var/ct/IBM.RecoveryRM.log
    Note: If the file /var/ct/IBM.RecoveryRM.log does not exist after the initial installation of System Automation for Multiplatforms, you can create a dummy file by running the /usr/bin/touch command:
    # /usr/bin/touch /var/ct/IBM.RecoveryRM.log
  5. Modify the file /var/ct/cfg/ctsec_map.global on all nodes.
    You must add the following entries for the user IDs ernie and bert to the RSCT global authorization identity mapping file (/var/ct/cfg/ctsec_map.global) on every node in the cluster. Add the new entries above the entry for the user clusteruser:
    unix:ernie@<cluster>=sa_operator
    unix:ernie@<any_cluster>=sa_operator
    unix:bert@<cluster>=sa_admin
    unix:bert@<any_cluster>=sa_admin
    unix:bert@<iw>=sa_admin
    ..
    unix:*@*=clusteruser

    The file is used to map a local user ID on a node to a global user ID within the System Automation for Multiplatforms domain. In the example, the local user ID ernie is mapped to the global user ID sa_operator, and the local user ID bert is mapped to the global user ID sa_admin.

    You can authorize more local user IDs for System Automation for Multiplatforms by adding lines to this global map file (on all nodes), and mapping them to the wanted role operator or administrator.

    Note: If the file //var/ct/cfg/ctsec_map.global does not exist on a node, copy the default file /usr/sbin/rsct/cfg/ctsec_map.global to the directory /var/ct/cfg and add the new entries to the file /var/ct/cfg/ctsec_map.global. Do not remove any entries from the file /var/ct/cfg/ctsec_map.global that exist in the default file you copied. The /var/ct/cfg/ctsec_map.global files on all nodes within the cluster must be identical. Always add new IDs for non-root users above the entries for the user clusteruser.
  6. Modify the file /var/ct/cfg/ctrmc.acls on all nodes. You must add the following entries for the global user IDs sa_operator and sa_admin to the RMC ACL file (/var/ct/cfg/ctrmc.acls) on every node in the cluster and remove the line that starts with LOCALHOST, for example:
       The following stanza contains default ACL entries.
       # These entries are appended
       # to each ACL defined for a resource class and
       # are examined after any entries
       # explicitly defined for a resource class
       # by the stanzas in this file,
       # including the OTHER stanza.
       DEFAULT
       root@LOCALHOST * rw
       none:root * rw // give root access to all
       none:sa_admin * rw // append this row for saadmin
       none:sa_operator * rso // append this row for saoperator
    
  7. When you completed the required modifications, run the following command on every node in the cluster to activate the changes:
    # /usr/bin/refresh -s ctrmc
  8. Extra changes that are required to use sampolicy and *samadapter commands:
    1. Access to configuration files:
      # /bin/chgrp -R sagroup /opt/IBM/tsamp/sam/cfg
      # /bin/chmod g+ws /opt/IBM/tsamp/sam/cfg
      # /bin/chmod g+w /opt/IBM/tsamp/sam/cfg/*
    2. Access to log files:
      # /bin/chgrp -R sagroup /var/ibm/tivoli/common/eez/logs
      # /bin/chmod g+ws /var/ibm/tivoli/common/eez/logs
      # /bin/chmod g+w /var/ibm/tivoli/common/eez/logs/*
    3. Access to configuration files in the /etc directory. If there is no directory /etc/opt/IBM/tsamp/sam/cfg, create it by using
      # /bin/mkdir -p /etc/opt/IBM/tsamp/sam/cfg
      Then, set the appropriate permissions:
      # /bin/chgrp -R sagroup /etc/opt/IBM/tsamp/sam/cfg
      # /bin/chmod g+ws /etc/opt/IBM/tsamp/sam/cfg 
      # /bin/chmod g+w /etc/opt/IBM/tsamp/sam/cfg/*
  9. Optional adjustments that are required for working with the sam.policies package: Pre-canned policies for various applications are provided in the installation package sam.policies, which can be downloaded from IBM Integrated Service Management Library.
  10. To allow a user who has the sa_admin role to set up these pre-canned policies, the permissions, and the ownership of the /usr/sbin/rsct/sapolicies directory must be changed after the sam.policies package is installed on all nodes:
    # chmod –R 2775 /usr/sbin/rsct/sapolicies
    # chgrp -R sagroup /usr/sbin/rsct/sapolicies

When you completed the steps successfully, the local users ernie and bert can run operational tasks of System Automation for Multiplatforms, such as issuing start and stop requests against resources, and the local user bert can also run administrative tasks of System Automation for Multiplatforms, such as defining and modifying policies.