Vault-ConjurIntegration - CyberArk Docs€¦ · 3 InternalandConfidential CyberArk...

Vault-Conjur Integration

Version 10.8

Copyright © 1999-2019 CyberArk Software Ltd. All rights reserved..This document contains information and ideas, which are proprietary to CyberArkSoftware Ltd. No part of this publicationmay be reproduced, stored in a retrieval system,or transmitted, in any form or by anymeans, electronic, mechanical, photocopying,recording, scanning, or otherwise, without the prior written permission of CyberArkSoftware Ltd.

CS-010-8-0 7-1-2019

Table of Contents

Vault Conjur Synchronizer 3Solution benefits 3How does it work? 4Synchronizer Flow 4System requirements 6Hardware requirements 6Licensing 6Audits 6Synchronizer Installation 7Configuration 12Vault Disaster Recovery 18Run Synchronizer 19Line of Business (LOB) 19Conjur Policies 23Accounts and Safes 32Prepare the Vault environment for dual account support 35Rotational group platform configuration 36Configure the object’s platform for dual account support 38Configure accounts and groups for dual accounts support 38Set the index of the group object 39Upgrade 43Uninstall Synchronizer 43Limitations 44Logs 45Troubleshooting 46Prior Releases 49

2 Table of Contents

CyberArk

3

Internal and ConfidentialCyberArk

Vault Conjur SynchronizerVault Conjur Synchronizer 10.8 supports Conjur Enterprise v.5x

Note:This section contains documentation for Vault Conjur Synchronizer 10.8. Fordocumentation of prior versions, see Prior Releases, page 49.

CyberArk's Digital Enterprise Password Vault ® (EPV) integration with Conjur expandsthe CyberArk Privileged Access Security to the DevOps space and tomodern anddynamic environments. Secrets that are stored andmanaged in the CyberArk Vault cannow be shared with Conjur and used via its clients, APIs and SDKs to enhance securityand reduce risks for the DevOps environments, including CI/CD pipeline, containerizedapplications, and cloud platforms.

The integration between the Enterprise Password Vault ® (EPV) and Conjur providesSecurity, IT, and DevOps teamswith a common platform to enforce privileged accesssecurity policies on all platforms - On Premise/Cloud/DevOps - to form a consistent,unified enterprise-wide PAS Program.

Solution benefitsCyberArk's Digital Enterprise Password Vault ® (EPV) integration with Conjur providesthe following benefits:

EnablesCyberArk customerswho store andmanage their secrets in the EnterprisePassword Vault ® (EPV) to benefit fromConjur's capabilities to provide secrets in

dynamic and ephemeral environments and containers.

Enable central policy enforcement for DevOps use cases, such as rotation,monitoring, and auditing.

How does it work?

1. Vault Admin creates LOB users and grants them ownership to specific safes. TheseLOBs facilitate the syncing of accounts to Conjur.

2. The CyberArk Vault-Conjur Synchronizer service (Synchronizer) retrieves theaccounts for these LOBs.

3. The Synchronizer generates a Conjur policy for these LOBs that contains the secretsdefined as variables, and loads them to Conjur.

4. The Synchronizer syncs the accounts to Conjur asConjur variables.

5. The Conjur Admin creates and loads a Conjur policy that delegates users and hostspermissions to the variables.

During each sync interval, the Synchronizer repeats step 2 and, if needed, steps 3and 4.

Synchronizer FlowThe Synchronizer syncs secrets from accounts in the root folder of safes that are ownedby the LOB user.

The Synchronizer supportsmost account types. To learnmore about single and dualaccounts, see Accounts and Safes, page 32.

Note:Accounts used on Service Account platforms are not synced.

In each sync interval the following steps are taken:

1. The Synchronizer user retrieves all LOB User accounts from the ConjurSync safe.

If there is a new LOB, generate the policy and load it to Conjur.


Vault-Conjur Integration 4

Each Vault account is represented in Conjur by the following variables:

Variable Required

password Yes

username No

For example:

Account Variable representation

Single account(Vault_Name/Safe1/Root/Account1)

Variable name: Vault_Name/lob_name/Safe1/Account1/usernameHas the following annotations:cyberark-vault: truecyberark-vault/accounts: Vault_Name/Safe1/Account1Variable name: Vault_Name/lob_name/Safe1/Account1/passwordHas the following annotations:cyberark-vault: truecyberark-vault/accounts: Vault_Name/Safe1/Account1

Dual account(Vault_Name/Safe1/Root/Account1,Vault_Name/Safe1/Root/Account2)

Variable name: Vault_Name/lob_name/Safe1/virtual_user_name/usernameHas following annotations:cyberark-vault: truecyberark-vault/accounts: Vault_

Name/Safe1/Account1, Vault_Name/Safe1/Account2cyberark-vault/dual-account: true

Variable name: Vault_Name/lob_name/Safe1/virtual_user_name/passwordHas following annotations:cyberark-vault: truecyberark-vault/accounts: Vault_

Name/Safe1/Account1, Vault_Name/Safe1/Account2cyberark-vault/dual-account: true

Non-CPMmanaged account Same as single account

Note:In a Dual account, the virtual_user_name of the Dual Account group must be uniqueper safe. For example, if a user has two Unix environments with Dual Accountconfigured, then the two environments cannot have the same virtual_user_name.

2. The Synchronizer runs in intervals as defined in theVaultConjurSynchronizer.exe.config file in the SYNC_INTERVAL_TIME parameter.This process syncs the LOB owned safeswith Conjur. The default value for SYNC_


Vault Conjur Synchronizer5

INTERVAL_TIME is 300 seconds (5minutes).

If the syncing process for this LOB takes longer than the SYNC_INTERVAL_TIME,the next sync interval for this LOB is skipped.

3. If an account is added to a synced safe, or if a new safe was added or assigned to theLOB User, then the new accounts will be synced to Conjur in the next sync interval.The Synchronizer will first refresh changes in currently synced secrets and then willadd the new accounts to Conjur, so ongoing changeswill be updated as soon aspossible.

System requirementsComponent Requirement

Synchronizer Windows Server 2016Windows Server 2012 R2.NET Framework 4.5.2PowerShell 4

PAS Version 9.7 and laterFor details, see the Privileged Access Security Installation Guide.

ConjurEnterprise

Version 10.8 and laterFor installation details, see Install Conjur Enterprise.

Conjur CLI Recommended install (not mandatory): cyberark/conjur-cli:5 Dockerimage.For details, see Conjur CLI.

Hardware requirementsComponent CPU # of cores RAM (GB)

Synchronizer 4 8

Conjur Conjur Container: 4Conjur host machine: 4 orgreater

Conjur Container: 8Conjur host machine: 16 orgreater

LicensingThe Synchronizer and the LOB users are APPProvider users and require appropriatelicenses.

AuditsAudits records are stored in the Enterprise Password Vault ® (EPV) and in Conjur. TheSynchronizer does not maintain audit records.



https://docs.conjur.org/Latest/en/Content/Tools/cli.html

Synchronizer InstallationThis topic describes how to install the Synchronizer on aWindows platform.

Log in to the Synchronizer machine as an Administrator and unzipVaultConjurSynchronizer.zip to a directory of your choice. In future steps, we refer tothis as <installation directory>.The installation process creates log files in the following locations:

<Synchronizer directory>/Logs/Installation.log

<Installation directory>/Installation.log

Note:Install Synchronizer on a clean machine with no other Vault-Conjur Synchronizerversion installed.

Configure Vault components

PrivateArk clientGo to File > Server File Categories... > New to add File Categories for the ConjurHost platform.

