Configuring the users or users.local files

About the users and users.local files

The users and users.local files grant access permissions to specific users connecting to a server. The permissions granted in the users and users.local files override any permissions defined on a per-client basis in the exports file. The permissions in the users and users.local files are defined on a per-user basis.

The users file is primarily used to implement user permissions that are defined through RBAC. (For more information about RBAC, see Managing-access.) With RBAC you define the characteristics of a role and assign users to that role. You can apply RBAC decisions to a server by running an ACL Push Job in the TrueSight Server Automation Console. Running an ACL Push Job automatically converts your role definitions and role assignments into entries in the users file on that server. Together these entries are called an access control list (ACL).

Typically the users.local file is used for granting permissions on a per-server basis rather than granting system-wide user privileges. Administrators might want to modify the users.local file to override RBAC policy on a particular server. Both the users and users.local files have the same format, but the users.local file is scanned before the users file. If the same users have entries in both users.local and users, entries in the users.local file take precedence.

The agent on a server enforces user permissions defined in an ACL by mapping incoming users to users defined on the server. The agent accomplishes this by doing the following:

• Incoming users are matched to a user name on the server. In other words, when user betty attempts to connect to a server, she must operate with the privileges already assigned to user betty on that server. In this scenario, a user cannot connect to a server unless a matching user name has been defined on a server.
• Incoming users are mapped to a specified user name. For example, all users connecting to a UNIX system can be mapped to root, while users connecting to a Windows system can be mapped to Administrator.
• If neither of the two previous techniques are possible, incoming users are automatically mapped to a user with downgraded permissions. UNIX users are mapped to user nobody and Windows users are mapped to Anonymous.

An ACL Push Job generates users file entries that grant a variety of permissions, including permissions for commands. The job uses the following algorithm to create users file entries relating to command authorizations:

• If no command authorizations are specified on the server in the TrueSight Server Automation Console:
  • And no command authorizations are specified for a role, no command authorizations for that role are pushed to the agent. This means the role has full authorization to use any Network Shell and nexec commands on that server.
  • But command authorizations are specified for a role, those command authorizations are pushed to the agent. This means the role is authorized to perform those commands on the agent.
• If command authorizations are specified on the server in TrueSight Server Automation Console:
  • But no command authorizations are specified for a role, no command authorizations for that role are pushed to the agent. This means the role has full authorization to use any Network Shell and nexec commands on that server.
  • And command authorizations are specified for the role, the command authorizations common to both are pushed to the agent. This means the role is authorized to perform only those commands on the agent.

When you make changes to the users or users.local files, the RSCD agent automatically detects your new settings and uses them for all subsequent client connections. You do not have to restart the agent or otherwise instruct it to read the new users or users.local files.

The users and users.local files reside in different locations in Windows and UNIX systems, as described in the following table.

The users and users.local files do not grant permissions on Windows servers to roles that are set up for Windows user mapping. For information about Windows user mapping, see Windows user mapping and agent ACLs. However, the users or users.local files should still include an entry for each role so that role can be granted access to a Windows server. Only the user mapping information in the users and users.local files is ignored for roles that employ Windows user mapping through automation principals. All other settings still apply. Consequently, even if you are using Windows user mapping, you should still push agent ACLs to servers when you add or modify user or role information in the TrueSight Server Automation Console.

The following sections provide more information about configuring the users and users.local files.

_{Back to top}

To configure the users or users.local files

Both the users and users.local files are a list of entries. Each entry grants permissions to a user. The format of each entry consists of two fields.

• The first field provides a role and a user name, separated by a colon, such as BLAdmins:BLAdmin.
• The second field is a comma-separated list of permissions that apply to the user defined in the first field. For a complete list of available permissions, see Options for users and users.local files. If an option sets multiple values, separate each value with a colon. For example, hosts=host1:host2.

For Network Shell users that are not communicating with servers through a Network Shell proxy server:

• The first field in a users file entry provides only a user name. No role is necessary because Network Shell does not recognize roles. The name of a Network Shell user should match the name of the user on the client host who is attempting to make a connection to this server.
• The second field is a comma-separated list of permissions that apply to the user defined in the first field. For a complete list of available permissions, see Options for users and users.local files. If an option sets multiple values, separate each value with a colon. For example, hosts=host1:host2.

Below is a sample users file with entries for DBAdmins:george and DBAdmins:betty. In this example, DBAdmins is the role and george and betty are users. Below these entries, two more entries grant george and betty access to this server using Network Shell. In these entries george and betty are not paired with any role

If george and betty communicate with the server by means of a Network Shell proxy server, the Network Shell entries shown above are not necessary. The entries for DBAdmins:george and DBAdmins:betty would grant george and betty access to this server.

