Best Way to Prevent AD Account Deletion via SailPoint (Set ProtectedFromAccidentalDeletion)

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

Hi Community,

We’re looking for guidance on the best way to prevent Active Directory (AD) accounts from being deleted when certain conditions are met in SailPoint Identity Security Cloud.

Goal:

When an identity enters the “lithold” lifecycle state, we want to ensure the corresponding AD account is protected from accidental deletion by setting the ProtectedFromAccidentalDeletion flag on the AD user object.

Question:

What is the best approach in SailPoint to achieve this?

  • Can this be handled using a workflow, that updates the AD object?
  • Can aggregation via the AD connector import the ProtectedFromAccidentalDeletion attribute?
  • Is it more appropriate to use a rule (e.g., an Afte or BeforeProvisioning Rule for the AD connector) to detect the lifecycle state and update the AD attribute accordingly?
  • Has anyone implemented a similar control and can share design patterns or lessons learned?

We’d appreciate any recommendations or code examples to help implement this safeguard properly.

2

Are you noticing accounts being deleted while in this lifecycle state, or are you looking to proactively prevent deletions as soon as an identity enters that state?

3

Hi,

We use a separate AD OU for “LegalHold” as we call it. If we place the user into the “LegalHold” OU, their lifecycle state becomes “LegalHold” in ISC. Our final lifecycle state called “Terminated” will only delete accounts that are 14 days past their End Date and in the “Disabled Accounts” OU. So, accounts that are in any OU besides Disabled Accounts OU, are effectively protected from Deletion.

For extra context, under a typical Leaver scenario, the Identity goes from Active to Inactive (which disables their accounts and moves their AD account to the “Disabled Accounts” OU). 14 Days later, they would enter the “Terminated” Lifecycle State and the accounts would be deleted.

4

The key is to ask the AD owners what functionality THEY want. They own AD and can make the best determination for their system just like you’d want to do for all other systems.

Personally I prefer a NO DELETE of all accounts and especially in AD where orphaned accounts can create other issues with ACLs. My preference to deletion is a “tombstone” OU the accounts can be moved to but isn’t read via the AD source so they look deleted to ISC but remain in AD.

1 Like
5

We’re looking to proactively prevent deletions as soon as an identitty enters that state

6

Hi @adebolu_omololu

ISC by default does not delete the AD objects or by that matter any accounts in any source. To achieve deletion, you need to make use of service standard before provisoning rule so as long as you are not using that you will be fine as ISC will not delete these AD object.

If you really want to make sure that once user reaches a particular CLS, it adds a particular attribute in AD, then you may make use of again the service standard before provisioning rule where you can setup an event trigger in below format.

{
{
                   "eventActions": [
                        {
                            "Action": "UpdateAttribute",
                            "Attribute": "ProtectedFromAccidentalDeletion",
                            "Value": "true"
                        }
                    ],
                    "Identity Attribute Triggers": [
                        {
                            "Attribute": "cloudLifecycleState",
                            "Value": "relevant_LCS",
                            "Operation": "eq"
                        }
                    ],
                    "Operation": "Create"
                },


}

But then again, i would agrue if it is really critical to not delete the accounts and prevent them from deletion then why do it only during users leaves and not from the begining of the account management i.e when the account is provisioning to AD. So for this you can have a static value in create account policy to ensure that it is always 1 or even use an identity attribute to sync this value and keep it always as 1.

Another option is also to make use to disabled OUs as fellow colleagues mentioned where you move these accounts when they are offboarded after certain period but above are the few methods you can choose.

One more possibility could be to make use of connector rule where you use the powershell script to update this attribute when the LCS is lithold.

So, there are many possibilities to achieve this but to me, i think if you start maintaining this attribute from creation time, that approach will be easier and that will ensure that account is not accidently deleted but if you are deleting these accounts then may be better to go for service standard before provisioning rule or may be use the connector rule to update this via PS script. You can also use UPDATE provisioning policy but that might trigger unecessary events so would not go for that.

I hope this helps.

Regards
Vikas

7

Per our business rules, Active Directory accounts are automatically deleted after a defined period. However, we have a requirement to prevent this deletion when the associated identity is in a ‘Lithold’ lifecycle state. To address this, we want to leverage the ProtectedFromAccidentalDeletion attribute in AD, which prevents the deletion of the AD object.

We’ve identified that:

  • ProtectedFromAccidentalDeletion is not a standard aggregatable attribute in SailPoint.
  • It can be set via PowerShell, but we’re exploring alternatives to PowerShell for enabling this flag.

Question:
Is there a way—other than PowerShell—to set the ProtectedFromAccidentalDeletion flag to TRUE on an AD account, possibly through a workflow, or a rule, when the identity’s lifecycle state is set to Lithold?

Appreciate any insights or implementation suggestions from those who’ve tackled similar scenarios.

8

Hi @adebolu_omololu

I would have preferred in this case after connector rule where we can use powershell script to do the work but as you are exploring other ways than powershell then i think we are left with only before provisioning rule where you intercept the lifecycle state of the user as ‘Lithold’ and then add a value in the provisioning plan for ProtectedFromAccidentalDeletion attribute.

But having said that you have also mentioned that this attribute is not a standard aggregated attribute then i am curious to see whether this will be provisioned via standard connector or not. But in general you can add new attributes to the schema and then try to run the aggregation and then this generally populate the attribute value from back-end application but you can check this. In general below will be my preference to achieve this.

  1. Apend the source schema and add this attribute ProtectedFromAccidentalDeletion in AD source and see if this is managed attribute. If it is getting aggregated then you can either have an identity attribute or play around with it in create and update provisioning policy to populate this value in AD.

  2. Use after Connector rule where you can pass the LCS of the user in arguments and thus use the powershell script to do the provisioning.

  3. Use the cloud rule to append provisioning plan and add this attribute value based identity LCS.

  4. Another option could be that you populate some other custom attribute in AD for these users and based on which in AD there can be some logic defined to populate this attribute.

Workflows unfortunately does not have direct way of handling it unless you want to play around with attribute sync configuration and then run workflow to update this attribute on account level such that it triggers sync but then again it will depend on standard connector as mentioned in point 1.

I hope this helps.

Regards
Vikas.