How BMC Server Automation grants access to RSCD agents

When a client contacts an RSCD agent, BMC Server Automation uses the following algorithm to determine whether a user has permissions for accessing the agent:

1. Every client installation (on Windows there can be multiple clients) and the RSCD agent each have their own securefile.
   • First, the client reads its secure file to determine whether it includes an entry for a particular server.
   • If an entry for that server exists, the client uses the information in the entry to establish a connection with the server.
   • Then, the RSCD agent on the server reads its secure file to determine if it has an entry for the incoming client.
   • If there is no entry for that client in the secure file of the server, access to the agent is denied.
   • If there is an entry and the communication parameters in the secure file on the server match those in the secure file on the client, a connection is established.
     Depending on the type of authentication and encryption specified in the secure file, additional measures might be required before a connection can be successfully established between clients and servers. For a description of how to set up communication security for a BMC Server Automation system, see Administering security. For more information about using on the secure file, see Secure file overview.
2. Assuming the conditions described below are satisfied, if you are using Windows user mapping, the incoming role is granted the permissions of a local or domain user on the server and the process if complete. If any of the following conditions are not satisfied, the algorithm continues to step 3.
   • The agent being contacted must be running on a Windows server.
   • The agent being contacted must be running on a server that has already been added to the BMC Server Automation system.
   • The agent must be running BMC Server Automation 8.1 or later.
   • A Network Shell client must be communicating through a Network Shell proxy server. To take advantage of Windows user mapping, Network Shell cannot contact an agent directly or communicate through a stand-alone Network Shell proxy server.
   • Any job acting on a target server must be running in an Application Server environment that meets the following criteria:
     • The Application Server must be running a Network Shell Proxy Service or the ProxyServiceURL value in the Application Server profile must point to a valid Network Shell proxy server.
     • The secure file on the Application Server must be defined so the appserver_protocol option is set to ssoproxy.
3. After a connection is established between the client and server, the system checks the exports configuration file, where the user= field can map users connecting from specified machines to a particular user on the server. For example, with the user= field, you can map users to root on UNIX systems or Administrator on Windows.
   On Windows, incoming users can only be mapped to local users. On Windows domain controllers, however, all users are domain users and therefore the mapping will be to a domain user, and the syntax of the mapping entry remains the same: map=WindowsUser and not map=domain\WindowsUser.
   If a role is mapped to a Windows user through an automation principal, the exports file produces no user mapping. For more about the exports file, see Exports file overview.
4. The system checks the users.local and users configuration files to determine if these files include any map= entries that supersede definitions set in the exports file. Using the map= field, you can map a user on a client to a user on a server. Typically, the users file is used to implement the permissions that are defined and granted to users on a system-wide basis through RBAC Management. The users.local file is used for granting user permissions on a per-agent basis rather than granting system-wide user privileges. If the same users have entries in both users.local and users, entries in the users.local file take precedence.
   If a role is mapped to a Windows user through an automation principal, the users.local and users files produce no user mapping. For more on the users and users.local files, see Users and users.local files overview.
5. If there is no user mapping defined in the exports, users.local, or users files, the system attempts to match the user ID of the incoming user to a user ID defined on the server where the RSCD agent is installed. If there is a match, the user is assigned that user's permissions.
   Note that, by default, user "root" on a UNIX client is not allowed to map to its equivalent user "root" on a UNIX server. Similarly, on Windows, any client user found to be a member of the Administrators group cannot be mapped by default to an equivalent user on the server.
6. If none of the previous steps succeed, the system maps the incoming user to a default user. On UNIX systems, users are granted the permissions of user "nobody." On Windows systems, if the role is not mapped to an automation principal, users are granted the permissions of user "Anonymous."
   • On UNIX, users coming in as root are, by default, mapped to nobody unless a corresponding entry for the root= field is found. If a root= field is found, then root equivalence is allowed. Similarly, on Windows, if an incoming user is not mapped to an automation principal and that user is a member of the Administrators group, then that user is, by default, mapped to Anonymous unless a corresponding entry for the root= field is found.
     In UNIX systems, you can use the anon= field to specify how to deal with anonymous users, including rejecting them with anon=-1. The anon= field is not supported for Windows. Also, on Windows, be aware that the validusers= option is treated the same as the allowed= option.
   • On Windows, if you are not using Windows user mapping, a mapping exists in the exports or users file, and the user that is being mapped to does not exist, access to the agent is denied. For example, if an entry in the users file says
     betty map=WindowsUser
     then any user named betty that tries to make a connection to this machine is mapped to the local user named WindowsUser. If there is no user named WindowsUser, access is denied.