Process Dormant accounts

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

Hi All,

We need to implement a process around the dormant accounts. Basically, disable account for users who have not logged in for more than 180 days. What are the best practices and best approach to achieve this.

We tried the Workflow route but the challenge is that the identity profile configuration has the account enablement configured for active lifecycle state. Has anyone else encountered the same issue?

Thanks.

2

Hello,

There are several ways you could try this, but if you don’t want to get stuck on LCS-Active enabling those accounts you need to configure your LCS logic and states for dormant accounts:

  • Create an Identity Profile attribute that fetches the AD lastLogon value for all AD accounts (or whatever system you have). Use this attribute and build logic around it with a new Lifecycle State → LCS == “dormant”. Then confiure disable account logic normally via LCS page. (You can also use the AD attribute directly in your LCS transform but might be better to handle in a separate identity attribute first.)
  • dormantLCSLogic → check lastLogon >180 days since today → disable account.
3

HI @Swegmann,

we dont want a new LCS for following reasons - we have multiple domains and an active user may also have dormant account on one or more of these domains.

So if we put such user in dormant LCS, we are essentially putting an active user in dormant LCS, which does not seem right.

Also, if we want to implement this on multiple domains, that may not be a feasible solution.

Thanks.

4

Hi Naman,
You should treat dormancy at account-level condition instead of lifecycle state. Single user can have multiple accounts across domain, using new life cycle state would incorrectly mark active account as dormant.

I would track last login date on each account, evaluate if account is dormant since 90 days using schedule task and disable only specific that account. With this approach identity will remain active and only dormant account from specific domain will get disabled.

5

Hi @namangpt ,

You may have a look at the below demo presented during one of the develper days. It will help you achieve the use-case.

For cloudlifecycle state changes, i would not be too concerned about it this approach works on setting an identity attribute and then during identity refresh these case where account have not been disabled will be captured automatically and then can be disabled.
Please check and let me know if this helps

Regards
Vikas.

6

Hello,

There are following options.

Option 1 –> Using Seperate LCS state

  1. Create a separate LCS state
  2. Use the AD account attribute of lastLogin for deciding the LCS state.
  3. Once the LCS state is changed, we can Disable the AD account

Option 2 –> Using Workflow

  1. Create a new Identity attribute named as “Dormant Days“
  2. Against the above identity attr, create a transform which will populate the value in “No. Of Days“ format using lastLogin AD attribute
  3. If the value “Dormant Days“ identity attribute is equals to 180 or greater than 180, through the ISC workflow, call the Disable account operation of AD.

Thank You,

Regards,

Rohit Wekhande.

7

@namangpt Are you trying to implement dormant process for AD accounts ?

8

Hi @ravindrthakkar, thanks for the suggestion. However, my main concern here is the re-enablement of account. How do we stop ISC from re-enabling the account? We have the configuration on identity profile to enable the accounts for active users.

Thanks

9

Hi @kompala, thats correct.

10

HI @rohit_wekhande, thanks for the suggestion. Option 2 seems more feasible as option 1 has a limitation that we wont be able to handle inactive accounts for active users, especially in case of user having multiple accounts.

However, my main concern here is the re-enablement of account. How do we stop ISC from re-enabling the account? We have the configuration on identity profile to enable the accounts for active users.

Thanks

11

@namangpt Be aware of the attribute you are reliant on getting the lastlogin value. Since you are connecting to one DC, that value gets synchronized in 14 days only from other DC’s. Also if you have Azure SSO, check if the value is synchronized as well otherwise you will be calculating the wrong value.

Also, only if LCS changes enable gets enforced, otherwise the inactive account remains inactive if the identity remains in the same LCS, correct ?

The best way is to create an automation job outside of SailPoint to retrieve values from multiple places to calculate the 180 days correctly, otherwise you need to consider the synchronization delay as well.

12

Hello @namangpt ,

You can intercept the “ENABLE ACCOUNT“ operation in Before Provisioning Rule and Remove the Enable Operation from provisioning plan. In this way, you can curb the execution of Enable account operation getting sent to AD.

13

HI @rohit_wekhande, thanks. Yes, that’s what we are planning to do if there is no other way.

We will be updating some attribute in AD using API from workflow, and then use that attribute to check if the account is disabled due to inactivity, if so, change the enable operation to disable.

14

Hi @vguleria, this was really informative, thanks for sharing.

15

Hi @namangpt,
1 - Create an identity attribute that notes last log in time. Sync that to an AD source atttribute that is not being used. Powershell script on the IQ server that supports that domain that disables said AD account
This will get very messy when you take into account all of the AD domains, and really only works for single digit AD domains.

2 - Powershell script on the IQ server that supports the AD, that runs on a daily schedule. Monitors the ‘lastLogonTimestamp’ attribute which is set by the AD, and disables the account.
Takes the processing weight off of Sailpoint in its entirety, and you don’t have to worry about the LCS as that won’t do anything on an identity refresh, they only trigger on a LCS change.
Also, very easy to replicate across all ADs