Configuring 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 user.local files that begin with # are considered to be comments.

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.