Controlling server access with agent ACLs
This topic discusses how you can use agent access control lists (ACLs) to control access to a server. It includes the following sections:
Understanding server access
When you define permissions for a server, you are controlling access to the server within the TrueSight Server Automation system. The TrueSight Server Automation Application Server enforces these permissions. However, you can also manage servers using Network Shell and the BLCLI. To completely control access to a server, you must modify configuration files on each server's RSCD agent. If you are using Microsoft Windows user mapping to grant user permissions on Windows servers, see Windows user mapping and agent ACLs.
Several methods exist to control access using agent configuration files. For detailed information about creating the configuration files, see Setting-up-configuration-files.
Typically, you control agent access by letting TrueSight Server Automation automatically translate the permissions you have defined for a server in the TrueSight Server Automation Console into a users configuration file on the agent. You accomplish this by running an ACL Push Job on a server, which overwrites the users file for that server's RSCD agent (see Creating-or-modifying-ACL-Push-Jobs). Before you push agent ACLs to a server by running the ACL Push Job, you can preview the entries to be created in the users file (see Previewing and pushing agent ACLs). When you define permissions for a server while adding the server, you can also preview agent ACLs (see Add-New-Server-Permissions). After you have pushed ACLs, the users file settings control all incoming connections to that agent.
When TrueSight Server Automation generates entries for a users file, it creates an entry for each user associated with each role that has access to the server. TrueSight Server Automation does not generate an entry for disabled users. An entry is formed by pairing a role and a user using the format role:user. In the example users file shown below, DBAdmins is the role and george and betty are users assigned to the DBAdmins role.
In addition to generating role:user entries, TrueSight Server Automation also creates another type of users file entry for Network Shell users. Because Network Shell does not recognize roles, the RBAC Manager folder asks you specify a role that functions as the default Network Shell role for each user (see User-Role-Selection). Using this information, TrueSight Server Automation generates a users file entry that does not include role information for each user. A users file entry is not generated for disabled users.
For example, in the users file shown above, the users george and betty have their default Network Shell role set to DBAdmins. In addition to the role:user entries for george and betty, TrueSight Server Automation generates entries for george and betty that are not paired with any role but are based on the same information as the DBAdmins role. These entries are default Network Shell roles, and they let george and betty access the server using Network Shell.
The users file that TrueSight Server Automation pushes to an agent 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. TrueSight Server Automation places a nouser entry in the users file of a particular server if the server property called PUSH_ACL_NO_USERS_FLAG is set to true.
Administrators can create a users.local file on agents to create a set of user permissions that are more fine-grained than is possible with the users file entries that TrueSight Server Automation automatically generates. For example, with RBAC you cannot specify some users as read only and others as read/write, but you can easily accomplish that by manually editing the users.local file. The RSCD agent reads the users.local file before it reads the users file, and the users.local settings supersede any corresponding settings in the users file. If the users file includes entries that are not superseded, those entries still apply.
Windows user mapping and agent ACLs
If you are granting user permissions on Windows servers through Windows user mapping, all permissions on the server are derived from the local or domain user to which a role is mapped.
However, configuration files on a managed server can control other capabilities besides user permissions. Because of that, when you change role or user information, you should always run an ACL Push Job, even to servers where you are using Windows user mapping.
Previewing and pushing agent ACLs
You can preview agent access control lists (ACLs) before pushing them to a server.
You can view the ACLs that TrueSight Server Automation will write into a users configuration file on the agent of a remote server when you run an ACL Push Job on that server (see Creating-or-modifying-ACL-Push-Jobs).
After you preview ACLs, this procedure gives you the option of pushing ACLs immediately to the server. This option provides a quick alternative to pushing agent ACLs by launching an ACL Push Job.
To preview and push agent ACLs
- In the Servers folder, select a server.
- Right-click and select Administration Task > Agent ACLs from the pop-up menu.
A window displays the entries that appear in the users file on that server after you push ACLs to the server. - Do one of the following:
- To push ACLs to the selected server without running an ACL Push Job, click Push. A dialog box asks you to confirm. Click OK. A progress bar shows the progress of the ACL push. A dialog box announces that the push was successful, or it lists any failures.
- To create an ACL Push Job to push the ACLs you are previewing to a server, click Schedule Job. The New ACL Push Job wizard opens. For information about using this wizard, see Creating-or-modifying-ACL-Push-Jobs.
- To close the window, click Cancel.