Considerations for automation principals and Windows user mapping

When an operation is performed on a remote system, it must be performed within a security context in the OS of the remote system. On UNIX systems, the security context is established by having the remote process invoke the identity of a particular user (by performing a setuid() system call). On Microsoft Windows systems, a more complex mechanism is required because Windows does not support an equivalent to the setuid() call.

When a server is initially added and registered on the TrueSight Server Automation Application Server, remote processes run as the BladeLogicRSCD local user (or, in a domain controller environment, the BladeLogicRSCDDC domain user). This user obtains group privileges from a local user specified in the agent configuration files through a mechanism called user privilege mapping (UPM). For more information about the UPM mechanism, see Impersonation-and-privilege-mapping.

As an alternative to the UPM mechanism, you can use automation principals to establish the security context for operations performed on a remote Windows target. An automation principal is a set of Windows credentials (user name, password, and optional domain name) that can be associated either to a TrueSight Server Automation role or, by a system property, to a remote server. For information about creating automation principals, see Creating-automation-principals.

When a TrueSight Server Automation operation is invoked using an automation principal, a process is started by the RSCD agent and this process is given the automation principal credentials. The spawned process runs with the identity and privileges of the automation principal user, not the BladeLogicRSCD user.

Advantages of Windows automation principals

When comparing the use of Windows automation principals to the use of the UPM mechanism, Windows automation principals have the following advantages:

  • An automation principal enables you to specify a user account for logging on to the remote system, while the UPM mechanism obtains only the group privileges of a user.
  • Automation principals support the use of domain accounts for mapping of roles, while the UPM mechanism does not support domain accounts.
  • Automation principals load part of the user profile and can therefore be used to install or deploy software packages that the UPM mechanism might find challenging, such as SQL Server packages.
  • Automation principals allow access to network resources such as network shared drives (although mapped drives are still not visible in Live Browse under the File System node). UPM, on the other hand, does not usually grant access to network resources.

Limitations in the use of Windows automation principals

Using Windows automation principals in the TrueSight Server Automation environment has the following limitations:

  • Although automation principals allow a remote operation to be performed with a given user's identity, the fact that the spawned process is not an interactive one means that any mapped drives remain unavailable to the spawned process. It is frequently possible to use Universal Naming Convention (UNC) paths to name a remote disk directly, without relying on mapped drives. This workaround is hampered somewhat by the fact that TrueSight Server Automation NSH does not support UNC path syntax. However, UNC paths can be used in .BAT files and nexec commands.
  • The Windows user whose credentials are carried in an automation principal must have "Log on as a batch job" privilege for successful use of the automation principal. This privilege is not normally among those applied to a new user account, so you must explicitly add it.
  • Retrieval of the credentials defined in the automation principal requires a database lookup.

  • Use of an automation principal requires an NSH proxy connected to the TrueSight Server Automation database. NSH operations that do not pass through an NSH proxy cannot use automation principals.

    This means that for NSH Script Jobs, File Deploy Jobs, Pre/Post commands for Deploy Jobs, in order to pickup the Automation Principal credentials, the NSH client on the Application Server running the Job must be configured to use a NSH Proxy.

    In addition, the following types of NSH proxy setups cannot use automation principals:

    • A "standalone" NSH proxy, that is, an NSH proxy without access to the TrueSight Server Automation database. Such an NSH proxy cannot retrieve the credentials from the database.

    • An NSH proxy that uses tunneling for communication with clients. If necessary, use the

      EnableProxyTunneling
      blasadmin parameter to turn off the tunneling mechanism.

  • When you are using Agent Installer Jobs for upgrading RSCD agents and those jobs are using Automation Principals to communicate to the targets, you must use an NSH Proxy.
  • TrueSight Server Automation Repeaters cannot be used with automation principals, because the repeater must contact the target agent without benefit of access to the TrueSight Server Automation database.
  • Use of Automation Principals is supported only by TrueSight Server Automation RSCD agents of version 8.0 or later.
  • The "Add a Server" operation contacts a remote server to obtain some simple initial items of information. This task does not support the use of automation principals.
  • When it cannot use automation principals, TrueSight Server Automation fuses the usual BladeLogicRSCD user and mapped privileges to perform a particular task. When these privileges are successful, the only way to tell whether an automation principal was used is by examining the agent or Application Server log files.

