Creating automation principals

You can create an automation principal, which defines a user credential that can be used for accessing external systems. Automation Principals are used primarily by agents to map access using a specific credential, most commonly a username and password, on an endpoint, instead of using the traditional impersonation method.

You can define an automation principal to access a server running any supported operating system. Some common uses for automation principals are:

  • Microsoft Windows user mapping — Map one or more RBAC roles to a local or domain user on a managed server.
  • Agent installation — Access servers where you want to run agent installations.
  • TrueSight Orchestration — Integrate Workflow Jobs with TrueSight Orchestration.
  • LDAP server access — Access an LDAP server such as an Active Directory server.

If your principal is used to map to an Active Directory account, the managed host must be a member of the appropriate Active Directory domain. Non-AD Automation Principals can use local authentication.

This procedure lets you map multiple roles to an automation principal. Alternatively, you can map a particular role to an automation principal (see Role-Agent-ACL). Rather than mapping automation principals to roles, you can accomplish the same mapping on a server-by-server basis using server properties. For information, see Using server properties to map automation principals for Windows user mapping.

You might need to create an automation principal that provides credentials for a superuser on UNIX systems. A superuser automation principal is the same as any other automation principal. It simply includes credentials for a superuser.

Note

Only servers running TrueSight Server Automation version 8.0 or later can recognize automation principals. Only Windows servers running TrueSight Server Automation version 8.0 or later can recognize automation principals used for Windows user mapping.

Automation principals cannot be used with repeaters.

Automation principals cannot be used if the NSH proxy uses tunneling for communication with clients. If necessary, use the

EnableProxyTunneling
blasadmin parameter to turn off the tunneling mechanism.

For information about modifying automation principals, see Modifying-automation-principals. For more general information about automation principals, see Considerations-for-automation-principals-and-Windows-user-mapping.

Before you begin

If you intend to use an Automation Principal for Windows user mapping, your Application Server must be configured to use a NSH Proxy server in order for jobs to use the Automation Principal when communicating with target servers.  For a detailed description of that configuration, see Setting-up-a-Network-Shell-proxy-server.

To create an automation principal

  1. Log on to TrueSight Server Automation Console using your BLAdmins or RBAC Admin credentials. You can create an Automation Principal with any role that has permissions to create Automation Principals.
  2. For more information, see RBACAdmin-and-BLAdmin-users.
  3. In the RBAC Manager folder, select Automation Principals.
  4. Create a new automation principal by right-clicking and selecting New > Automation Principal from the pop-up menu. The Automation Principal Creation wizard appears.
  5. Provide information for the automation principal as described in the following topics:
  6. To close the wizard and save your changes, click Finish at any time.

Note

Alternatively, you can create a new automation principal by copying an existing automation principal and pasting it into the Automation Principals node. The password of the original automation principal is not copied into the new automation principal, so you must set the password while editing the new automation principal.

Where to go next

Automation-principal-General

 

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