Skip to main content

Onboarding an account

Users assigned as Account Trustees can use the Account: Onboard request to onboard an account to a team.

Click below to view a demonstration of onboarding a Windows account to a team.

Click below to view a demonstration of onboarding a Linux account to a team.

To onboard an account to a team:

  1. From the home page, click Manage resources.

  2. Click Account: Onboard.

  3. Select a managed account.

    3424.png

    Click Next .

  4. Select the:

    • Managed System Policy ID The ID of the policy used to manage the account

    • Disclosure option Select the appropriate checkboxes for the disclosure methods by which the team can access the account.

    • Maximum Concurrent Checkout The number of concurrent checkouts for the account. If unspecified, this is set to 1.

    3425.png

    Click Next .

  5. Select the Account Team that will access the account.

    Click Next .

  6. If the disclosure method was by direct connection, determine whether sessions will be monitored by:

    • Clipboard

    • Keystroke

    • Screen

    3426.png

    Click Next .

  7. Select the Users with 'credential manager' privilege can override and randomize the password checkbox if you want to allow users with the credential manager role to override and randomize checked-out passwords

    Passwords will always be randomized on check-in. This option provides the user with buttons to override or randomize on demand.

    3427.png
  8. Click Submit.

    Bravura Security Fabric notifies authorizers to review the request if required.

  9. Click the View request link at the top of the page to view the status of the request.

API automation for account onboard

Once the API has been configured (See ”SOAP API” in Bravura Security Fabric Remote API (api.pdf) and your script has been authenticated to the API (Login or LoginEx API calls), the WF API calls can be used to create an API request.

Use the WFPDRSubmit function to create a workflow request and submit the request for publishing.

When submitting a request, use ”ONBOARD_ACCOUNT” as the PDR ID. The request uses the following attributes:

attrkey

value

HOSTID

The ID of the system on which the account resides.

ACCOUNT

The ID of the account to be onboarded.

MSP_ID

The managed system policy the account will be binded to.

MA_TEAM

The team that the account will be assigned to.

REQUEST_TEAM

The team in which its account trustee(s) will be used to authorize the request. This value is required, but not enforced for this request.

See REQUEST_TEAM attribute for more information.

DISCLOSURE_METHOD_DIRECT

T to enable direct connection disclosures for the account, F to disable.

DISCLOSURE_METHOD_VIEW_COPY

T to enable display and copy disclosures for the account, F to disable.

SESSMON_KEYSTROKE

T to enable keystroke recording for direct connections, F to disable.

SESSMON_CLIPBOARD

T to enable clipboard recording for direct connections, F to disable.

SESSMON_SCREENSHOT

T to enable screen recording for direct connections, F to disable.

MA_PWD_OVERRIDE

T to allow credential managers to randomize or override account during check-out, F to disallow.

MA_RES_CHECKOUT_LIMIT

The number of concurrent checkouts for the account.

ACCOUNT and HOSTID attributes are required. Note that those are not automatically populated from SELECT_MA. This will be accomplished in a future version(s)

ONBOARD_ACCOUNT batch request sample

"ACCOUNT","HOSTID","MSP_ID","MA_TEAM","SESSMON_CLIPBOARD","SESSMON_KEYSTROKE","SESSMON_SCREENSHOT","MA_PWD_OVERRIDE","DISCLOSURE_METHOD_DIRECT","DISCLOSURE_METHOD_VIEW_COPY","MA_RES_CHECKOUT_LIMIT"
"account01","D39B55F07A6A487AABE4BD8C9EC1679C","ONBOARDED_ACCOUNTS","TEAM-000000","T","T","T","T","T","T","1"

The REQUEST_TEAM attribute is the team in which its system trustee(s) will be used to authorize the request. This can be a different value depending on which PDR is used. In some cases, the value is auto filled and in other cases, a value is not required.

PDR ID

API submittable

REQUEST_TEAM required

REQUEST_TEAM auto-filled

BATCH_REQUEST

No

N/A

N/A

CREATE_LARGE_CREDENTIAL

No

N/A

N/A

UPDATE_LARGE_CREDENTIAL

No

N/A

N/A

WEBAPP_DISCLOSURE_CREATE

No

N/A

N/A

WEBAPP_DISCLOSURE_DELETE

Yes

No

N/A

WEBAPP_DISCLOSURE_UPDATE

No

N/A

N/A

TEAM-CREATE

Yes

Yes

Yes

TEAM-DELETE

Yes

Yes

Yes

TEAM-MEMBERS

Yes

Yes

Yes

TEAM-UPDATE

Yes

Yes

Yes

CREATE_VAULT_SYSTEM

Yes

Yes

Not required

ARCHIVE_VAULT_SYSTEM

Yes

Yes

Yes

UPDATE_VAULT_SYSTEM (1 - same team)

Yes

Yes

Yes

UPDATE_VAULT_SYSTEM (2 - transfer)

Yes

Yes

Yes

CREATE_VAULT_ACCOUNT (1 - team vault)

Yes

Yes

Yes

CREATE_VAULT_ACCOUNT (2 - system vault - same team)

Yes

Yes

Yes

CREATE_VAULT_ACCOUNT (3 - system vault - different team)

Yes

Yes

Yes image idm2004

ARCHIVE_VAULT_ACCOUNT

Yes

Yes

Yes

UPDATE_VAULT_ACCOUNT (1 - team vault)

Yes

Yes

Yes

UPDATE_VAULT_ACCOUNT (2 - system vault - same team)

Yes

Yes

Yes

UPDATE_VAULT_ACCOUNT (3 - system vault - transfer)

Yes

Yes

Yes image idm2004

ONBOARD_SYSTEM

Yes

Yes, but not enforced

No

ARCHIVE_ONBOARDED_SYSTEM

Yes

Yes, but not enforced

No

UPDATE_ONBOARDED_SYSTEM

Yes

No

If the destination team is unset or the destination team is the same as the source team

ONBOARD_ACCOUNT

Yes

Yes, but not enforced

No

OFFBOARD_ACCOUNT

Yes

Yes

Yes

UPDATE_ONBOARDED_ACCOUNT

Yes

Yes, but not enforced

No

CREATE_PAMUTIL_API_USER

Yes

No

Not required

image idm2004 improper display of the team in update/archive when the destination team's vault trustee is not in a team owning the vault system. This will be fixed in a future release.