Manage Credentials Between Applications (A2A)

The A2A (Application to Application) feature lets you manage credential requests from automated request servers.
The A2A (Application to Application) feature lets you manage credential requests from automated request servers. After Credential Manager provides the password, the request server submits them to access the target.
Request scripts
are applications that require credentials for target accounts on password management target devices. These scripts request the managed credentials by way of the A2A Client, which runs on a request server. This request server is treated like a target server but is an A2A device type.
The A2A feature uses an A2A Client that you install on a host in the customer environment. The A2A Client then has to integrate with the appliance.
This topic describes the following tasks:
A2A Terminology
The following terms are specific to A2A configurations:
  • Request Server:
    A host server where the requestor application resides and where you install the A2A Client.
  • A2A Client:
    A program that is installed on the request server. The A2A is the intermediary that communicates between the requestors and
  • Requestor:
    A program or script that requests credentials that are stored as part of an A2A target account at
    . To obtain credentials, the requestor communicates to the A2A Client, which then fetches the credentials from
    . When
    receives the credential request, it evaluates attributes of the request server, the requesting program/script, and the user executing the requesting program. If authorized,
    sends the credentials to the requestor. A requester can use credentials for any task that requires credentials, such as opening connections to databases.
  • Target Alias:
    A unique name that identifies an A2A target account. An A2A target account might have multiple aliases.
  • Authorization Mapping:
    A mapping defines which requesting application or scripts can access which target accounts. Mappings implement A2A security.
Configuration Overview
This section provides a high-level overview of the process to configure A2A credential management:
You do not have to complete the A2A tasks in any specific order. The only exception is for A2A deployments on an AWS AMI in an Amazon Virtual Private Cloud.
  1. Add target devices that host target accounts for use by request servers. These targets use the device type Privileged Management.
  2. Install the A2A Client on a remote host.
  3. Use the PAM UI to register the A2A Client with a PAM server or a site VIP in a clustered environment.
    1. Add the A2A Client as an A2A device.
    2. Activate the Device.
  4. Integrate the A2A request scripts on the A2A Client host
  5. Use the UI and integrate the request server with the appliance server:
    1. Specify the A2A request scripts
    2. Specify authorization mappings
Configure A2A for High-Availability in Multisite Clustered Environments
You can configure your A2A implementation to provide varying levels of availability in a multisite clustered environment by configuring the PAM nodes at which sites to which each request server can connect. The more PAM nodes to which a request server can connect, the higher the availability.
For example, for maximum A2A availability, can configure your environment so that all request servers can connect to every PAM node in your cluster. Another example is to configure your environment so that each request server at a site can connect to every PAM node at its local site and the primary site.
High-Availability vs. Security and Performance
Because higher availability configurations require more connections between request servers and PAM nodes, some at remote sites, there is a corresponding impact on network security and performance. Configuring network and server firewall rules to allow the associated connections affects network security. The additional network traffic affects network performance. You must therefore consider these tradeoffs when determining your availability strategy.
At a minimum, we recommend that you configure each request server to be able connect to all the PAM nodes at its site by taking the following actions:
  • Register all request servers with their local site VIP rather than with an individual PAM node.
  • Configure your network and firewall rules to provide all PAM nodes at a site with a clear network path to all local request servers.
The previous configuration is considered the default solution and described in all associated procedures in this documentation.
Identify Targets Using Target Aliases
To manage A2A passwords, assign one or more target aliases for each target account. A target alias is a unique name that links a target server, a target application on that server, and a target account for that application. A script that is integrated with Credential Manager, uses the alias to retrieve the target account credentials from the database. The credentials enable access to the target system. With a target alias defined, target credentials are not hard-coded into scripts, allowing Credential Manager to handle password changes automatically.
The following figure shows the hierarchical structure of target accounts.
Target Aliases for A2A Communication
target aliases for A2A communication
Requesting programs also identify a target account by specifying a target alias. Target aliases are global to the appliance. The aliases differ from target account names because target names can be duplicated on many hosts. An example of a duplicated name is the root account on UNIX systems.
Target aliases and groups are also used in authorization mappings.
Specifying a target alias is identical to the target alias specified by the requesting program.
If the mapping is to a target group, all accounts in the group represent the target. Grouping targets lets the requesting program/script obtain the target aliases for each target account without you configuring multiple mappings. Target groups are the most scalable way of specifying targets. However, some requesting programs might get credentials for target accounts that are not needed. To prevent this issue, configure mappings to individual aliases or set up target groups with the smallest scope possible.