1. Add the following file categories for the Conjur Host platform:

Note:This step is required when using Vault 10.2 and below.

File Category Name Type Required Category

HostName TEXT No

ApplianceURL TEXT No

ConjurAccount TEXT No

2. Go to Tools > Administrative Tools > Users and Groups > New > User tocreate the user for the Synchronizer. Provide a password for this user:

Tab Column Value

General User name Sync_<Synchronizermachinehostname>

User type APPProvider

Authentication Usermustchangepassword atnext log on

Uncheck



Tab Column Value

Passwordnever expires

Check

PVWA1. Log in to the PVWA as a Vault administrator.2. For PAS 10.6 and earlier versions: To import the Conjur Host platform, go to

ADMINISTRATION > Platform Management > Import Platform. Open thePolicy-ConjurHost.zip from the <installation directory>/Installation folder.

3. To activate the CyberArk Vault platform, go toADMINISTRATION > PlatformManagement, selectCyberArk Vault then selectActive, and save.

4. Create a Safe namedConjurSync. Assign ownership of the Safe to theSynchronizer Vault user with the following permissions:

Role Permission

Access Use accountRetrieve accountList account

Account Management Add accountUpdate account contentUpdate account proprieties

Workflow Access Safe without confirmation

Advanced Create folderDelete folder

5. Log off fromPVWA.

InstallationThe Synchronizer can be installed in either of the following ways:

InstallationMethod Description

Standard Youwill be asked to provide information throughout the installationprocess.

Silent The installation procedure is initiated either by a user or by a script, and isperformed without any human interaction

Standard installation1. Open aWindows PowerShellwindow as an administrator, navigate to

<installation directory>/Installation and run the following command :

.\V5SynchronizerInstallation.ps1



2. Follow the installation prompts.3. When the installation process ends, the CyberArk Vault-Conjur Synchronizer

service appears in theWindowsServiceManagement Console and the CyberArkVault-Conjur Synchronizer event log appears in the Event Viewer in theApplication and Services Logs folder. For details, see Logs, page 45.

Silent installationTo run a silent installation, you need the following prerequisites:

Credential file for the Conjur Admin user. During installation, the Conjur Adminuser creates the Synchronizer host in Conjur.Configure the silent.ini file

Do the following to prepare and run the silent installation:

1. Open aWindows PowerShellwindow as an administrator, navigate to<installation directory>/Installation/ and run the following commands tocreate a credentials file for the Conjur Admin user:

$username = "<Conjur admin username>"

$password = Read-Host "Enter the Conjur adminpassword" -AsSecureString

$credentials = New-ObjectSystem.Management.Automation.PSCredential -ArgumentList $username,$password

$credentials | Export-Clixml ConjurAdminCredFile.xml

2. Go to <installation directory>/Installation to edit the silent.ini file:Parameter Description Default value

InstallationTargetPath

Location to install thesynchronizer.

C:\ProgramFiles\CyberArk\Synchronizer

ConjurServerDNS Conjur server DNS, including portif needed.

VaultName The logical name for theCyberArk Vault used tosynchronize with Conjur. Forexample, the DNS name.

Note:Vault name cannotcontain specialcharacters ornumbers.

ConjurAccount The name of the Conjur account



Parameter Description Default value

to which you would like to sync.

VaultAddress Address of the CyberArk Vaultused to synchronize with Conjur.

VaultPort Port of the CyberArk Vault 1858

SynchronizerVaultUsername

User name of the SynchronizerVault user

ConjurCredentialsFilePath

Full path of the Conjur Adminuser's credentials file that wascreated in step 1 (<installationdirectory>/Installation/ConjurAdminCredFile.xml)

3. Open aWindows PowerShellwindow as an administrator, navigate to<installation directory>/Installation and run the following command :

.\V5SynchronizerInstallation.ps1 -silent

4. When the installation process ends, the CyberArk Vault-Conjur Synchronizerservice appears in theWindowsServiceManagement Console and the CyberArkVault-Conjur Synchronizer event log appears in the Event Viewer in theApplication and Services Logs folder.

Create a cred file for the Synchronizer's Vault user1. After a silent installation, open aWindows PowerShellwindow as an

administrator, navigate to <installationdirectory>/Installation/CreateCredFile and run the following commands:

.\CreateCredFile.exe VaultConjurSynchronizerUser.credPassword /Username Sync_<Synchronizer machinehostname>/Password <Synchronizer Vault User password>/ExePath "<Synchronizerdirectory>\VaultConjurSynchronizer.exe"/Hostname

2. Move the output file to <Synchronizer directory>\Vault.

Post installationDuring the installation process, the installer created a credentials file for the SynchronizerConjur host. To create an account for this host in the Vault, you need to decode thecredentials stored in this file. This account is the Synchronizer representation in Conjurand is used to retrieve the Synchronizer identity in Conjur.

Add an account in the Vault for the Synchronizer's Conjur host1. Navigate to <installation directory>/Installation.

Run the following commands to read the credentials of the Synchronizer Conjurhost:



$credentials = Import-Clixml -PathsynchronizerConjurHost.xml

$credentials.Username

$credentials.GetNetworkCredential().password

2. Use the values from step 1 to add an account in the PVWA:Method How to

PVWA Edit the following:Parameter Value

Device Type Application

Platform Name Conjur Host

Store in Safe ConjurSync

Host Name The value of$credentials.Username

host/mysynchost

Appliance URL https://<Conjur Server DNS>/api

ConjurAccount The name of the Conjur account towhich you would like to sync.

Password The value of$credentials.GetNetworkCredential().password

Name Conjur_<name> where name is theDNS of ConjurFor example, Conjur_conjur-myorg

Allowautomaticpasswordmanagement

Disable

SecurityBy default, the installation restricts permission to the Synchronizer folder toAdministrators group only. If you wish to run the Synchronizer with anOS user that is not



amember of the Administrators group, you will need to give this user read, execute, andwrite permissions to the Synchronizer folder.

Following Synchronizer installation, permanently delete or protect the credentials usedduring installation. This includes theConjurAdminCredFile.xml andsynchronizerConjurHost.xml files.During the Synchronizer installation process, a Conjur server issuer certificate isretrieved and stored at LocalMachine\Root certificate store.

This will occur only if the Conjur server issuer certificate is not already a trustedcertificate.

We recommend configuring the Conjur appliance with the certificate issued by yourorganization's Certificate Authority.

ConfigurationThis topic describes the configuration of the CyberArk Vault-Conjur SychronizerWindows service and its files. The configuration files define how the Synchronizer worksand aremodified automatically during installation. Youmay edit the CyberArk Vault-Conjur Synchronizer Windows service and its configuration filesmanually afterinstallation according to the tables below.

Note:If you modify a configuration file, restart the CyberArk Vault-Conjur Synchronizerservice.

CyberArk Vault-Conjur SynchronizerWindows service configurationThe following table lists the parameters found used for the CyberArk Vault-ConjurSynchronizer Windows service configuration.

You canmodify the following:

Parameter Description Default

General >Startuptype

Indicates how and whenthis service is started.

Automatic(Service starts at boot time)

Log On >Log on as

The type of accountwhere the service runs.

Local System Account(An account, used by the service controlmanager, that has extensive privileges onthe local computer and acts as the computeron the network)

Recovery >First failure

The action that occurson the first servicefailure.

Restart the Service

Recovery >Secondfailure

The action that occurson the second servicefailure.

Restart the Service




Recovery >Subsequentfailures

The action that occurson subsequent servicefailures.

Take No Action

Recovery >Reset failcount after

Time after which thefailure count is reset to0.

1 day

