“User lock/unlock” management scenario

In my previous post I was raising doubts about the fact that implementing lock/unlock account procedure might not be so easy. Here I’m trying to explain why.

Preliminary remarks: although this requirement is rarely present in IAM project RfP’s, it is obvious that any large organization already has a procedure disciplining the user lock/unlock processes. Let’s try to imagine it in detail.

A user can be locked for various reasons. For example:

1. Technical lock (a user is locked because he or she has exceeded max wrong passwords or due to extended inactivity).
2. Administrative lock (specific events coming from HR determine a temporary or definitive user lock i.e. maternity leave or grace period before expiration).
3. Security lock (a user is locked by a security manager).

It is also obvious that unlock procedures must follow hierarchy rules, such as:

1. A Technical lock on a user can be removed by any administrator (Head of Unit, Help desk etc..).
2. A Security lock on a user can only be removed by a Security Officer.
3. An Administrative lock on a user CANNOT be removed by any administrator. His or her unlock is determined only by an HR event (return after long leave or expiration interruption etc..).
4. To complete complexity, if a user’s Security or Administrative lock is directly removed by the target (e.g. using AD console), then the IAM system must react in real time by resetting the unlock.

These processes must be managed by the IAM system since access systems (e.g. MS Active Directory) do not have the “intelligence” for this purpose and therefore cannot “assist” such management.
If this type of requirement, even though not particularly complex, is not directly supported by the tool’s data model, a custom development consisting of "data model” definition managing would be required.
The data model shall support data, relations between them and other already available data as well as necessary developments to implement policies.

In conclusion:

• When the product data model itself already supports these processes, mapping of the said process is reduced to pure and simple configuration in no time. Maintenance and changes are made by high level administrators
• In case native support is not available, the following should be expected: detailed technical specification definition, Data Model updating, policy writing (usually at low level) and tests, changes, complex management, etc….