When you are using the console, the BMC Server Automation Application Server enforces all authorizations defined for roles and system objects.
If a role does not have at least Read authorization for an object (at both the role level and the object level), the Application Server denies access to the object. A role must have additional authorizations to perform other actions on an object, such as executing a job or modifying a server.
For servers, an additional layer of access control is available. This enforcement mechanism employs configuration files on the agent. With these configuration files, you can restrict all incoming connections to the agent, whether those connections originate in the BMC Server Automation Console, Network Shell, or the BLCLI. When using configuration files, you can manage access at the agent level by running ACL Push Jobs (see Creating or modifying ACL Push Jobs). This job uses the authorizations specified for all roles granted access to a server and generates entries in an access control list for that server. The ACL Push Job then copies that access control list (ACL) to the server's agent. On the agent this ACL is called the users configuration file. For more information about how BMC Server Automation converts role information into entries in a users configuration file, see Controlling server access with agent ACLs.
For Microsoft Windows servers, you can optionally control access using an alternative approach to configuration files: Windows user mapping. In this approach, you define an automation principal who maps to a local or domain user on a Windows server. Then you can associate the automation principal with a role. When that role accesses the Windows server, the role is granted the permissions of the local or domain user.
Agent ACLs can define other types of connection characteristics besides user mapping. Because of that, you should run Agent ACL Push Jobs on servers when you add or modify user or role information, even if you have set up Windows user mapping on those servers. For more information about Windows user mapping, see Creating automation principals.