Important

   

Starting version 8.9.03, BMC Server Automation is renamed to TrueSight Server Automation. This space contains information about BMC Server Automation 8.9.02 and previous versions. For TrueSight Server Automation 8.9.03 and later releases, see TrueSight Server Automation 8.9.

Configuring the users or users.local files

This topic explains the purpose of the users and users.local files, describes the available options, and details how to configure them. This topic includes the following sections:

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 BMC 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 BMC 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 BMC 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.

About manual changes in the users file.

Any manual changes in the users file are overwritten once an ACL Push Job runs. Use users.local file for any manual modifications.

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

Platform

Location

Solaris, Linux, AIX, HP-UX

/etc/rsc/users/etc/rsc/users.local

Windows

<WINDIR>\rsc\users
<WINDIR>\rsc\users.local
(For example, <WINDIR> can be \windows or \winnt.)

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 BMC 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, BMC 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:

SecOps:* rw,map=root

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.

Tip

BMC recommends adding an entry for RBACAdmins:RBACAdmin and BLAdmins:BLAdmin to the users.local file for every server. Because these roles cannot be deleted, they provide a way to access a server in case you accidentally revoke everyone else's permissions for that server. If you choose to rename the RBACAdmins or BLAdmins roles, the entries you make in the users.local file should reflect those naming decisions.

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:

Option

Description

commands=<cmd1[:cmd2 ...]>

This is a list of colon (:) separated commands that the user is allowed to execute on the local host. If no commands= option is given, the corresponding entry in the exports file determines what commands the user can run. See Restricting commands for more details on the use of this field.

exists

(UNIX only.) This entry tells the RSCD agent that an account with the same user name must exist on this host.

hosts=<hosts1[:host2 ...]>

This entry tells the RSCD agent that permissions should only apply if the user named in the first field is connecting from one of the hosts in this list of colon (:) separated host names and/or addresses. The addresses can be in IPv4 or IPv6 format, however when using an IPv6 address ensure that the server address is enclosed in square brackets. If no hosts field is provided, the entry applies to the user named in the first field regardless of what host that user is connecting from.

map=<username>

This entry forces incoming client connections to run with the permissions of <username>. For more information, see How BMC Server Automation grants access to RSCD agents. For Windows systems, you can enter a Windows user account SID rather than a user name.

nomknod

(UNIX only.) By default, clients are allowed to create special files (character special and block special). Specifying the nomknod option instructs the RSCD agent to prevent the client from making an mknod(2) call, generating an EACCES (Permission denied) error.

nosuid

(UNIX only.) By default, clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission using chown(2). If you specify the nosuid option, the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file's permissions.

nouser

This is a special user name that denies user access to the server unless the user has an entry specifically configured in the users or users.local files. When the nouser name is included in the users or users.local file, server access is limited to users specifically included in the users or users.local files.

ro

The named user has read-only access.

rootdir=<dirname>

(Linux and UNIX only) By default, the RSCD agent allows the client to "see" the complete directory tree from / on down. By specifying the rootdir entry, the RSCD agent sets the "root" directory to <dirname> by making a call to, or emulating, chroot(2). Clients can then see files and directories from dirname on down.

For more information about the implications and further requirements of this option, see Using users.local to specify an alternative root directory.

rsu=<user1[:user2 ...]>

The client command rsu allows a client to get alternate remote permissions on the agent. By default the client is challenged for the respective user's password but with the -p option no password is requested. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. If the client tries to use the rsu command with the -p option (that is, no password challenge) and then tries to switch to a user not in the list, access is denied.

rw

The named user has read/write access.

validuser

This entry tells the daemon that the user name/UID/GID combination of the remote (incoming) user must match a user name/UID/GID combination on the local host.

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 BMC 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.

Notes

  • When the rootdir option is no longer required, you can undo the corresponding setup by deleting the copied directories and un-mounting the mounted file systems or directories in the file system root.
  • The rootdir option is not supported on Windows platform and can only be used on Linux and UNIX platforms.

Back to top

Was this page helpful? Yes No Submitting... Thank you

Comments