Discontinuing the use of the BladeLogicRSCD user

In some environments, creating and managing a local user account such as BladeLogicRSCD is an administrative challenge because an organization-wide security policy might prohibit local user accounts. In these environments, BMC recommends the use of automation principals, and you can remove the BladeLogicRSCD account after the initial registration of the RSCD agent on the TrueSight Server Automation Application Server.

The following table discusses the prerequisites of removing the BladeLogicRSCD user.

Requirement

Details

TrueSight Server Automation version

To remove the BladeLogicRSCD local account, you must have TrueSight Server Automation version 8.1 or later installed.

On any earlier version of BMC Server automation, the BladeLogicRSCD local account is still required, even if it is unused. Furthermore, even if you remove this account, it is recreated automatically the next time that a connection is established with the RSCD agent.

TrueSight Server Automation architecture

You can remove the BladeLogicRSCD local account from remote servers.

However, do not remove this local user account from the file server. Correct operation of the TrueSight Server Automation infrastructure requires user privilege mapping for file servers.

When to remove

To remove the BladeLogicRSCD local account, wait until after the server has been added and registered on the TrueSight Server Automation Application Server.

The BladeLogicRSCD account and User Privilege Mapping (UPM) must be enabled when the system is first registered with the TrueSight Server Automation Application Server. The first call to the RSCD agent is made without knowing what OS the agent is running on. UPM is an agent-side functionality, so to invoke, that server does not need to know the OS, but the agent does need to know. The automation principal, on the other hand, is a functionality on the Application Server side, and the decision whether to use an automation principal to access an agent is made at the server side. One of the things needed to make that decision is the OS of the machine that the agent is running on, and that property is set only after the first call to the agent is successful. If UPM is disabled before the first call, there is no way to access that agent and hence no way to get the information about the OS to enable the server to make the decision of using an automation principal.

To remove the BladeLogicRSCD user

After the server has been added, run the chapw -d command on the remote system. To run the chapw -d command, you must connect to the agent by means of a Network Shell Proxy Server. Use the blcred command to log on, and select a role that has an automation principal associated with it.

Note

When the chapw -d command is run against an Active Directory domain controller, the BladeLogicRSCDDC account is not deleted (whereas against a member or standalone server, the chapw -d command does delete the account). You should run the chapw -d command against all domain controllers in the domain, and you can then manually delete the BladeLogicRSCDDC account from the domain. In this manner, you prevent the chapw -d command from running against a single domain controller and having it delete an account that other domain controllers are using.

To re-enable the use of the BladeLogicRSCD user

Run the chapw -e command in a similar manner to the way that you ran the chapw -d command. In particular, ensure that the role that you choose for running the command has an automation principal associated with it.

Permissions for the local or domain account

When considering what local or domain account to use for the User Principal Mapping or Automation Principal (respectively), you should consider the actions that the account will need to perform on the target systems. The account used must have the Operating System level permissions and rights to perform those actions. For example, if installing a piece of software is required to run as root, then the RBAC Role in TrueSight Server Automation must be mapped to root. Similarly, if the installation of a patch requires certain rights on Windows, the local or domain account must have such rights or permissions. For example, Microsoft has documented what rights are required to install patches, so the local or domain account would need those rights, and, as mentioned above for Windows, the BladeLogicRSCD user must not have an explicit Deny permission for any of those rights, if the UPM is in use.  Beyond this guidance, your system administrator should determine what rights are required for any particular action and ensure that the local or domain account used by TrueSight Server Automation has the correct rights or permissions.

 

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