Automation principals and server management

When using TrueSight Server Automation to perform actions on a managed server, you must be granted privileges to act on that server. The approach for granting these privileges varies between Microsoft Windows and UNIX servers.

• On Windows servers, you can use two possible approaches:
  • Windows user mapping — The operating system on a managed Windows server can recognize the identity encapsulated in an automation principal. When TrueSight Server Automation performs an action on a managed server, the system can map one or more roles to an automation principal, in effect mapping those roles to the identity defined in the automation principal.
  • User privilege mapping — Users are granted permissions on managed servers through the TrueSight Server Automation configuration files. For more information, see Impersonation-and-privilege-mapping.
• On UNIX servers, the RSCD agent uses a setuid command to fully impersonate a user on the managed server.

To set up UNIX user impersonation or Windows user privilege mapping, you must use the TrueSight Server Automation configuration files (exports, users, and users.local) on each managed server. For information, see Setting-up-configuration-files.

To set up Windows user mapping, you must define an automation principal in RBAC and associate it with one or more roles. Then you must associate the automation principal with a role. For more information, see Creating-automation-principals.

Considerations for using automation principals

• Only Windows servers running TrueSight Server Automation 8.0 or later can recognize automation principals.

• To use automation principals, ensure that the tunneling mechanism, which can be used by the NSH proxy for communication with clients, is turned off. If necessary, use the

  EnableProxyTunneling

  blasadmin parameter to turn off the tunneling mechanism.

• The Automation Principal user password is stored in the TrueSight Server Automation database using AES 128 bit encryption.

• Deploy Jobs and File Deploy Jobs that include repeaters can only use Windows user mapping when communicating with the repeater or a target server. When the repeater communicates with targets running Windows, communication must be based on user privilege mapping. The following table details how Deploy and File Deploy Jobs can use automation principals during indirect deployments.

  Step during job	Use automation principal?
  Application Server initiates communication with agent on target server.	Yes
  Application Server copies payload to repeater.	Yes
  Repeater copies payload to agent. Note: Because automation principals cannot be used during this step, Deploy and File Deploy Jobs must rely on user privilege mapping to copy payloads to target servers running Windows. In this situation, you should not disable user privilege mapping on the agent. Also, you should not remove the BladelogicRSCD user from the agent.	No
  Agent deploys software on target server.	Yes