Back to the IdentityIQ 7.3 overview: What's new in IdentityIQ 7.3
IdentityIQ version 7.3 continues to build out a robust Privileged Access Management (PAM) solution, by adding credential cycling to IdentityIQ's support for PAM.
The Identity University eLearning course on IdentityIQ 7.3 New Features includes a detailed lesson on enabling credential cycling. The course is available in early September 2018.
Important: For the most up-to-date information about configuring and using the PAM module, refer to the IdentityIQ product documentation on PAM.
At a high level, credential cycling is a feature that allows applications which require credentials (such as username and password) to obtain that information directly from a PAM source, such as a CyberArk or Beyond Trust solution. Previously, these credentials had to be set up in the application definition manually, and if any information changed in the PAM solution, those changes had to be made manually in IdentityIQ by an administrator. With IdentityIQ 7.3, the credential cycling feature lets credentials be pulled directly from the PAM vault at runtime, with no manual intervention (other than initial configuration) by the IdentityIQ administrator, adding both security and convenience.
With version 7.3, you can manage credentials solely within your PAM solution. Essentially, an administrator defines which applications will use credential cycling, which PAM solution provides those credentials, and how each of the applications will contact the PAM vault to retrieve the credentials. This is done via a configuration file that is imported into IdentityIQ as an object.
Here is a brief summary of how credential cycling is configured in IdentityIQ. A more detailed look at the template and the configuration options is provided in a later section.
[IdentityIQ installation directory]\WEB-INF\config\credentialConfigurationTemplate.xml
The credentialConfigurationTemplate.xml is located in the WEB-INF\config directory of your IdentityIQ installation.
The template file includes sections for BeyondTrust, CyberArk, and a solution-neutral direct attribute mapping option. If you are using a PAM solution other than BeyondTrust or CyberArk, you can use those sections of the template as a model for configuring another PAM solution.The file is fully commented, to provide guidance as you insert your configuration settings.
Here are some key points to observe when you work with the BeyondTrust portion of the template:
Note that to enable credential cycling with the BeyondTrust PowerBroker Password Safe application, passwords must be configured in the JSON format. For example:
{"bt_user":"MyUserName","bt_password":"MyPasswordValue"}
In the Credential Source section, you configure
In the Credential Association section, you configure
<CredentialSource credentialClass="sailpoint.pam.credential.BeyondTrustCredentialManager" name="beyondTrust ">
<!-- The attributes in this map are used mainly to communicate with BeyondTrust.
Any values here can be overridden by values of the same name in the attributes
map of each credential association. Required attributes must either be configured
here or in every credential source. Attributes:
Required: url
Required: runas
Required: apikey
Required: managedSystemName
Required: managedAccountName
Optional: durationMinutes
Optional: credentialCacheMinutes
Optional: checkInReason
Optional: checkOutReason
-->
<Attributes>
<Map>
<entry key="url">
<value><String>https://your.beyondtrust.server/BeyondTrust/api/public/v3/</String></value>
</entry>
<entry key="runas">
<value><String>runas_user</String></value>
</entry>
<entry key="apikey">
<value><String>your_BeyondTrust_api_key_goes_here</String></value>
</entry>
<entry key="managedAccountName" value="beyond_trust_managed_account_name"/>
<entry key="managedSystemName" value="beyond_trust_managed_system_name"/>
</Map>
</Attributes>
<!-- ***Application Configuration -->
<CredentialAssociation applicationName="application_name"
attributeName="application_username_attribute"
credentialAttributeName="bt_user">
<!-- *** Attribute values go here. These attributes can be used to override values from
*** above, or can be left out if not needed -->
<Attributes>
<Map>
<entry key="managedAccountName" value="special_beyond_trust_managed_account_name"/>
</Map>
</Attributes>
</CredentialAssociation>
<CredentialAssociation applicationName="application_name"
attributeName="application_password_attribute"
credentialAttributeName="bt_password"/>
</CredentialSource>
CyberArk implementations require the installation of CyberArk’s Credential Provider API. The Credential Provider API enables passwords that are stored in CyberArk Digital Vaults to be retrieved by IdentityIQ. This API must be installed on the same server IdentityIQ is installed on.
Note that the Credential Provider API is NOT the same as CyberArk’s Central Credential Provider, which provides access to the Digital Vault via web services. For full details on how to obtain and use the Credential Provider API, please refer to CyberArk’s documentation.
IdentityIQ uses the “Application Hash Value” method of authenticating to the API; other methods of authentication will not work. Verify connectivity to the CyberArk Digital Vault using the command line clipasswordsdk before attempting to construct the attributes of the Credential Cycling Configuration object.
Note: For more information, refer to CyberArk’s Credential Provider and ASCP Implementation Guide.
First, ensure that you have extracted the pam-credential.jar file from the identityiq.war. If you have deployed IdentityIQ using the "exploded" form of the war file, you don't need to take any extra steps to extract the pam-credential.jar file; however, if you are not using this deployment strategy, you will have to extract the pam-credential.jar from the identityiq.war file, perform the steps below, then repackage the pam-credential.jar back into the identityiq.war file.
Here are some key points to observe when you work with the CyberArk portion of the template.
In the Credential Source section, you configure
In the Credential Association section, you configure
<CredentialSource credentialClass="sailpoint.pam.credential.CyberArkCredentialManager" name="cyberark">
<!-- The attributes in this map are used mainly to communicate with CyberArk.
Any values here can be overriden by values of the same name in the attributes
map of each credential association. Required attributes must either be configured
here or in every credential source. Attributes:
Required: safe
Required: folder
Required: appId
Required: object
-->
<Attributes>
<Map>
<entry key="safe" value="cyber_ark_safe_name"/>
<entry key="folder" value="cyber_ark_folder_name"/>
<entry key="appId" value="cyber_ark_app_ID"/>
</Map>
</Attributes>
<!-- *** Application Configuration -->
<CredentialAssociation applicationName="application_name"
attributeName="application_username_attribute"
credentialAttributeName="CyberArk_username_attribute">
<!-- *** Attribute values go here. These attributes can be used to override values from
*** above, or can be left out if not needed -->
<Attributes>
<Map>
<entry key="object" value="object_value"/>
</Map>
</Attributes>
</CredentialAssociation>
</CredentialSource>
Here are some key points to observe when you work with the mapping portion of the template:
In the Credential Source section, you configure your actual credential values, since you are not connecting to a third-party PAM source. It is a good practice to use encrypted passwords in this section.
The Credential Associations settings connect the values in the Credential Source section to your applications as shown in the template XML below.
<CredentialSource credentialClass="sailpoint.pam.credential.MapCredentialManager" name="mapCredManager">
<!-- The attributes in this map are the values that will be returned by the map credential manager.
It's probably a good idea to encrypt these so they are not stored in plain text if the values
are sensitive -->
<Attributes>
<Map>
<entry key="credentialValues">
<value>
<Map>
<entry key="map_username_attribute" value="john_doe_username"/>
<entry key="map_password_attribute" value="super_secret_password"/>
</Map>
</value>
</entry>
</Map>
</Attributes>
<!-- *** Application Configuration -->
<CredentialAssociation applicationName="application_name"
attributeName="application_username_attribute"
credentialAttributeName="map_username_attribute"/>
<CredentialAssociation applicationName="application_name"
attributeName="application_password_attribute"
credentialAttributeName="map_password_attribute"/>
</CredentialSource>
When credential cycling is configured for an application, the Application Definition UI shows a message to indicate this. Although the relevant credential fields (in this example, Connection User and Connection Password) are still marked as requiring values, these fields are not validated when credential cycling is enabled, and so can be left blank, or can include dummy values.
Hi,
I posted this question in the community about Credential Cycling and hoping someone can take a look. I have the same general question as everyone, What is the syntax to refer to a non-standard username or password attribute in our application config?
Also, can credential cycling be used for other objects other than Application like a Custom object or IntegrationConfig?
https://community.sailpoint.com/t5/IdentityIQ-Forum/SailPoint-s-MapUtil-API/m-p/264568#M193728
I use Active Directory accounts for some SailPoint connectors. I am able to get the password from CyberArk for Domain and Forest User, but i am unable to get the password for IQService Credentials for the same connectors. Is this possible?
<CredentialAssociation applicationName="TestIIQ" attributeName="IQServiceConfiguration[IQServiceUser=Domain\\USER;].IQServicePassword" credentialAttributeName="Password">
<Attributes>
<Map>
<entry key="object" value="VALUE"/>
</Map>
</Attributes>
</CredentialAssociation>
Has anyone gotten this to work for the IQService user?
@mwill Yes, the configuration is actually quite simple. Below is for use with CyberArk, hope it helps.
<Configuration name="CredentialConfiguration">
<Attributes>
<Map>
<entry key="sources">
<value>
<List>
<CredentialSource credentialClass="sailpoint.pam.credential.CyberArkCredentialManager" name="cyberark">
<Attributes>
<Map>
<entry key="appId" value="YourAppIDHere"/>
<entry key="folder" value="root"/>
<entry key="object" value="Cyberark Object Name"/>
<entry key="safe" value="Cyberark Safe Name"/>
</Map>
</Attributes>
<CredentialAssociation applicationName="TestIIQ" attributeName="IQServicePassword" credentialAttributeName="Password"/>
</CredentialSource>
</List>
</value>
</entry>
</Map>
</Attributes>
</Configuration>
Hi All,
We have successfully configured credential recycling for our Active Directory application by following the steps outlined in the relevant article. We imported the CyberArkConfigurationTemplate with all the necessary CyberArk details, and the import was successful. The message 'Credential Cycling is enabled for AD application definition' is visible, indicating that the configuration is recognized.
However, when we leave the username and password fields blank in the configuration settings page, we encounter an error stating that these mandatory fields must be populated. After filling in these mandatory fields, the test connection works, but the credentials are being sourced from the configuration settings rather than being retrieved from CyberArk CP as intended.
We have verified through the CyberArk CP logs that CyberArk CP is capable of retrieving the credentials. Despite this, the AD application within IdentityIQ is not utilizing the credential recycling process to obtain the credentials from CyberArk.
Could anyone provide insights into what steps we might be missing or any additional configurations required to ensure that the AD application correctly uses credential recycling to fetch credentials from CyberArk?
I'm assuming that you misconfigured the CredentialConfiguration object. The "Credential Cycling is enabled for this application." message will appear as long as the CredentialConfiguration object has at least one CredentialAssociation with the given applicationName, but it does not validate that you configured the attributeName correctly. I will say that this seems to be because the documentation does not specifically call this out. Essentially, since the application configuration can have multiple entries with the same attribute name (especially AD apps), you need to ensure the attributeName uses dot notation to traverse the map to the exact attribute you want replaced (kind of like what you need to do to reference form model attributes).
With that said, if your attributeName is just "user" for AD, it will not work because the AD apps can have multiple "user" or "password" entries since you can have multiple domains and forests. You will need to use dot notation to traverse the map to the exact entry. For example, you can use your domainDN as the way to specify the exact user entry you want to replace. If your domainDN is: "DC=testLab,DC=org", you can use the following entry in the CredentialConfiguration object:
The """ is necessary because we need to escape the quotes in the CredentialConfiguration XML object.
Cheers!
Eric Mendes, MS (Cybersecurity), CISSP
Senior Identity Architect
MajorKey Technology
Hi @Eric_Mendes_CISSP ,
Thank you so much for taking the time to respond to my comment. Could you please clarify if my understanding is correct as outlined below?
If my domain name is abc.internal.com, then the credential association would be:
<CredentialAssociation applicationName="AD"
attributeName="domainSettings[domainDN="DC=abc,DC=internal,DC=com"].user"
credentialAttributeName="password"/>
<CredentialAssociation applicationName="AD"
attributeName="forestSettings[domainDN="DC=abc,DC=internal,DC=com"].user"
credentialAttributeName="password"/>
My pleasure!
Yes, that looks correct to me. I would think that the credentialAttributeName would be "user" instead of "password", but that might just be a placeholder on your part.
Cheers!
Eric Mendes, MS (Cybersecurity), CISSP
Senior Identity Architect
MajorKey Technology
Hi @Eric_Mendes_CISSP ,
Firstly, thank you very much for your prompt response. Secondly, we are still encountering issues with credential cycling for the AD application using CyberArk. The error message we receive is as follows:
[ InvalidConfigurationException ] [ Possible suggestions ] Ensure that the Active Directory Service is up and running. [ Error details ] Failed to connect to - dc=abc,dc=xyz,dc=com : [LDAP: error code 1 - 000004DC: LdapErr: DSID-0C090DA9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4f7c]
I can confirm that the domain controllers are accessible from the IdentityIQ server on ports 389 and 636. Below is the credential configuration file we are currently using. Any assistance in resolving this issue would be greatly appreciated.
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sailpoint PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<sailpoint>
<!-- NOTE the attribute values contained in the credential sources and credential associations may be encrypted -->
<Configuration name="CredentialConfiguration">
<Attributes>
<Map>
<entry key="sources">
<value>
<List>
<!-- REMOVE IF NOT CONFIGURING CyberArk
Start of CyberArk Credential source Configuration -->
<CredentialSource credentialClass="sailpoint.pam.credential.CyberArkCredentialManager" name="cyberark">
<Attributes>
<Map>
<entry key="safe" value="safe name"/>
<entry key="folder" value="root"/>
<entry key="appId" value="App ID"/>
</Map>
</Attributes>
<!-- *** Application Configuration -->
<CredentialAssociation applicationName="AD"
attributeName="domainSettings[domainDN="DC=abc,DC=xyz,DC=com"].user"
credentialAttributeName="password">
<Attributes>
<Map>
<entry key="object" value="object name from CyberArk"/>
</Map>
</Attributes>
</CredentialAssociation>
<CredentialAssociation applicationName="AD"
attributeName="forestSettings[domainDN="DC=abc,DC=xyz,DC=com"].user"
credentialAttributeName="password">
<Attributes>
<Map>
<entry key="object" value="object name from CyberArk"/>
</Map>
</Attributes>
</CredentialAssociation>
</CredentialSource>
</List>
</value>
</entry>
</Map>
</Attributes>
</Configuration>
</sailpoint>
We managed to resolve the issue. The problem was with the Credential Association. In the XML configuration, we had specified two credential associations: one with the domain settings and another with the forest settings. After removing the forest settings, the configuration worked correctly. It appears that only the domain settings are necessary.
If possible could you please provide a sample XML configuration for setting up an Entra ID application to use CyberArk Credential Provider (CP) to retrieve secrets from CyberArk?
My pleasure! Yeah I would recommend that you configure the credential associations to only replace the static values you already configured in the application XML. If you are not currently providing credentials to the forest configuration, then there is no need to have credential cycling input a value, otherwise, you might get weird errors.
Regarding Entra/Azure, you would follow the same steps as on the on-prem AD. First, configure the application so that it works as expected when inputting static credentials. Then go into debug and find the entry names for the values you provided and then place that in the credential associations. Entra/Azure looks to be even easier because the credentials seem to be stored at the root of the application attributes, therefore, you can just reference them by name in the credential association. For example, if you configure a client ID, then it can be referenced as "clientID".
Eric Mendes, MS (Cybersecurity), CISSP
Senior Identity Architect
MajorKey Technology