I was wondering if anyone has been able to have the Non-Employee Risk Management tool auto disable Admin/System/Users accounts when that person leaves the ORG.
We recently had a workflow fail that caused a notification to go out the the Admins group. This is showing people who are not longer active. I know the short fix is to go in and disable them in NERM. But I would like to automate this so that we do not have to worry about having to keep this updated all the time.
Thank you
Hey Mark,
NERM doesn’t really have automation available for the “Users” of the Application. That is something that I generally recommend is done as part of regular user management in AD / the Identity Provider.
IE: If a User leaves your Org, the IT team needs to disable their AD Account. As part of that disablement, that team should also ensures the NERM account is disable. That can be done manually or via API calls to PATCH the status of the user to “disabled”: patch-user | SailPoint Developer Community .
If you have IDN, you could most likely set up a Workflow in IDN that upon the lifecycle state changing for an Identity, an HTTP Request is sent to NERM to disable the account
The “devil in the details” is what you mean by “… that person leaves the ORG”.
If there’s a termination/expiration process then that process should ensure the person’s related accounts are disabled appropriately. This “process” could be a whole variety of things.
Keep in mind that NERM is based on group membership outside the toolset (mostly with the exception of collaboration users which likely wouldn’t be admins). This means that the above mentioned process(es) control the access. This process could involve terminating a contractor directly in NERM which is then aggregated to IDN and subsequently the AD account is disabled and groups removed. This full process would remove them from the group membership.
Unfortunately there’s no “magic bullet” and without a process (manual / automated / both) that terminates the account used to SSO to NERM there’s nothing directly in NERM that can be done.
A TOTALLY different topic - The generic error email you noted not being configurable in any way is a real challenge to deal with from many different perspectives and needs serious attention (in my opinion).
Thank you. From the sounds of it in this use case what I should do is setup a new webservice connector and pull in the USERS from SecZetta and correlate them to a cube. Then define the needed API request via HTTP operations. This way it could be 100% automated to remove the required access. The number of users with the Sponsor access is very limited in scope so this in theory should not be to hard to complete.
It also allows us to track users who have this level of access. And I also agree that that not being able to update the notification can be a pain.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.