Use case:
On user employment/association with organization is terminated, the account and access removal should be handled in the below sequence.
Disable accounts in target application on Day 0/last working day
Remove all access assigned to the account on Day 30
Delete account on Day 60.
In case if a user got rehired within 30 days do not remove access.
In case if a user got rehired within 60 days do not delete account.
Justification/Business requirements:
Users may get rehired within 30 days or 60 days, in such case users should be able to use the account created earlier without having to go through the approval process again to get required access (retaining access if the user returns within 30 days). This specifically reduces wait time if the application is integrated with SSM in disconnected mode.
Frequent offboarding and rehiring Casual workers or part time workers or contractors depends on the nature of work performed by such works. For example, an external vendor who gets access only required and gets offboarded from IT systems as soon as the work is completed. This vendor user may need access in case if any maintenance work is involved. In such cases where the vendor needs access only for a limited period of time and need not to go through approval process to get access setup.
Solution:
This requirement can be address actionable analytics but it involves writing SQL queries and client must be good in writing sql queries. A wrong sql query may add heavy load on application servers and RDS which may lead to application outage and impact on application availability/SLA. Also this requires careful editing of queries for any future maintenance.
SSM version 5.5 above provides OOTB future-dated tasks generation functionality which will be used to address this requirement.
Configuration item 1:
On the global configurations – Common – turn on ‘Discontinue Pending Task on User Rehire’. This option will drop/discontinue the pending remove access tasks and delete account tasks if the user gets rehired before the task execution date. This will help to avoid users to raise access requests to get the access reinstated.
Configuration item 2:
Create 2 user update rules.
One rule to disable account & remove access and another rule to delete account. Both remove access and delete accounts are handled by the same action and you can’t have the same action more than once in a rule so suggested to create 2 separate rules.
1. Create a rule 1 and the example is
Rule name: User Termination - Day0 - StatusKey Check
Trigger Actions when: Trigger when user is updated from import or API (depends on your implementation)
Condition: if user statuskey updated and statuskey=0
Action:
Disable user account on endpoints (select either all or the end points you wanted to include) and day when to execute
Deprovision access (select either all or the end points you wanted to include), select access only on the 3rd dropdown box and day when to execute
