Hi all, I have an scenario where client has an API for reading HR persons (with active or deactive status, vacations, medical leaves, etc). It always brings a list of all persons in json, so we can aggregate into identities with corresponding lifecycle state.
Problem arises for fired users, which they are not present on this list. Is some way to transfor this “absence” of user into a change in the lifecycle state?
I have to perform some things when this state is reached, for example, disable accounts, move AD account to an special OU, etc, that’s why I need the identity attributes to be present, and can not just delete identity.
Hi Gladstone! Problem is that I will not have info about who was fired, because they will not be present in the HR response. For example, today I receive HR accounts A, B and C. I will create idenitity and provision accounts for them. Tomorrow, C is fired, so aggregation will bring accounts A and B only. I do not realize that C is not present.
I though in making an WS after operation, reading all identities each time, and comparing to actual json response. If something is not present, I should add it to the returned json response. But as far as I read, idn does not have access to read IDN data model, right?
Thanks Gladstone! Yes, unoptimized should delete identities that does not appear on HR response, if delete threshold is active. But I still have this problem that identity should not be deleted, but changed to a “fired” lifecycle state. Also, when disabling account from AD, I will need also to move it to a special OU, with some parameters from identity.
I am trying to exhaust all ideas before asking client to modify their HR API, he wasn’t sure if he could do it.
Hi @jsosa , interesting use case I must say!
I understood you want to retain the identity for “fired” scenario, then how about the other scenarios where let’s say if the user leaves the organization and is removed from the HR source, do you also want them to be retained in IdentityNow?
Intent is to understand you want to retain all identities irrespective of their lifecycle state.
Hi @gauravsajwan1 For one side they need these identities to remain on IDN for auditing purposes. Also, I must perform certain actions on accounts, after event occurs. For example, as I can not detect that some user was fired, it should be not possible to use a powershell after operation rule to perform several actions on ad account, for example moving user to another OU, which is formed with user attributes. Just an as example, OU=deleted,OU=region,OU=cost_center,…
Hi @iamnithesh ! Unfortunately, HR Rest API simply returns working employees. Fired or living employees will not be present on next call to API. I think it leaves us with only 2 options: they add these users to API call, or add another endpoint to search for fired users. But as this two options goes to client’s side, we are not sure they will be able to do that.
We have a similar issue. Users that are no longer employeed are dropped from the authoritative source feed after 15 days of their end-date. If their termination is back dated they drop immediately on the next aggregation. We tried the option to not delete any accounts but then there is no event to cause a lifecycle state change which is needed to trigger the disablement of accounts. We looked at Workflows and didn’t find anything either. We ended up working with HR to change how the 15 days is determined. Instead of based on end-date it is also based on transaction date to keep it x days past either.
Also, if there is a new-hire that doesn’t show up it never makes it into the main feed so if they aren’t entered into the HR system within 2 or 3 days they automatically drop from the staging table and are deleted in SailPoint. Any accounts created aren’t handled. In this scenario we have created a script that checks the feed against AD accounts and any still enabled and not in the HR feed are manually handled.
SailPoint documentation says that an identity cube that gets deleted with accounts associated to it are really hidden and not fully deleted. If there was a way to access those hidden identities, actions could still be ran to finalize termination.
We had the similar case and were not able to achieve it and had to make changes in the Authorative source. We did had a Sailpoint ticket raised and this was the reply.
The first part explains when an identity is hidden from the UI. Does not mean it is deleted. The second part details when an identity is deleted. Now when an identity is deleted it varies. Most times it is our cleanup job that runs in the middle of the night and not at the time when an identity is eligible for deletion. Unfortunately the only thing the customer sees is that the identity is no longer visible in the UI and they assume it has been deleted. The identity, even though not visible may linger for hours, days, months.
Identities can be hidden from the UI or deleted altogether. These rules ensure the UI displays relevant identities and that IdentityNow is conservative about the identities it deletes altogether. A simplified way to explain the rules is:
IdentityNow hides an identity from the UI when the authoritative account is removed,
IdentityNow deletes an identity when all non-authoritative accounts and administrative responsibilities are removed.
IdentityNow decides what identities to hide/show in the UI each time Admins load up a page. In other words, IdentityNow will begin hiding or showing identities based on the rules right away after identities are updated. IdentityNow runs an identity deletion task each night that evaluates all identities and determines the ones to delete. So we are not recommending using this trigger because of all these reasons.
Here are the specific rules:
• An identity will be hidden in the UI unless it meets both of these requirements
• Must have a non-empty last name, email and uid
• Must be either correlated or protected
• An identity will be deleted altogether if it meets all of these requirements:
• No correlated accounts
• Not an owner of a role, access profile, application, source, or taskResult
• Not an owner or requester of a workItem
• Not a protected account or manager
• No assigned capabilities
Hi @jsosa , I believe based on above responses from other folks - it looks like it’s not a best design to write custom stuff to facilitate the requirement in IDN, as you want some identities to retain and some to be deleted (like terminated ones) which is kinda complex and not a good design in long run.
One way I can see it, try to persuade the HR application team to either,
Provide you “fired” identities data over the same API endpoint or a different API endpoint, OR
Periodically export such “fired” identities to a csv file on a server location from where you can aggregate them into IDN as a separate auth source for fired identities and manipulate LCS accordingly.
Have you thought about using a Workflow with Identity Deleted/Source Account Deleted trigger?
When authoritative source doesn’t receive account C, IDN will trigger a Identity deletion event for that Identity. You can use that event as your workflow trigger and configure it to modify accounts/access/notifications etc using available workflow actions.
After reading all the responses, I didn’t come across this kind of situation but here are my approaches
I was wondering if you have start date and end dates for Identities. I guess you don’t have this info either, if you have you can play around these attributes.
I guess you might have selected Disable Account Deletion in your HR source aggregation. If not, then HR account will be deleted, Identity gets deleted. But, Target sources accounts will get uncorrelated. This is not a good approach.
If you have selected Disable Account Deletion then Workflow trigger Source Account Deleted will not have scope here.
***I will be referring Life Cycle State as LCS
Approach 1: Customization Rule
Build a customization Rule in such a way that, add an attribute lastAggregated with value as current date.
For all users which are included in HR source, this attribute will be updated with current date.
Build a Date compare Transform for LCS attribute, read lastAggregated from HR Source.
If you have current date then return Active else Inactive.
Approach 2: Identity Attribute Rule
Create identity Attribute Rule for LCS attribute
Hope your HR app has API call that can get response for a single user
if yes, then make a call for the current user.
If you get response then return active else inactive.
Document doesn’t say API calls are restricted in Rules, but need to check.
I guess Approach 1 will work for you, I am confident about it.
Approach 2, unnecessary API calls which will be too many.
Let me know
Edit 1: I missed that Customization Rule is not yet available in IDN, you can try this in WS After Operation Rules maybe to append an attribute to the Response.
I agree this may work for our situation as well. It doesn’t have to be a rule, just need a way to create that account attribute, lastAggregated with current date.
Add lastAggregated to account feed with current date
Shravari,
How would you be able to take action on uncorrelated accounts? I could see it being able do notifications but not disablement of the then uncorrelated accounts.
Authoritative sources usually don’t have any uncorrelated accounts because they have an Identity Profile attached to them so that it creates Identities. But if you were missing mandatory attributes like last name or email address the source would show record as Identity Exception and not an uncorrelated account.
I am not sure why you would need to disable an uncorrelated account because if that is deleted by the source eventually, I would assume there’s no further action needed.
I hope this answers your question.
If not, please let us know your specific use case which you are trying to address.
It’s not just about Authoritative source account, what about accounts in Target apps/sources for the same identity.
Let’s say that Identity has accounts in some target sources for example: AD, Salesforce, Mainframe.
When the account is deleted in Authoritative source, Whatever happens to Identity (either deleted or identity exception), what happens to these target accounts, are you going to leave them as orphan accounts forever sitting in target sources, wasting the licenses ?
Thanks for your insights @MVKR7T. I believe the points you mentioned is exactly the issue we are trying to solve in this discussion. We cannot leave orphan accounts forever so whenever an Identity is deleted from Auth source we should have a workflow that will disable them at the least. There should also be a cleanup for all accounts on target sources which have been inactive/disabled for X days.
Hi @MVKR7T ! Sorry for the delay. And thanks all for responses! I am not being able to test yet, but this is my main doubt at this point. Suppose I have some identities with accounts. Then an identity is deleted from HR. At the workflow level, identity deletion will be identified and triggers some actions. Accounts that belonged to that identity, should be still be available, for example, with an Get Acccounts actions? Or at this point they will jus be orphan accounts? That’s my concern, because If I have to perform some action on, for example, AD account (modify some attribute so it goes into powershell rule, and do things), and account is not present for this deleted idenitty, I will not be able to do nothing with these accounts, now orphan.
