Hello Experts,
I’m currently analyzing the Delinea integration with ISC, specifically for onboarding privileged accounts. Apart from the out-of-the-box documentation, we haven’t found detailed information regarding the available capabilities.
Could you please advise on what can be achieved in terms of application onboarding or integration with IdentityNow.
Thanks
I, too, am interested in that information. I even hit up my CSM to see if we could do a POC so I could see the capabilities of the connector, but no dice. We are looking to see what level of granularity we can get with the connector as far as who has which rights to which folder, so we can perform certifications on that.
Hello,
Could you please confirm which Delinea architecture you are using, on-premises or cloud?
The supported capabilities may vary depending on the architecture and the connector type being used with ISC (IdentityNow).
You can also verify the officially supported features in the “Supported Features” tab within the SailPoint connector documentation for Delinea. This section outlines what is available in terms of:
-Account aggregation
-Provisioning (create / modify / disable)
-Entitlement management
-Access requests
Once we understand which architecture you are working with, I can provide more specific guidance on what is achievable for privileged account onboarding.
Thanks.
When you say “onboarding privileged accounts”, you mean for actually creating secrets in folders for other users to access, correct? This is notably distinct from creating and provisioning user accounts for people to access those secrets.
The out-of-box connectors are built around the latter use case.
Since they use the SCIM endpoints, they’re designed to interact with the /Users and /Groups resources. They don’t use the /PrivilegedData resource (which would be used to create secrets) and the only interaction they have with the /Containers and /ContainerPermissions resources is for linking permissions on the entitlements on the SailPoint side, which would be groups.
In my case Delinea Cloud
Are you on Secret Server Cloud or Delinea Platform? I don’t think they even have a connector for the platform currently.
same as we have cloud too
I’ve worked with both Delinea Cloud (Secret Server Cloud) and on-premises Secret Server integrations with ISC.
In both scenarios, we were able to perform full lifecycle management of local PAM users.
In the on-premises implementation, we integrated Secret Server with Active Directory.
After provisioning the AD group through ISC, the user creation and folder access assignment in Secret Server were handled automatically via the AD integration.
This approach worked very well, as access control was driven by AD group membership rather than directly provisioning folder permissions from ISC.
For Secret Server Cloud, you can review the officially supported capabilities here:
Please make sure to check the supported connector version and confirm it matches the product version you are currently working with.
With Secret Server Cloud, it is possible to manage the user lifecycle end-to-end via ISC, including:
If you are evaluating a design where access groups are created directly in IdentityNow and then provisioned dynamically into Secret Server Cloud, this may not be natively supported by the standard connector.
In most implementations, IdentityNow manages users and their group memberships, while the structural management of access groups within Secret Server is handled directly inside Delinea.
If dynamic group creation from ISC is a requirement, it may require:
I would recommend reviewing the supported feature set carefully and, if needed, evaluating whether this requirement should be handled outside of IdentityNow.
@richard_rocha, do the folders that a user has access to appear in ISC as entitlements? Our audit team would like a way to determine who has access to which secrets, and while I figure that level of granularity is unlikely, showing access at the folder level should be sufficient.
I have a demo tenant but I haven’t looked at it yet. If it works anything like the CyberArk connector does (both are SCIM-based), the permissions on the entitlements will just show you the folders
“Aggregate container permissions as direct permissions” means it’s hitting the /ContainerPermissions SCIM resource which will show what folders (Containers) a group has access to.
In order to show the accounts a user effectively has access to, you have to bring in data from the /PrivilegedData endpoint and marry that up with the /Containers and /ContainerPermissions to answer “what account does this grant access to?”
Sailpoint doesn’t do that with the CyberArk connector and I’m willing to bet it’s the same with this one
Just as an example, here’s what the permissions look like on the CyberArk connector I built compared to the OOB SailPoint connector. I did some extra work to ensure that the effective access to accounts is displayed as well as the safes they reside in. I’ll probably end up doing the same thing for a secret server connector
It works very similarly to CyberArk, as @mcheek mentioned.
In ISC, you can aggregate the groups from Secret Server, and those groups will appear as entitlements. Then, within the Permissions tab of the entitlement, you are able to see which folders that specific group has access to.
So while you may not get secret-level granularity directly as entitlements, you can determine folder-level access by reviewing the permissions associated with each group.
This approach typically satisfies audit requirements when folder-level visibility is sufficient to demonstrate who has access to which areas within Secret Server.
@richardnrocha & @mcheek , just to be clear, this is only available on the Delinea specific connector, right? Currently, we are using the generic SCIM connector.
From my experience, yes, that capability is available through the Delinea specific connector.
If you are currently using the generic SCIM connector, the behavior may be different. The SCIM connector typically supports standard user and group provisioning, but it does not always expose application-specific permission structures (such as folder-level mappings) in the same way the dedicated connector does.
If it is technically possible to expose that information via SCIM, it would likely require some level of customization to include folder relationships within the SCIM schema.