Recovery >Restartserviceafter

Time between servicefailure and service start,if the action is Restartthe Service.

1 minute

VaultConjurSynchronizer.exe.configThe following table lists the parameters found in themain configuration file which aremodified automatically during the installation process. These parameters define how theSynchronizer works.

You canmodify the following:


INTEGRATION_VAULT_NAME

The logical name forthe CyberArk Vaultused to synchronizewith Conjur.Use the Vault Namethat has been usedduring installation.For example, theDNS name.

Note:Vaultnamecannotcontainspecialcharactersornumbers.

SYNC_INTERVAL_TIME

Interval time (inseconds) when theSynchronizerrefreshes accountsfrom the vault.

300

CRED_FILE_PATH The path to theSynchronizer VaultUser cred file

./Vault/VaultConjurSynchronizerUser.cred




VAULT_FILE_PATH

The path to theVault.ini file usedprimarily to configurethe CyberArk Vaultaddress.

./Vault/Vault.ini

LOGS_FOLDER_PATH

Path to the log files.If you customize thelog file path, restrictread/writepermissions to theAdministrator'sgroup.

./Logs

CASOS_LOG_LEVEL

Defines whichCASOS log level iscreatedValid values:OFFERRORDEBUG

ERROR

CASOS_LOG_MAXIMUM_FILE_SIZE_MB

Maximum size ofCASOS log filebefore being rolled

8

log4net > root >level

The log root level.Logs are written fromthe selected level andabove.Valid values:ALLDEBUGINFOWARNERRORFATALOFF

INFO

log4net > root >appender >MaximumFileSize

Themaximum size(in MB) of the log filebefore being rolled.

10MB

log4net > root >appender >MaxSizeRollBackups

Themaximumnumber of backupfiles that are keptbefore the oldest iserased

60

CONJUR_CERT_FILE_PATH

Obsolete parameter.Do not remove it from




the configuration file.

POLICIES_FOLDER_PATH

Obsolete parameter.Do not remove it fromthe configuration file.

log4net > appendername ="eventLog"

Specify the LevelMinand LevelMaxparameters:DEBUGINFOWARNERRORFATAL

Default LevelMin = WarnDefault LevelMax = Fatal

Vault.iniThe Vault parameter file, Vault.ini, contains all the information about the Vault that will beaccessed byCyberArk components. Each component that will access the Vault requiresa Vault.ini file of its own.