The users file can also include a nouser entry. Including this entry instructs a server to allow a connection from a user only when that user has been explicitly defined in the users configuration file. When you use an ACL Push Job to push a users file to a server, TrueSight Server Automation places a nouser entry in the users file if that server has a property called PUSH_ACL_NO_USERS_FLAG set to true.

Lines in the users and users.local files that begin with # are considered to be comments.

_{Back to top}

Using wildcards in the users.local file

The users.local file allows you to use a wildcard in place of user names when defining role:user combinations. This capability is unique to the users.local file.

For example, you could create a users file entry such as:

An entry like this grants read/write access to all users who have assumed the role of SecOpcs. All users in the role are mapped to root.

Identifying users with a wildcard provides some benefits. By performing a modification like this, you can temporarily allow all users in a role to access a server without first running an ACL Push Job to change the users file on that server. In some organizations, running an ACL Push Job might first require a lengthy change control process.

Using a wildcard:

• Lets you authorize all members of a role to perform certain types of actions. You do not have to update entries in the users.local file when users are added to or removed from a group.
• For user names in the users.local file is a capability that should be used sparingly. Entries in the users.local file override entries in the users file. Thus an entry like the one shown above overrides any more restrictive settings defined for the role using RBAC.

_{Back to top}

Options for the users and users.local files

The users and users.local files provide the following options that you can use to assign access permissions to users:

_{Back to top}

Examples for the users.local file

In the following example, the first and second entries in the users file grant read/write access to user1 and user2, who are associated with the role of SrAdmin. Both users are mapped to Administrator on this server. Because no hosts field is provided, user1 and user2 can access this server from any other server. The third and fourth entries, which are for user1 and user2, do not associate those users with a role but do map them to user Administrator. These entries are used for granting permissions to Network Shell users. The fifth entry grants read-only access to user3, who is associated with the role of JrAdmin and is mapped to Anonymous on this server. The last entry forbids access to all users who are not specified in the users file.

SrAdmin:user1 rw,map=Administrator
SrAdmin:user2 rw,map=Administrator
user1 rw,map=Administrator
user2 rw,map=Administrator
JrAdmin:user3 ro,map=Anonymous
nouser

The following example in the users.local file grants read/write access to user1 and user2 if they are connecting from either host1 or host2 and they have a local account with the same user name and user ID as they do on the host from which they are connecting. If user1 is not connecting from host1 or host2, then user1 is only given access to the /data directory and granted the permissions of user3. If user2 is not connecting from host1 or host2, user2 is granted read-only permission.

user1 hosts=host1:host2,rw,validuser
user2 hosts=host1:host2,rw,validuser 
user1 rw,rootdir=/data,map=user3 
user2 ro

The following example in the users.local file grants read/write access to user1 and user2 and forbids access to all other users.

user1 rw 
user2 rw 
nouser

Using users.local to specify an alternative root directory

Using the rootdir option in the users.local file, you can set an alternative root directory and limit the directory hierarchy to which the RSCD agent has access on a UNIX platform. The rootdir option is equivalent to the chroot option of a UNIX operating system. When you set the rootdir option, the RSCD agent changes the file system root to the directory that you specify.

For example, if rootdir is set to /tmp (that is, rootdir=/tmp), the RSCD agent sets its file system root to /tmp, and from this point onwards all operations are performed with respect to /tmp.

As a result of the change in the file system root, the RSCD agent expects all required objects to be located in the new root specified by the rootdir option, rather than in the default / root. This impacts the following central features in TrueSight Server Automation:

• Live Browse: To enable the use of the Live Browse feature, you must set up a file system hierarchy under the new root similar to the file system hierarchy found under the default / root. This enables the RSCD agent to load the DAAL-related shared objects and the related system shared objects necessary for executing Live Browse requests. If the required objects are not in place, the Live Browse view displays empty results. 
  
  On a Linux system, a live browse of system information is also dependent on the /proc file system, and this file system must appear in the new file system root. You can use the mount command to achieve this.

• Remote command execution: To ensure that all commands specified in the remote_cmds file execute properly, the OS commands and their related system shared objects hierarchy must be found under the new root directory. To achieve this, you can either copy files or mount directories onto the new root directory.

  Example

  The date command is dependent on the following shared objects:

  • librt.so.1 => /lib/tls/librt.so.1 (0x006ce000)
  • libc.so.6 => /lib/tls/libc.so.6 (0x00b34000)
  • libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00f04000)
  • /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00c87000)

  If rootdir=/tmp, the date executable and its dependencies (listed above) are searched with respect to /tmp as the root, and not /. For the date command to work, you must ensure that /bin/date, /lib/tls/librt.so.1, /lib/tls/libc.so.6, /lib/tls/libpthread.so.0, and /lib/ld-linux.so.2 are located in /tmp.
  You can either selectively copy these files into the respective directories or mount the /lib and /bin onto /tmp/bin and /tmp/lib.

_{Back to top}