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:
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:
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:
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.
Solaris, Linux, AIX, HP-UX
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.
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.
For Network Shell users that are not communicating with servers through a Network Shell proxy server:
Below is a sample users file with entries for
DBAdmins:betty. In this example,
DBAdmins is the role and
betty are users. Below these entries, two more entries grant
betty access to this server using Network Shell. In these entries
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: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.
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:
BMC recommends adding an entry for
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.
The users and users.local files provide the following options that you can use to assign access permissions to users:
This is a list of colon (:) separated commands that the user is allowed to execute on the local host. If no
(UNIX only.) This entry tells the RSCD agent that an account with the same user name must exist on this host.
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
This entry forces incoming client connections to run with the permissions of
(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.
(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
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
The named user has read-only access.
(Linux and UNIX only) By default, the RSCD agent allows the client to "see" the complete directory tree from / on down. By specifying the
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
The named user has read/write access.
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.
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.
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.
The following example in the users.local file grants read/write access to user1 and user2 and forbids access to all other users.
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:
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.