Hi All,
Can we stop remove entitlement event trigger when source is added for disable during LCS change in identity profile provision tab?
If yes could you please assist the process?
Thanks!
Hi All,
Can we stop remove entitlement event trigger when source is added for disable during LCS change in identity profile provision tab?
If yes could you please assist the process?
Thanks!
Please provide more details on your use case. How do you think is the remove entitlements process getting triggered?
Hi Nithesh,
Our use case is when user leaves company LCS will change from active to terminated, on terminated LCS we want disable Azure AD source account all entitlement should remain in Azure AD source account, once user terminated + 90days dormant LCS should get trigger then all these entitlement need to be removed and source account need to be deleted, I noticed before disabling user account Modify plan got triggered and entitlements was removed from the source account after that source account went to disable state.
Now my query here is remove entitlement event will get triggered automatically whenever source account is going to disable in this case can we stop this remove entitlement trigger ?
Hi @Vasanth ,
Thank you for sharing the details. Not sure if this functionality of removing all the entitlements once user moves to disabled state is from Azure but from ISC i am not aware of such functionality unless you have some events, workflow or may be the azure access is assigned via birthright access which is removing the entitlements.
From my perspective, you will need to analyze why the removal is getting triggered and stop it. Once user moves to dormant state, then you can have a workflow created that will be triggered based on lifcycle state change and then remove the remaining azure access.
I hope this helps.
Regards
Vikas.
Hi @vikas, Thanks for the response.
Azure access assigned via birthright access. I noticed there is no such workflow configured. I’ll take your point and check how this event is getting triggered.
Thanks!
If the azure access is assigned via birthright role, then you will need to add the criteria such that users with terminated CLS also keeps the access.
Make sure the dormant CLS is not included in the criteria so when user moves to terminated state the role will not be removed and after 90 days the access will be removed.
I hope this helps.
Regards
Vikas.
Hi @Vikas,
Yes, I tried adding role with Standard criteria added these conditions as mentioned above and able achieve the use case, but I don’t know whether this remove entitlement event trigger in disabling source is default behavior in ISC or not?
Thanks!
Hi @vasanthrajsp29 ,
Can you please share the screenshot of the birthright criteria on the role that was removed.
Also, can you please check if you have a cloudServicesIDNSetup key defined on the source json. This could also trigger the removal of the entitlements. IF it is there, can you please attach the screenshot for the same ?
Thank You.
Regards
Vikas.
Hi @Vikas,
cloudServicesIDNSetup was not included in source.
Thanks!
Thank you for sharing the details. Do you really need the birthright criteria on account attributes also. Would it not just work if you add it based on identity attribute Lifecycle state.
Is it possible to just remove the birth right criteria on the account attributes and see if that helps.
Regards
Vikas.
Hi @Vikas,
Thanks for the response, if we remove account attribute it will trigger for all the identities that exist, we have other authoritative source as well users under those might get these roles to avoid those, I added account attribute for one specific source. Any other suggestion would help?
Thanks!
This is probably happening because of the “Access Profile” added to the LCS that user had before moving to “terminated” LCS. If the same Access Profile is not present in the terminated LCS, then ISC will remove all the entitlements (that are under the Access Profile) during LCS change
Hi @iamnithesh ,
Hence its default behavior which we don’t have scope to change on provisioning plan. Correct me if I’m wrong.
Thanks!
That’s right. And, it’s meant to be like that
Ahh good catch @iamnithesh
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.