Update Account attribute - Active Directory

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

Hi All,

Not sure if this has been covered in the past but all my searches in the forum come up with different results.

We have a request to update a specific attribute on the AD account with a datestamp that is then used by a downstream compliance process to ensure the account is linked to the SailPoint identity and is being managed.

In the past we have had cases with other provisioning systems where accounts are orphaned in AD even though it was expected that they were being managed through the legacy provisioning process.

In the “Update Account” policy of the source we originally added the following:

"name": "Update Account",
    "description": null,
    "usageType": "UPDATE",
    "fields": [
        {
            "name": "extensionAttribute5",
            "transform": {
                "type": "static",
                "attributes": {
                    "now": {
                        "type": "dateMath",
                        "attributes": {
                            "expression": "now/s"
                        }
                    },
                    "value": "$now (Updated by ISC)"
                }
            },
            "attributes": {
                "cloudRequired": "true"
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        },

However, what we found is that this only seems to trigger either if there is an update done by ISC due to some identity attribute change, or if a full Identity refresh is processed.

Ideally what we would like, as efficiently as possible, is to be able to update the value for all managed accounts at least 1 time every week, as randomly as possible in order to avoid updating every account on every execution.

Hopefully that makes some sense.

2

I would recommend avoiding the use of the “Update Account” policy whenever possible, as it is triggered during every Identity Refresh.

I have experienced with this issue when trying to use “Update Account” policy.

Based on your use case, it sounds like you need to update an attribute on a weekly basis to indicate that the account is managed by SailPoint, right ?

For this requirement, I would recommend using an Identity Attribute associated with Transform + Attribute Sync approach which the most used approach used for attribute synchronization on target system in ISC.

Like :

  1. Create an Identity Attribute, for example: ISCManagedAD.

  2. Attach a transform to this attribute with the following logic:

    • Read the current value of extensionAttribute5 from the user’s Active Directory account.

    • If extensionAttribute5 is empty or null:

      • Set the value to <current timestamp> (Updated by ISC).

    • If extensionAttribute5 already contains a value:

      • Parse the existing timestamp.

      • Check whether the timestamp is older than 7 days.

      • If it is older than 7 days:

        • Update the value to <current timestamp> (Updated by ISC).

      • Otherwise:

        • Keep the existing value unchanged.

  3. Configure Attribute Sync to map ISCManagedAD to extensionAttribute5 on the Active Directory source.

With that every time that ISCManagedAD is updated, it is automatically sync to extensionAttribute5 in AD.

Notes

Synchronizing an attribute across all identities on a regular basis may still be quite resource-intensive, especially when managing a large number of accounts.

I would suggest challenging the business requirement and exploring simpler alternatives, such as:

  • Setting a flag only once during account creation to indicate that the account is managed by SailPoint. Or Using an existing account attribute or governance object to identify SailPoint-managed accounts instead of updating a timestamp every week.

  • Generating a periodic SailPoint report listing all accounts currently managed by SailPoint.

3

Hi @roberto233 ,

  1. How many accounts do we currently have where the update is expected ?
  2. Also, is there a expectation that if the account is not linked to any identity then also the update should happen to the Active Directory Account ?

Thanks

4

We’re currently processing / managing approx. 30K identities through the platform.

In the ideal world we could assume that the AD object is linked and managed by SailPoint, however history has shown us in the past that humans tend to take the path of least resistance and unfortunately in our environment we still struggle with overprovisioned access. We have seen cases where engineers on site have added deny permissions on the user object for the ISC gMSA thus preventing ISC from disabling the object or syncing any attributes. This is just one scenario where we’ve seen identities being “orphaned” in various iterations of Identity management platforms.

Thus having a form of “Heartbeat” indicator on the AD object itself to confirm that ISC is still able to write to the object and has a source record for it, has been one of the only methods to ensure when a termination event is received that it will be actioned.

5

One alternative could be also to enable and report use ISC native change detection Enhancement: Native Change Detection - Announcements / Product News - SailPoint Developer Community

To regularly (during aggregation) identify and report all changes made outside of ISC.

If there are 30 k accounts, attempting to synchronize all accounts even a weekly basis would be very resource-intensive.

Or just add a before provisioning rule : that will set an attrbute lastSailpointUpdate in the plan for every operation on Active Directory.