Note:The semicolon (;) and hash (#) characters indicate the beginning of a remark. However,if these characters appear between quotation marks (“”) or after an equals sign (=) theyare considered to represent a parameter.

Parameter

Vault

Description The name of the Vault.

Acceptable Values String

Default Value None

Address

Description The IP address(es) of the Vault. The first IP address is the IPaddress of the Production Vault and the remaining IP addresses areDR Vaults. There is no limit to the number of DR IP addresses thatyou can specify.

Acceptable Values <IP address>,<IP address>,<IP address>,...

Default Value None

Port

Description The Vault IP Port.

Acceptable Values Number



Parameter

Default Value 1858

Timeout

Description The number of seconds to wait for a Vault to respond to a commandbefore a timeout message is displayed.


Default Value 30

ProxyAddress

Description The proxy server IP address. This is mandatory when using a proxyserver.

Acceptable Values IP address

Default Value None

ProxyPort

Description The Proxy server IP Port.


Default Value 8081

ProxyUser

Description User for Proxy server if NTLM authentication is required.

Acceptable Values User name

Default Value None

ProxyPassword

Description The password for Proxy server if NTLM authentication is required.

Acceptable Values Password

Default Value None

ProxyAuthDomain

Description The domain for the Proxy server if NTLM authentication is required.

Acceptable Values Domain name

Default Value NT_DOMAIN_NAME

BehindFirewall

Description Accessing the Vault via a Firewall.

Acceptable Values Yes/No

Default Value No

UseOnlyHTTP1

Description Use only HTTP 1.0 protocol. Valid either with proxy settings or with



Parameter

BEHINDFIREWALL.


Default Value No

NumOfRecordsPerSend

Description The number of file records that require an acknowledgement fromthe Vault server


Default Value 15

NumOfRecordsPerChunk

Description The number of file records to transfer together in a single TCP/IPsend/receive operation


Default Value 15

ReconnectPeriod

Description The number of seconds to wait before the sessions with the Vault isre-established.


Default Value 1

EnhancedSSL

Description Whether or not to use an enhanced SSL based connection (port 443is required).


Default Value No

PreAuthSecuredSession

Description Whether or not to enable a pre- authentication secured session.


Default Value No

TrustSSC

Description Whether or not to trust self-signed certificates in pre-authenticationsecured sessions.


Default Value No

AllowSSCFor3 PartyAuth

Description Whether or not self-signed certificates are allowed for 3rd party



Parameter

authentication (eg, RADIUS).


Default Value No

CIFSGateway

Description The name of the CIFS Gateway.

Acceptable Values String

Default Value None

HTTPGatewayAddress

Description The URL of the HTTP Gateway.

Acceptable Values URL

Default Value URL

Vault Disaster RecoveryThis topic describes support of Vault disaster recovery which provides seamlessproductivity during a failover.

For details, see the following topics:

Disaster Recovery SiteInitiate a DR Failback to the Production Vault

Transparent failoverAs soon as the Production Vault cannot be reached by the Synchronizer, the failoverprocess begins in the DR Vault transparently, and no human intervention is required.

The IP addresses of both the Vault and the DR Vault are specified in the Vault.iniconfiguration file. When the Synchronizer cannot reach the Vault specified by the first IPaddress, it transfers automatically to the Vault specified by the second IP address, whichis the DR Vault.

Configure transparent failover1. In the Vault.ini file, in theAddress parameter, specify the IP addresses of the

Vault and the DR Vault, separated by commas, without quotes, as shown in thefollowing example:

Address=1.1.1.102,1.1.1.232

The above example indicates that the IP address of the Production Vault is1.1.1.102 and the IP address of the DR Vault is 1.1.1.232.

2. Add theSwitchVaultAddressTimeOut parameter.



https://cyberarkdocu.azurewebsites.net/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PAS INST/Installing-the-Privileged-Account-Security-Disaster-Recovery-Site.htm?Highlight=Disaster%20Recovery%20Site

https://cyberarkdocu.azurewebsites.net/Product-Doc/OnlineHelp/PAS/Latest/en/Content/PASIMP/Initiating-DR-Failback-to-Production-Vault.htm

This parameter specifies the number of seconds that the Synchronizer will try toaccess additional Vault IP addresses after the initial timeout to the current Vault,specified in the Timeout parameter, expires.If this parameter is not added, the default value of three secondswill be applied.

3. Save the Vault.ini file and close it.4. Restart the Synchronizer window service.

Replicate synchronizer userThis is configured by the following parameter in the CreateCredFile utility:

DisableSyncPasswordToDR –Whether or not passwords that are replaced in usercredential files will be replicated to all the configured DR sites. By default, this parameteris set to ‘No’, which indicates that the DR user’s password will be replicated to the DRVault whenever it is changed.

Run SynchronizerThis topic describes how to run the Vault-Conjur Synchronizer.

Note:You can add LOBs before you run the synchronizer. For details, see Line of Business(LOB), page 19

1. Navigate to theWindows Services Management Console and start theCyberArk Vault-Conjur Synchronizer service.You can also start this service from the command line, using the following command:

sc.exe start CyberArkVaultConjurSynchronizer

2. Go to <LOGS_FOLDER_PATH> and open theVaultConjurSynchronizer.log logfile to verify that Synchronizer is running without errors.

Note:Synchronizer sync on startup may take time

Line of Business (LOB)

OverviewA line of business (LOB) represents a business group that requires access to secretsfrom the Vault. This enables segregation of duty (SoD). The LOB facilitates the syncingof accounts to Conjur.

This topic describes how to add and assign permissions to an LOB user.



Add an LOBYou can add an LOB before or after running the Synchronizer.

PrivateArk clientGo to Tools > Administrative Tools > Users and Groups > New > User andcreate a Vault user for the LOB, provide a password for this user, and update thefollowing values:

Tab Column Value

General User name <LOB name>

Note:LOB Usernamecannotbegin with aspecialcharacter orcontainspaces.

User type APPProvider

Authentication UserMust ChangePassword at Next Logon

Uncheck

Password never expires Check

PVWA1. Create an account for the LOB User with the following configuration. The account

namemust have a prefix of LOBUser_<LOB name>. To set this, see Customizethe account name, page 21, below.

Configuration

Parameter Value

Device Type Application

Platform Name CyberArk Vault

Note:Ensure thatthe platformis activated.

Store in Safe ConjurSync

User Name Unique <LOB name>

Address IP address of the Vault



Parameter Value

Password Password of <LOBname>

CustomizeAccount Name

LOBUser_<LOB name>

Customize the account nameIn the PVWA v10 interface:

In the PVWA classic interface:

2. Assign the Vault user <LOB name> as an owner of the Safes you would like tosyncwith Conjur. The <LOB name> user requires the following permissions:Role Permissions

Access Use accountsRetrieve accountsList accounts

Workflow Access Safe without confirmation



Delete an LOBTo stop syncing a particular LOB, do the following steps:

Caution:After deleting an LOB, other hosts or users can no longer access the LOBvariables.

PVWAThis step deletes the LOB account in PVWA. The Synchronizer will no longer sync theLOB.

1. Log in to the PVWA as a Vault administrator.2. Delete the LOBUser_<LOB name> user account from the ConjurSync safe.

PrivateArk clientThis step deletes the LOB user in PrivateArk. The user will not be counted for licensepurposes.

Delete the <LOB name> user.

Conjur Enterprise EditionThis step deletes an LOB fromConjur.

1. Create a policy file named deleteLob_<lobName>.yml with the LOB name youintend to delete.

2. In the policy file, input the below text. Replace the <lobName> text with the LOByou intend to delete.

- !deleterecord: !group <lobName>-admins

3. Log in to Conjur as a Conjur Administrator and load the policy using the ConjurCLI:

conjur policy load --delete <VaultName> <path to yourpolicy>

This can also be done using the Conjur v5 update policy REST API:https://www.conjur.org/api.html#policies-update-a-policy-patch

Supported LOBsThe Synchronizer can support up to 10 LOBs. If you initially addmore than 10 LOBs, theSynchronizer doesn't start and generates an error in the logs.

If you add LOBs after the Synchronizer started and the total number of LOBs exceeds 10,the Synchronizer does not sync these additional LOBs and generates an error in the logs.



https://www.conjur.org/api.html#policies-update-a-policy-patch

Conjur PoliciesConjur policies enable you to define security rules in declarative files. These securityrules describe which users and services have privileges to accessmachines or getsecrets such as passwords and API keys.

When synchronization is complete, the Conjur policy tree structure for each Safecontains:

Delegationpolicy

Formanaging Conjur users, groups, hosts, and layers privileges:<Vault_name>/<lob_name>/<safe_name>/delegation

Consumer group Has read and execute permissions to all of the Safe's variables:<Vault_name>/<lob_name>/<safe_name>/delegation/consumers

For more information about variable names, see how the Vault account is represented inConjur.

Grant role permissions on all variables in a SafeTo grant role permissions to all variables in a Safe, youmust be amember of the <safe_name>-admins group.To grant permissions on all variables in a Safe:

1. Append the <vault_name>/<lob_name>/<safe_name>/delegation policy usingtheAppend to PolicyREST API.

2. Add users, hosts, groups, and layers to the consumers group that has read andexecute permissions on all Safe variables.

Example: Granting permissions on all variables in a specific SafeBob is a Conjur user. He wants to grant a Conjur host, /myapp/myhost, read andexecute permissions on all synced variables in the secured_vault/serverapp_lob/db_accounts_safeSafe.1. Jane, the LOB admin, adds Bob to the db_accounts_safe-admins group,

enabling him to grant permissions to /myapp/myhost on all variables under thedb_accounts_safe policy:a. Jane creates the following policy, bob.yml, to grant BobSafe Admin

privileges:

- !grantrole: !group db_accounts_safe-adminsmembers:- !user <path>/bob

b. Jane loads bob.yml to secured_vault/serverapp_lob:

conjur policy load secured_vault/serverapp_lob bob.yml



https://www.conjur.org/api.html#policies-append-to-a-policy-post

2. Now that Bob is Safe admin, he can add the host to the consumers group:a. Bob creates the following policy,myhost_delegation.yml:

- !grantrole: !group consumersmembers:- !host /myapp/myhost

This policy adds /myapp/myhost to the consumers group which alreadyhas read and execute permissions on all of the Safe's variables.

b. Bob then loads the policy as follows:

conjur policy load secured_vault/serverapp_lob/db_accounts_safe/delegation myhost_delegation.yml

Grant role permissions to specific variables in a SafeTo grant role permissions to specific variables in a Safe, youmust be amember of the<lob_name>-admins group.To grant permissions on specific variables in a Safe:

Append the <vault_name>/<lob_name> policy using theAppend to PolicyRESTAPI, granting permissions to users and hosts on the specific variables.

Caution:Avoid usingPUT (--replace) to update <vault_name>/<lob_name> policies. Thismay remove all synchronized secrets under the LOB, and would require manualsteps to fix the synchronization.

Example: Grant role permissions to a specific variable in a SafeJane is LOB admin. She wants to grant a Conjur host, /myapp/myhost, read andexecute permissions to the synced variable, secured_vault/serverapp_lob/db_accounts_safe/oracle_account/password.1. Jane grants permissions to /myapp/myhost on a specific variable under the

db_accounts_safe policy as follows:a. Jane creates themyhost_delegation.yml policy as follows:

- !permitrole: !host /myapp/myhostprivileges: [read, execute]resources: [!variable db_accounts_

safe/oracle_account/password]



https://www.conjur.org/api.html#policies-append-to-a-policy-post

b. Jane then loads the policy as follows:

conjur policy load secured_vault/serverapp_lob myhost_delegation.yml

Vault Conjur-Synchronizer Full Policy GuideThis topic consolidates all concerns regarding policies for Synchronizer on top of Conjur.

It includes all policies that Synchronizer loads during installation or runtime, aswell assuggested follow-up policies.

Although Synchronizer usesConjur REST APIs for similar actions to those described inthe examples below, the examples here use Conjur CLI syntax.

Note:This page is aligned with all Synchronizer versions support Conjur v5.

Before synchronizationWeassume the following policy structure exists in Conjur before using Synchronizer.

Let's say a user, Alice, owns themyApp policy.

[admin] conjur policy load root myapp_policy.yml

myapp_policy.yml

- !userid: alice

- !policyid: myAppowner: !user alice

InmyApp, Alice defines a host and a variable. The host has permissions to read andexecute the variable.

[user/alice] conjur policy load myApp myapp.yml

myapp.yml

- !variable password- !host myHost- !permit

role: !host myHost



https://www.conjur.org/api.html

https://www.conjur.org/tools/cli.html

privileges: [read, execute]resource: !variable password

ThePassword secret ismoved to the Vault, to the safeNameSafe, whose accountname isdbuser. This provides all the goodies Privileged AccessManager provides, forexample, Central PolicyManager, Privileged SessionManager, and so on.

Conjur admin wants to install Synchronizer to sync the password and to grant the hostthe same permissions on the new variable.

Synchronizer policiesThis section describes:

Installation policy, page 26LOB policy, page 26Safe policy, page 27

Installation policyDuring the Synchronizer installation, an installation policy is loaded and creates thefollowing:

Vault admins group with a Synchronizer host in itA vaultName policy owned by the group

[admin] conjur policy load root vaultName.yml

vaultName.yml

- !groupid: vaultName-admins

- !policyid: vaultNameowner: !group vaultName-admins

- !hostid: syncHostUser

- !grantrole: !group vaultName-adminsmembers:- !host syncHostUser

LOB policySuppose the LOB, lobName, owns Safe, safeName.Syncing an LOBmeans that for each LOB, an LOB admins group and an LOB policy arecreated.



The responsibility of the LOB admins group is to manage access to all variables in theLOB.

[host/syncHostUser@syncHosts] conjur policy load vaultNamelob.yml

lob.yml

- !group lobName-admins

- !policyid: lobNameowner: !group lobName-admins

Safe policyFor each non-empty safe owned by an LOB user, Synchronizer creates its own sub-policy.

The safe policy defines a safeName-admins group and a delegation sub-policy. ThesafeName-admins group owns the delegation sub-policy.

In the delegation policy, the Synchronizer defines a consumers group. This group isautomatically given read and execute permissions on all variables under the Safe.

The responsibility of the safeName-admins groupmembers is to managemembers ofthe consumers group.

Creating a Safe

[host/syncHostUser@syncHosts] conjur policy loadvaultName/lobName safe.yml

safe.yml

- !group safeName-admins

- !policyid: safeName

Creating a delegation policy

[host/syncHostUser@syncHosts] conjur policy loadvaultName/lobName/safeName delegation.yml

delegation.yml



- !policyid: delegationowner: !group ../safeName-admins

Creating a consumers group

[host/syncHostUser@syncHosts] conjur policy loadvaultName/lobName/safeName/delegation consumers.yml

consumers.yml

- !groupid: consumers

Safe policy in Synchronizer 10.6 and earlierIn earlier versions of Synchronizer (10.6 and earlier), safeName is just a simplepolicy—a container for the Safe's variables.

[host/syncHostUser@syncHosts] conjur policy loadvaultName/lobName safe.ymls

safe.yml

- !policyid: safeName

Creating variablesVariables are created under a Safe policy.

A variable ID ismade up of two parts joined by a forward slash (/):

An account name in the Safe for a single account or a virtual user name for adual accountA variable for the account's password and/or the username.

A variable can have three annotations:

Annotation Description

cyberark-vault: 'true' The source of this variable'svalue is in the Cyberark Vault

cyberark-vault/accounts:vaultName/safeName/dbusercyberark-vault/accounts:vaultName/safeName/osuser01,vaultName/safeName/osuser02

The path to the account inCyberark Vault.For dual accounts, this is a listof paths to all accounts of dualaccount group. The list iscomma separated.



Annotation Description

cyberark-vault/dual-account: 'true' The variable belongs to a dualaccount.In single accounts thisannotation does not exist.

The policy also contains a permit statement that provides read and executepermissions to the consumers group.

Permit statements such as delegation policies and consumers groups exist onlyfromSynchronizer 10.8.

[host/syncHostUser@syncHosts] conjur policy loadvaultName/lobName/safeName vars.yml

vars.yml

- &active-variables- !variable

id: dbuser/passwordannotations:

cyberark-vault: 'true'cyberark-vault/accounts:

vaultName/safeName/dbuser- !variable

id: dbuser/usernameannotations:

cyberark-vault: 'true'cyberark-vault/accounts:

vaultName/safeName/dbuser

- !permitrole: !group delegation/consumersprivileges: [ read, execute ]resources: *active-variables

After loading variables, Synchronizer updates their values using the Add a secretREST API.

[host/syncHostUser@syncHosts] conjur variable valuesadd vaultName/lobName/safeName/dbuser/password'P@s$w0rd'

[host/syncHostUser@syncHosts] conjur variable values



https://www.conjur.org/api.html#secrets-add-a-secret-post

add vaultName/lobName/safeName/dbuser/username'myAppUser'

Follow up policiesSuppose bob is a user in Conjur. Conjur Admin can grant bobmembership to the lob-admins group.

[admin] conjur policy load root bob.yml

bob.yml

- !userid: bob

- !grantrole: !group vaultName/lobName-adminsmembers:- !user bob

"Specif ic" follow up policyNow bob can grant read and execute permissions on a specific variable to specific roles(groups, layers, users and hosts).

Bob grantsmyHost read and execute permissions on the dbuser account variables.

[bob@vaultName/lobName-admins] conjur policy loadvaultName/lobName permit.yml

permit.yml

- !permitrole: !host /myApp/myHostprivileges: [ read, execute ]resources: [ !variable safeName/dbuser/password,

!variable safeName/dbuser/username ]

"All safe variables" follow up policy

Note:Supported from Synchronizer 10.8.

chris is a user.

[admin] conjur policy load root chris.yml



chris.yml

- !userid: chris

bob (lob-adminsmember) grants chris membership to the safeName-admins group.

[bob@vaultName/lobName-admins] conjur policy loadvaultName/lobName grant_safeName-admins.yml

grant_safeName-admins.yml

- !grantrole: !group safeName-adminsmembers:- !user /chris

Now chris can grant consumersmembership to any other role (group, layer, user andhost) in Conjur.

The consumers group already has read and execute permissions on all safeNamevariables.

chris grants consumers membership to the host,myHost.

[chris@vaultName/lobName-admins/safeName-admins] conjurpolicy load vaultName/lobName/safeName/delegation grant_consumers.yml

grant_consumers.yml

- !grantrole: !group consumersmembers:- !host /myApp/myHost

Consuming variablesNowmyHost can consume the variables.

[myApp/myHost] conjur list[

"quick-start:variable:myApp/password","quick-

start:variable:vaultName/lobName/safeName/dbuser/password""quick-

start:variable:vaultName/lobName/safeName/dbuser/username"]



[myApp/myHost] conjur variable valuevaultName/lobName/safeName/dbuser/passwordP@s$w0rd

[myApp/myHost] conjur variable valuevaultName/lobName/safeName/dbuser/usernamemyAppUser

Delete LOBConjur admin wants to delete the lobName LOB.Delete runs by cascading. Because the lobName-admins group owns lobName,deleting the group deletes the LOB too.

[admin] conjur policy load --delete vaultName delete_lob.yml

delete_lob.yml

- !deleterecord: !group lobName-admins

Accounts and Safes

Manage single accountsThis topic describes how you can provision accounts in the Password Vault.

Provisioning methods

Methods Description

PVWA You can provision accounts individually in the Vault in the AddAccounts page of the PVWA.

AccountsFeed–

You can configure the CPM to scan an organizational network andretrieve a list of accounts that have access to its computers and theirdependencies.

ProvisioningAccountsAutomatically

You can detect and provision accounts automatically providing a fulllife-cycle automatic management system forWindows accounts andtheir services.

Web Service You can provision accounts using theAddAccountweb service.

Bulk upload You can provisionmultiple accounts with the Password Upload utility.

For more information about these provisioningmethods, see thePrivileged AccessSecurity Implementation Guide .



Add an account in the PVWAThe following procedure describes how to add an account in the PVWA.

Add an account1. Click ACCOUNTS to display the Accounts page.2. ClickAdd Account; the Add Account page appears.

Note:This button will only be displayed if you have the Add accounts, Updatepassword value, or update password properties authorization in at least oneSafe.

3. From the Safe drop-down list, select the Safe where the account will be stored.4. From the Device drop-down list, select the platform onwhich the new password is

used.5. From the PlatformName drop-down list, select an active target platform.6. Required or optional properties for the type of account that you have selected will

appear automatically, according to the definitions in the target platformconfigurations.

7. Specify the required account properties and, if necessary, the optional accountproperties.

Note:To specify an IPv6 address, specify the global format, as shown in the followingexample: 1000:1000:1000:1000:1000:1000:1000:0055For a list of platforms that support automatic password management on IPv6,refer to the Privileged Access Security System Requirements.

8. In thePassword field, specify the password. Make sure this passwordmeets yourenterprise password policy requirements.

9. In theConfirm Password field, specify the password again.10. To generate a password name automatically, selectAuto-generated. For more

information about naming passwords automatically, refer to Identifying Accountsin the Privileged Access Security Implementation Guide.

11. To specify a password name, enter the name in theCustom field.12. To disable automatic passwordmanagement by the CPM for this password so

that it will bemanagedmanually, selectDisable automatic management forthe password. You can also enter a reason for doing this.

Note:The CPM user must be an owner of the Safe where the password will be storedand a platform name of an active target account platform must be specified inorder for the password to be managed by the CPM.

13. ClickSave; the new account is added.14. If the PVWA is configured to automatically change or verify passwordswhen they

are added, this will be done now. For more information about configuring this



feature, refer to Adding Accounts in the Privileged Access SecurityImplementation Guide.

15. The account is now created in the specified Safe and the new account details aredisplayed in the Account Details page. If the specified password contains leadingand/or trailing white space character(s), a message appears in the AccountDetails page indicating that theywill automatically be removed.

16. Some platforms require additional information. You can specify this information inthe tabs in the Account Details page.

Manage Dual AccountsTheDual Accounts deployment method eliminates any edge case delays that may beencountered when using the Single Account deployment method. Using the SingleAccount deployment method, delaysmay be incurred in edge cases such aswhen apassword is requested exactly when CPM is changing that password. Dual Accountsensures no such delays are incurred when the application needs credentials, since apassword that is currently used by an application will never be changed. This is especiallyrecommended in high load and critical applications.

The Dual Accountsmethod ensures seamless, safe access to a system, database, orapplication. With this type of account rotation, there are no blackout periodswhenpasswords expire.

How it worksTwo accounts with identical privileges are assigned: one active:A, one inactive:B. Thereis always an active account, which remains untouched during password rotation. Thisensures business continuity, with no delays.

Rotation 1At the set date for password rotation, accountA, the first account in use, is deactivated,andB is activated.

While the second accountB is active, there is a grace period, during which thedeactivated first accountA will have its password reset. This allows all applications toregister the change and switch to using the newly active account.

Rotation 2At the next set date for password rotation, accountB is deactivated. AccountA is nowactive.

Deactivated accountB has its password reset at the end of this grace period.

Dual Account propertiesTheDual Account solution uses two account properties to determine which accounts arevalid for use at any given time.

Property Description

DualAccountStatus This property flags accounts as Active or Inactive. Dualaccounts pairs will always have one active account and oneinactive account.

VirtualUsername This property identifies two identically provisioned accounts in adual accounts pair under one virtual username.



On each target system, theremust be two accounts with identical permissions, the dualaccounts pair, used by the application to connect to the system. In the Vault one accountis tagged as active and the other account is tagged as inactive (using theDualAccountStatus property), while on the target system (e.g. database), they are bothenabled. CyberArk AIM does not enable or disable accounts on target systems.

A typical example is when an application connects to a remote database.

TheBillingApp application regularly requests an account password from theCredential Provider in order to connect to a DB2 database, located on 10.0.0.1.

When using the Dual Account solution, two accountsmust reside on the DB2 database.Both accounts have the same value for their VirtualUsername property, which linksthem and creates the dual accounts pair. These accounts will be used by theBillingAppapplication to connect to the database when required. One account is alwaysActive andone account is always Inactive. Account status will be updated during a passwordchange.

Configure dual accountsThis topic describes how to configure Dual Account passwordmanagement.

Configure support for dual account password managementTo support rotation of the two accounts before a Central PolicyManager passwordchange, the two accounts are grouped into a Rotational Group.

For details about the PAS functionalitymentioned in this section, see the PrivilegedAccess Security Implementation Guide.

Prepare the Vault environment for dual account support

Note:This step needs to be done once.

In the PrivateArk Client, add the following file categories to the Vault environment:

Note:Make sure that the file categories are configured at the Vault level and not at the Safelevel.

Category Type Description

CurrInd Numeric This file category is applied to the group accountand indicates the currently active account in theRotational Group context. The valuematches anaccount index (see below) in the Rotational Group.

Index Numeric This file category is applied to all accounts in theRotational Group. Accounts will be rotated inascending order according to their index.



Category Type Description

DualAccountStatus List Valid Values: Active/Inactive

VirtualUsername Text A logical name that represents both accounts in theRotational Group.

Rotational group platform configurationConfigure the Platform that will be used by theGroupObject.

Note:Do this step for each Platform setting. If one Platform setting addresses all DualAccounts’ pairs and their needs, it may be reused.

In PVWA’s Platform Management:1. Duplicate theSample Password Group Platform template.

2. Rename the Platform to represent its purpose. For example, Rotational Policy.3. Activate the Platform. ClickEdit to configure the new policy.



4. Go to Target Account Platform > Automatic Password Management >General. Edit the Platform’sPolicyType toRotationalGroup

5. Go to Target Account PlatformRight-clickAutomatic PasswordManagement > Add additional Policy SettingsRight-clickAdditional PolicySettings > Add Parameters. Right-clickParameters > Add Parameter. Add acustom property to the group, calledGracePeriod

6. Set theGracePeriod parameter and value:



TheGracePeriod value is the number of minutes between the rotation of rolesbetween the accounts (Active/Inactive) and the beginning of the password changeprocess for the current Inactive Account.This enforces a delay that ensures there are no discrepancies between theaccount being used by the application and the one having its password rotated.It is recommended that theGracePeriod value is set to be 3 times longer than thesync interval time (SYNC_INTERVAL_TIME) parameter of the Synchronizer.

Note:In an environment where Dual Accounts is implemented for both AIM andConjur, set the value of the GracePeriod for both to which whichever value ishigher.

7. Save the new Platform.

Configure the object’s platform for dual account supportConfigure the Platform that will be used by the each of the Dual Accounts’ objects.

Note:This step needs to be done for each Platform used by Dual Account objects.

Configure the object's platform1. Go to Target Account Platform > UI & Workflow > Properties.Right-click

Optional . Add the following properties previously defined in the Vault:IndexDualAccountStatusVirtualUsername

2. Save the Platform.

Configure accounts and groups for dual accounts support

Note:This step is done for each account that is used as Dual Account.

Configure for dual accounts support

1. Click to configure dualaccount support.



2. Create the account object.

Note:Both accounts must be created in the same Safe.

3. For each dual account, selectAccount Details > Edit to edit each the dualaccount properties:

Property Description

VirtualUsername Logical representation of the account pair. This valuemustbe the same on both accounts.

Index Ascending from 1

DualAccountStatus On the account with Index value ‘1’, set this value to‘Active’. Set the other account to ‘Inactive’.

4. On theCPM tab, clickCreate New orModify to the account to a group:Property Description

Group Enter a group name. This should be the same for both accounts.

PlatformName

Specify the Dual Account platform that you specified in theprevious step.

Set the index of the group object

Note:This step is done once on the group object.

Set indexUsing the PrivateArk Client, edit the group object (this can be found in the Groupfolder of the Safe containing the Dual Accounts objects):



1. Right click the Group object.2. SelectProperties > File Categories3. Add a file category calledCurrIndwith a value of 1. This indicates the index of the

account that is set as Active.

Account rotation flow

Under Rotational Group Platform Configuration1. The CPMdetects that the Rotational Group requires a password change, based

on its Platform settings.2. DualAccountStatus of both accounts is switched between Active and Inactive.3. TheCurrInd of the Group is updated to the index of the Active account.4. The Inactive account ismarked for a password change.5. Based on theGracePeriod property of the Rotational Group Platform, the

password change is delayed, allowing the Credential Provider to refresh its cacheand start working with the current Active account.

6. Once the grace period has ended, the CPMwill initiate a password change taskfor the Inactive account.

Configure the password change interval for dual accountsThe following section describes how to set the interval for an automatic password changein the PVWA:

In Dual Account configuration, a password is changed only after the Account Rotationprocess is completed and theGracePeriod has ended.Therefore, to comply with your organizational password change policy, the followingformula can be used to calculate the password’s expiration period (Require passwordchange every X days) in the Rotational Group Platform settings:

There is an organizational audit requirement that passwords will be changedevery 30 days.The Rotational Group has 3members.Set the expiration periodof theRotational Group to 10 days.

Set the interval for automatic password change in PVWA1. Go toAdministration > Platform Management > Rotational Policy > Edit >

Automatic Password Management > Password Change.EditPerformPeriodicChange toYes.

2. Go toPolicies > Master Policy > Password Management > Requirepassword change every X daysSelectAdd Exception. Select <platform youcreated earlier> > Next. Edit the value to the amount of dayswanted.



LimitationsAccount usages are not supported in automatic Dual Account configuration.

When initiating amanual password change on an account that is amember of aRotational Group, the "Synchronize the current account's password with the group'spassword" radio button is not supported.

Selecting this option will cause the specific account’s password to be out of syncwith theCredential Provider cache.

One-time Passwords and Exclusive AccountsThe Synchronizer can retrieve accounts that have been configured for one-timepassword access and exclusive accounts. However, the effects of interactive user usageand application usage vary, as explained below.

Interactive usage of one-time passwords and exclusive accountsWhen one-time accounts are used, their password is changed after every usage, basedon theMaster Policy. In addition, if Exclusive Access is enforced by theMaster Policy, theaccount is automatically locked during usage. For more information about one-timepasswords and exclusive access, refer to TheMaster Policy in the Privileged AccessSecurity Implementation Guide.

Application usage of one-time passwords and exclusive accountsInherently, applications require passwords at a very high rate. Therefore, one-timepassword workflows are not relevant when applications retrieve passwords. Similarly,several applications in your organizationmay require the same account to be used at thesame time and, therefore, exclusive account workflows are not relevant either.

Nevertheless, it is possible for applications to use accounts that have been configured touse one-time passwords and/or exclusive accounts. Unlike interactive user workflows,one-time passwords that are retrieved by the Synchronizer do not trigger a passwordchange, nor will accounts be locked (if Exclusive Access is configured).

Interactive usersmay continue using these accounts at the same time as applications usethem. However, use by interactive users and applications concurrently will invoke



frequent password changes on accounts that have been configured for one-time access.Password changes require the the Synchronizer to access the Vault in order to retrievethe new password and introduce additional load.

If possible, it is recommended to separate accounts used by interactive users andaccounts used by applications.

Manage Accounts and Safes During SynchronizationThis topic describes how tomanage accounts and safes during synchronization.

Add an Account1. Add an account to a synced safe (the LOB User is an owner of that safe)2. In the next sync interval, the account is added to the LOB and corresponding

variables are created in Conjur.3. After the variables are created and loaded, create a delegation policy and grant

permissions to hosts and users on the variables

Rename an Account1. Give an account, that is synced to Conjur, a new name. (The LOB User is an

owner of the safe that the account is stored in.)2. In the next sync interval, the renamed account is added to the LOB as a new

account and the variables are created in Conjur.3. After the variables are created and loaded, create a delegation policy and grant

permissions to hosts and users for these variables.

Note:The variables that correspond to the account before you renamed it are notdeleted from Conjur. For details, see Limitations, page 44

Add a Safe1. Create a new safe with accounts and add the LOB User as an owner of that safe.

Or add the LOB User as an owner of an existing safe2. In the next sync interval, the accounts are added to the LOB and the variables are

created in Conjur.3. After the variables are created and loaded, create a delegation policy and grant

permissions to hosts and users on the variables

Rename a Safe1. Give a safe that already syncs to Conjur a new name. The LOB User is an owner

of that safe.2. In the next sync interval, the renamed safe's accounts are added to the LOB and

the variables are created in Conjur.3. After the variables are created and loaded, create a delegation policy and grant

permissions to hosts and users on the variables.The variables that correspond to the account before you renamed it are notdeleted fromConjur. For details, see Limitations, page 44.



Delete an Account or SafeDeleting an account or a safe from a currently synced LOB is not supported. Fordetails, see Limitations, page 44.

UpgradeThis topic describes upgrading Vault-Conjur Synchronizer.

Note:Upgrade is supported from v10.4.We recommend backing up the Synchronizer folder (default path: C:\ProgramFiles\CyberArk)before proceeding.After the upgrade, expect the first startup of the Synchronizer to take as long as it tookwhenSynchronizer was first installed.

1. Log in to the Synchronizer machine as an Administrator.

2. UnzipVaultConjurSynchronizer.zip to a directory of your choice.3. StopCyberArk Vault-Conjur Synchronizer service.4. Copy and replace all files except

Vault folderandVaultConjurSynchronizer.exe.conffrom unzipped VaultConjurSynchonizer folder to Synchronizer folder.

Note:The previous location of the Synchronizer folder remains the same. By default, theSynchronizer folder is located here: C:\Program Files\CyberArk\Synchronizer.

Caution:The Vault folder itself and the configuration file,VaultConjurSynchronizer.exe.conf, must not be replaced.

5. StartCyberArk Vault-Conjur Synchronizer service.

Uninstall SynchronizerThis topic describes how to uninstall the Synchronizer on aWindows platform.

Perform the following steps as an Administrator on the Synchronizer machine.

Note:If you are uninstalling in order to upgrade to a new version of Synchronizer:

We recommend backing up the Synchronizer folder (default path: C:\ProgramFiles\CyberArk)before proceeding.Onlyperform the first two stepsbelow.



1. Stop and delete theWindows service.

Run the following commands:

sc.exe STOP CyberArkVaultConjurSynchronizer

sc.exe DELETE CyberArkVaultConjurSynchronizer

2. Delete the Synchronizer folder.

The default location is C:\Program Files\CyberArk.

3. You can also delete each LOB created for the Synchronizer.

This step is optional. For details, refer to Delete an LOB, page 22.

Limitations

General Synchronizer limitationsHigh availability is not supported

Synced Accounts per LOB:One LOB can support up to 15,000 accounts, however, you cannot exceed 150,000accounts across all 10 LOBs.Variable names are limited to 126 characters.

You cannot add a username to an account that has already been synced by theSynchronizer. The username variable will not sync and an error message is writtento the log during each sync interval.

We support two accounts in a dual account group.

Distributed Vaults are not supported.

Secret values that are synced from the CyberArk Vault must not be changed inConjur. If such a secret value is changed in Conjur, unexpected behavior may occur.Change secret valuesonly in their source accounts in the Vault.The Synchronizer syncs accounts found in the root folder of the Safe. Accountslocated in sub-folders are not synced to Conjur.

The Synchronizer skips any safe name, account name, or virtual user name of a dualaccount that begins with a special character and logs an error.

The colon (:) symbol is not supported in the following names: Vault name, LOB username, Safe name, Account name, Account property name (File category name),Virtual user name.

Deletion limitationsDeleting an account or a safe from a currently synced LOB is not reflected in Conjur.

Variables and their values are not deleted in Conjur when you delete an account inthe Vault. This is also true for variables of accounts in a deleted safe.

After accounts are deleted from the Vault, the LOB admin should delete the Conjurvariables of the deleted accounts.



Upgrade limitationsTo upgrade youmust have:

Synchronizer v.10.4 or later.

Synchronizer installed with Conjur Enterprise v.5.

LogsSynchronizer logmessages are written into log files and into theWindowsEvent log.

Log filesSynchronizer logs are located in <LOGS_FOLDER_PATH>. The logs folder contains thetrace log files that track the Synchronizer activity. Themain log file is calledVaultConjurSynchronizer.log.

You can configure the log folder path and log level in theVaultConjurSynchronizer.exe.config file. For details, see Configuration, page 12

Windows Event logThe Synchronizer logs are written to theEvent Viewer > Application and ServicesLogs > CyberArk Vault-Conjur Synchronizer.You can configure the log level in theVaultConjurSynchronizer.exe.config file. Fordetails, see Configuration, page 12.

The following table describes the log levels based on the starting number of the Event ID:

If the Event ID starts with... Synchronizer log level Event log level

1 Debug Information

2 Info Information

3 Warning Warning

4 Error Error

5 Fatal Error

Log entry formatThe following describes the log entry format:

[Date] [Thread ID] [Thread Context] [Debug Level] [Message]

Parameter Description

Date Time of the log entry.

Thread ID ID of thread that wrote the entry.

ThreadContext

The name of the LOB processed by the thread ormain if outside thecontext of the LOBs.

Debug The log root level. Logs are written from the selected level and above.



Parameter Description

Level Valid values:ALLDEBUGINFOWARNERRORFATALOFF

Message The log entry message.

TroubleshootingThis topic describes how to troubleshoot specific errors issued by the Synchronizer to theLogs, page 45.

Issue Errorcode Resolution

Invalid username or password, or theLOB user no longer exists

ITATS004E

Enter a valid user name andpassword.

<InstallationScript> cannot be loadedbecause running scripts is disabled onthis system.Formore information, see About ExecutionPolicies

Change PowerShell executionpolicy to enable you to runscripts (at least AllSigned). Afterinstallation , change the policyto its previous value.

System.Net.WebException: The remoteserver returned an error: (422)Unprocessable Entity.

Edit the name of the entity thatbegins with a special character.

Connection timeout to the vault ITACM012S

Increase the TIMEOUTparameter value in the<Installationpath>\Vault\Vault.ini file.The default value is 60 seconds.

Connection timeout during loadingpolicy via SDK

VCSS004E

Set HTTP_REQUEST_TIMEOUT parameter value inthe <Installationpath>\VaultConjurSynchronizer.exe.config file.The default value is 100,000milliseconds (100 seconds).

At first Synchronizer start up, thenumber of LOBs exceeds 10

VCSS004F

The Synchronizer can supportup to 10 LOBs. If you initiallyaddmore than 10 LOBs, theSynchronizer doesn't start and



https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies


generates an error in the logs.Verify the number of LOBsdefined in the Vault is 10 or less.

At start up, the total count of LOBsexceeds 10

VCSS018E

The total count of LOBsexceeds our limit of 10 whilestarting the Synchronizerservice. Only those LOBs thathave previously been syncedwill be synced again. Pleaseremove the others listed in theerror log as not synced.Reducing the number of LOBstomeet the limit will remove thiserror.

After start up, the number of LOBsexceeds 10

VCSS016E

If you add LOBs after theSynchronizer started and thetotal number of LOBs exceeds10, the Synchronizer does notsync these additional LOBs andgenerates an error in the logsVerify the total number of LOBsdefined in the Vault does notexceed 10.

Failed to initialize Conjur Client withexception of typeSystem.Net.WebException andmessage The remote server returnedan error: (401) Unauthorized

VCSS006E

The Synchronizer Conjur host’scredentials that are stored in theConjur host account in theConjurSync safe are incorrect.Verify that you can login from aConjur CLI with the credentialsstored in the account by runningthese commands:

conjur authnlogout

conjur authnlogin<HostNamefield of theaccount>

When prompted for an API key,use the password of theaccount.The account’s credentials arecreated at the end of the




installation process, and arestored insynchronizerConjurHost.xml.For details on creating theConjur host account, see Postinstallation, page 10.

Failed to initialize Conjur Client withexception of typeSystem.Net.WebException andmessage The remote server returnedan error: (404) Not Found.

VCSS006E

The Synchronizer Conjur host’sApplianceUrl that is stored in theConjur host account in theConjurSync safe is incorrect.Verify that the value ofApplianceUrl contains the URL:

https://<ConjurServer DNS>/api

Accounts are not syncing The Synchronizer is running butnot syncing to Conjur. If you seein the logs these lines:

2018-04-17 15:19:14,865[6] [main] INFOVaultConjurSynchronizer.Synchronizer - VCSS003IRefreshing accounts fromthe vault - start2018-04-17 15:19:14,865[6] [main] INFOVaultConjurSynchronizer.Synchronizer - VCSS003IRefreshing accounts fromthe vault – end

And not:

2018-04-17 15:28:07,770[6] [main] INFOVaultConjurSynchronizer.Synchronizer - VCSS003IRefreshing accounts fromthe vault - start2018-04-17 15:28:10,770




[9] [LOBUser_ops] INFOVaultConjurSynchronizer.Synchronizer - VCSS008ISyncing LOB – start2018-04-17 15:28:30,770[9] [LOBUser_ops] INFOVaultConjurSynchronizer.Synchronizer - VCSS008ISyncing LOB – end2018-04-17 15:28:37,770[6] [main] INFOVaultConjurSynchronizer.Synchronizer - VCSS003IRefreshing accounts fromthe vault – end

This indicates that theSynchronizer is refreshing butnot syncing any LOBs becausethe LOB User account is notconfigured correctly.Verify that the account is storedin the ConjurSync safe, and thatthe account name (and theusername) start with“LOBUser_”.

Failed to perform synchronization withexception of typeCyberArk.Services.Exceptions.VaultConnectionEndedException

ITACM012S

If you encounter this error in theDR environment, wait a fewminutes until the vault DRbecomes the active vault.

Failed to perform synchronization withexception of typeCyberArk.Services.Exceptions.TimeoutHasExpiredException

ITACM012S

If you encounter this error in theDR environment, wait a fewminutes until the vault DRbecomes the active vault.

Prior ReleasesThe following tables contains links to prior releases of Vault Conjur Synchronizer.

Version Supported Conjur Enterprise Download

10.3 v.4



Version Supported Conjur Enterprise Download

10.3.1 v.4

10.4 v.4v.5

10.5 v.4v.5

10.6 v.5



Vault-ConjurIntegration - CyberArk Docs€¦ · 3 InternalandConfidential CyberArk...

Documents

Transcript of Vault-ConjurIntegration - CyberArk Docs€¦ · 3 InternalandConfidential CyberArk...