Implementation of an Emergency Leaver functionality

Using the "Security Risk" flag (IsSecurityIncident) is the ootb Emergency Leaver function that allows you to disable or delete all assigned user accounts controlled via the account definition configuration. The same is true for the assigned entitlements at those user accounts.

As long as the import does not touch this flag, the user will stay locked.

https://support.oneidentity.com/technical-documents/identity-manager/8.0/target-system-base-module-administration-guide/6

Hth

Using the "Security Risk" flag (IsSecurityIncident) is the ootb Emergency Leaver function that allows you to disable or delete all assigned user accounts controlled via the account definition configuration. The same is true for the assigned entitlements at those user accounts.

As long as the import does not touch this flag, the user will stay locked.

https://support.oneidentity.com/technical-documents/identity-manager/8.0/target-system-base-module-administration-guide/6

Hth

Hi Markus,

thank you  for ur feedback.

I did some testing with it and works fine so far, two points that came up and I could't clarify so far.
For a person who has IsSecurityIncident set and account definition is set to retain the linked accounts, these accounts get disabled. Nevertheless it seems as if the person itself can still log in to WebUI by username and password. Are my obervations correct and is there a special reason why it is like?
2nd point, in contrast to IsInactive - not automatically set due to IsSecurityIncident being set- the person is per default considered, managed and visible by the system as a "normal" active person, right? Not menaing that the behavior is strange, but asking if there are any further processes, UI etc. that have a special handling.

Thank you !!

In regards to number one, the user is still allowed to log into the portal, to allow him to challenge the "security risk". At least some customers have implemented it that way, as the feature was implemented in the first place.

Coming with version 8.2, the system will block the login attempt for users having the flag IsSecurityIncident set. But you can fall back to the original behavior controlled by a configuration parameter.

In regards to the 2nd point, besides the removal of the permissions, the rest of the processes should treat the person as an active person.

Thank u very much !!!

One more to go, as the customer would like to have it set and provisioned "as fast as" possible.
I would assume the option would be to set a higher priority on the process in case the process was triggered due to an change on that attribut and maybe have it provisioned via dedicated server, which is "waiting for these kind of jobs".

Therefore I was searching for a process in the JobQueue which might have to be customized to increase the prio, but couldn't find anything.

Any suggestion where or how to do this?

Each process step has a priority that can be set. Since 8.1 the priority is controllable by a script.

The ootb process ADS_ADSAccount_Update/(De-)activate uses this.

 Thank you and adjusting the *update processes for ADS, LDAP, ... was what I already had in mind.

I was more thinking about possiblities in inheriting from person to account level or are the update processes on account tables is the only place that can/ needs to be adjusted?

Thank you !!

There is no inheritance involved for the template execution between a person and its connected user accounts. This update is done in a single transaction.