CyberArk PAM- Eliminate Hard Coded Credentials using Java REST API Calls

Still in many Organization hard coded credentials are stored in Application config files for making application-to-application connection, in scripts (ex: scheduled tasks) and config files. Generally, these are high privileged service accounts and its passwords are set to be never changed.
Keeping hard coded credentials always risk to the organizations security posture. CyberArk provides a solution called Application Identity Manager using which, the passwords of Privileged Service Accounts can be stored centrally in Password Vault, logged, rotated and retrieved in many different ways.
CyberArk supports two approaches to eliminate hard-coded credentials, which are;

  1. Credentials Provider (CP). This required an agent needs to be installed on each server where the application or script is running.
  2. Central Credential Provider (CCP).

In this post I’m giving more details on how to retrieve credentials via CCP using Java REST API call. Applications that require credentials to access a remote device or to execute another application remotely can request the relevant credentials from the CCP via REST or SOAP calls.

Pre-Requisites:The CCP installation consist of two parts, which are;
1) Credential Provider for Windows ( 2012 R2, 2016)
2) Install the Central Credential Provider web service (IIS 6, 7.5, or 10)
Client Requirements:
The Central Credential Provider works with applications on any operating system, platform or framework that can invoke REST or SOAP web service requests.
CCP Supported Client Authentication:
1) Client certificates
2) The address of the machine where the application is running
3) Windows domain Operating System user
In this example I’ve used Java to make REST API call to CCP Web Services using Certificate and Client IP authentication. This approach will work with any programming languages like .Net, Python, PowerShell etc.
1. On board Required Application into CyberArk via Password Vault Web Access (PVWA) Web Portal.
2. Create Required Platform and Safe.
3. On-board Required Privileged Service Account into CyberArk via PVWA
4. Add Application we have created in step1 as the member of this Safe with Retrieve permission enabled
5. Add Provider Users as a member to the Safe, which was created as part of CCP initial installations.
6. Add the Certificate into CCP’s IIS server, the same certificate will be used for client authentication
7. Add the certificate into java keys store using Java key tool command
8. Run the java Code.
On-board Application => Login to PVWA =>Go to Application Tab =>Add Application : provide Application name, Owner and other details. Go to Allowed machine Tab=> Enter the IP Address of the machine where the java code is running. I’ve also added time restriction which ensures credentials will be released only within the time limit after the successful authentication.

Create Platform and Safe: Login to PVWA =>Go to Administration=>Platform Management => Select Windows Domain Accounts => Duplicate it and modify according to the Password requirements.

On-board Account and Add Members: Login to PVWA =>Go to Accounts => Account View => Add Account => Enter the actual Privileged Account details by selecting the Safe and Platform we have created in the previous steps. In this example I’ve chosen AD as my target account but we can any platform accounts as per the need since CyberArk support all most all of the platforms.

Add Application as a Safe Member: Login to PVWA =>Go to Policies =>Access Control =>Select the Safe=> Edit members => Add Application as member with Retrieve permissions and Add Provider user with Retrieve and List permissions

Add Certificate into IIS Server: Either we can use Self Signed or CA Signed client Certificate. I’ve added a signed AD Domain certificate for PVWA SSL connection, so I’m going to use the same certificate into my Client Java code. To add Certificate into Java key Store: I’ve java installed in my client machine ( where my java code will run to make REST API calls. The below key tool command must be executed via CMD.
keytool -importcert -storepass changeit -keystore "C:\Program Files\Java\jdk1.8.0_181\jre\lib\security\cacerts" -alias compsrv01 -file certnew.cer
Java Code:
Note : if you look at the java code there is no hard coded credentials or tokens used to authenticate into CCP, Its simply uses the certificate for authentication. 

Java Output: 

The outcome of the above REST API call will be a JSON and we can get
the user name, password (content) from it. These credentials will be dynamically referred in the target scripts,
applications which will then use the credentials to perform its tasks.

With Simple REST API calls, CyberArk Vaulted account’s credentials can be retried using combination of certificate and client server IP authentication. This will be helpful for eradicating embed hard coded credentials in the application config files, scheduler jobs, scripts etc.

Replace Personal Privilege Account into Shareable Broker Accounts

Most of the organizations still have the practice of Personal Privilege Accounts in their corporate platforms and application. It’s very challenging when comes to managing and monitoring those accounts which gives non-restrictive access to the most valuable systems in the Organizations. Effective procedures around managing these privileged accounts are extremely difficult without specialized tools.
CyberArk Privileged Account Management solution enable these organizations to secure, provision, manage, control and monitor all activities associated with privileged accounts present in their IT landscape.
One of the primary goals of implementing Privilege Account Management solution will be replacing personal privileged accounts with shareable broker Accounts. This will drastically reduce the total number of privilege accounts for each application and systems. And, these broker accounts will get the other benefits from CyberArk PAM solution for example, One Time Password, enforce corporate Password Policy, tamper proof audit trails etc.
Replace AD Personal Privileged Accounts into Shareable Broker Accounts
Typical CyberArk approach to replace Active Directory personal privilege accounts into shareable broker Accounts are graphically depicted in the below picture.
Note: Assume all green line connectors are the customization needed to implement this use case.
1) In this scenario, two new AD shared accounts (App_Broker_Acc1|2) are created and added as members of domain admin groups (after this implementation we can disable all the existing personal privilege accounts which are members of this group ex S-XXXX, S-YYYY)
2) A new AD group (PAM_Domain Admins) will be created specifically to map users normal AD id to CyberArk Safe (Safes are logical containers with in the CyberArk Vault). This will provide end user (289705, 289706) access to fetch password and initiate a session to target platforms.
3) The normal AD IDs of the administrators will be added as members of the newly created AD groups for PAM.
4) A Safe (AD_Domain Admins_Safe) will be created in CyberArk. The AD group (PAM_Domain Admins) which we’ve created in step2 will be made as member of this safe with required permission enabled.
5) On-board the Shared account which are created in Step 1 into CyberArk. These accounts will be stored under the Safe, which we have created as part of step 4.
6) Now the administrators will be able to logon to CyberArk Web Portal (PVWA) using their normal AD ID and then they can connect to the target platform by selecting a broker account without knowing its credentials.
7) Session initiated through shareable broker account without end user knowing its password.


Follow Us!

Kloud Solutions Blog - Follow Us!