Impersonation and privilege mapping

TrueSight Server Automation uses different 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.

    Important

    The users that are mapped via the RSCD agent use the limits set for the user that runs the RSCD process (which is typically root). For example, when you run the following command, the process resource limits are inherited from the RSCD process.
    nexec -i <target> bash

  • (Windows)— Three techniques are available. The first two techniques are available for assuming an effective identity and the third technique can be used when you do not want to use user impersonation.
    • 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 (typically a domain user) that is used to access the managed server.

    • User Privilege Mapping (UPM) — Allows the agent to temporarily grant a 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 TrueSight Server Automation takes advantage of the access control mechanisms provided by the remote server's operating system.  In this method the RSCD Windows Service will start as the LocalSystem account and then drop privileges to the BladeLogicRSCD to listen for incoming connections.  

      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 TrueSight 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.
      • In a domain controller environment, this user account is named BladeLogicRSCDDC.
      • The password for the BladeLogicRSCD user account is set to never expire. This setting ensures that the Agent is always up and running and prevents situations where it fails due to expired password. Whenever a connection is made to the Agent, the setting is validated. If a change is detected, it is restored to never expire.
    • NEW IN 23.4 SYSTEM User Only Mapping — Maps all the configured or permitted roles/users to the SYSTEM user on the server. The RSCD agent on a Windows host runs as the SYSTEM user, with administrator-level privileges. This user mapping is useful when your organization-wide security policy prohibits user impersonation. In such cases, the Windows User Mapping or User Privilege Mapping (UPM) techniques cannot be used. Note the following points when you use SYSTEM User Only mapping:
      • The unprivileged user account for BladeLogicRSCD or BladeLogicRSCDDC (domain controller environment) is not created, as it is not utilized.
      • When SYSTEM User Only mapping is enabled on the server, the Windows User Mapping and User Privilege Mapping (UPM) are ignored.
      • All configuration settings in the exports, users, and users.local files are enforced, except for user mapping (for example, map= or user=).
      • The RSCD Agent log indicates the Agent is configured to have SYSTEM user only:
        image-2023-8-25_13-55-43.png
      • The agentinfo command, which reveals the impersonation user, will indicate that the processes are executed under the SYSTEM account.
        image-2023-8-22_18-35-12.png

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.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*