As not all sources/applications/connectors support disabling/enabling operations, what is the best way or options to manage those accounts complying to audit when an identity join/leave/rejoins an organization?
Example:
When someone with an active account to sources without “enable” feature leaves, accounts he/she own might be stripped of all access but there is no operation triggered to disable the account. No logs to show the account was disabled. I don’t see me or application owners pinky swearing to auditors/compliance that the account is active but has no access the standard solution.
Maybe a workflow to open a ServiceNow Ticket to have have the account disabled? Or you could also look at doing a before/after provisioning rule to disable the account. But it would all depend on the application and what API’s you can access.
This is where I would start researching these 2 methods to figure out which one would be the best fit. It will all depend on your business requirements.
Adding to options provided above, you can also open a serviceNow ticket via ServiceDesk. You need to add source in identity profile and set to auto disable for inactive lifecycle state. Then, configure in serviceDesk to send ticket to respective app team with user information.
If you have an attribute that defines the status, if you can sync that attribute, you can make it as an Access Profile or Role, assign it if user leaves automatically. Some applications will not have disable functionality, but updating status attribute would work and vice versa.
Example: Atlassian suite cloud connector, for Jira, it wont work if you update status attribute, you have to do disable account operation.
If not feasible with direct provisioning then,
Create a ticket to app team to disable account
Send email notification to disable account
Subscribe for a report with app team as recipients
