Impersonation and privilege mapping

BMC Server Automation provides several mechanisms to enable a user to assume an effective user identity and a set of user permissions on remote servers:

• (UNIX) — The agent fully impersonates a user through a call to the setuid command.
  For this reason, the agent must run as root (which is the default) so that connections can be mapped to the appropriate user defined in the exports, users, and users.local files.
• (Windows)— Two techniques are available for assuming an effective identify:
  • Windows User Mapping — Maps a role to a local or domain user on the server so the role is granted the user's privileges. To set up Windows user mapping, you must define an automation principal, which defines a user credential that can be used to access an external system.

  • User Privilege Mapping (UPM) — Allows the agent to temporarily grant the local user's group privileges to an unprivileged user account called BladeLogicRSCD. This privilege mapping mechanism allows the agent to acquire the mapped local user's group privileges without having to access that user's Windows credentials (user name and password). In this way BMC Server Automation takes advantage of the access control mechanisms provided by the remote server's operating system.

    Note

    Windows Domain Controllers have no local users. To set up user privilege mapping on Windows Domain Controllers, map users to a member of a first-level group, such as BuiltIn\Administrators. The mapped user cannot receive administrative privileges via a group within another group. For example, if the mapped account is in Domain Admins and Domain Admins is in BuiltIn\Administrators, the mapping will not work. The default UPM mapping cannot traverse multiple groups.

    Normally, the RSCD agent on a Windows host runs as the SYSTEM user, with administrator-level privileges. When a client — that is an Application Server, Network Shell proxy server, or Network Shell client — contacts an RSCD agent on a remote server, the RSCD agent takes the following series of actions:

    1. Starts a new process running as the unprivileged local user, BladeLogicRSCD. (This is possible because the agent knows the credentials for the BladeLogicRSCD user.)
    2. Checks for settings in the exports, user, and users.local configuration files that specify a local user context under which the client's commands should execute. (For details, see How BMC Server Automation grants access to RSCD agents.) 
    3. Uses a NetUserGetInfo API call to obtain detailed information about the local user specified in the configuration files, and temporarily acquires the group privileges that the managed server's operating system grants to this local user.  
    4. Assigns additional privilege tokens (group memberships, Group Policy Settings) to the spawned process based on the privilege tokens obtained from the mapped user.
       The spawned process runs with the BladeLogicRSCD identity, enhanced with the privileges equivalent to some other user (as specified in the agent configuration files). The spawned process does not run with the identity of the mapped user.

    Note

    • If the BladeLogicRSCD user is assigned to any Deny Local Security Policy settings, those denies will take precedence over any grants to the mapped user, and the effective privileges of the actions that the agent will take will include the denied settings.
    • The BladeLogicRSCD user should only be in the Deny Logon Locally and Logon as Batch Job User Privileges, and no other privileges, for the reason mentioned above.

If you are not using Windows user mapping and there is no user mapping defined in the exports, user, or users.local configuration files, the system attempts to match the user ID of the incoming user to a user ID defined on the managed server where the RSCD agent is installed. If there is a match, the user is assigned that user's permissions in the same manner as if there was explicit mapping — that is, on UNIX systems the agent fully impersonates the user through setuid. On Windows systems the agent performs user privilege mapping.

For example, if a user authenticates as "joe" and then begins to use Network Shell, the user takes on the privileges and permissions of the user "joe" on the target server. If user equivalency is not possible (that is, joe does not exist on the target server as a user), users are mapped to an underprivileged account (nobody on UNIX or Anonymous on Windows).

For more information about impersonation and privilege mapping, see Setting up configuration files.