FIM Best Practice: Handle deprovisioning with care

I have two personal rules I always follow when implementing disabling and deprovisioning:

  1. Never make decisions on an absence of data, and
  2. Never make destructive changes straight away.

Never make decisions on an absence of data

A common scenario has HR offering a list of all “current” employees – meaning that when someone leaves they disappear from the list. We are then expected to take this as a sign to start disabling and even deleting objects. This is a great way to set yourself up for disaster.

Items disappear off lists for all sorts of reasons. Here are some real examples I know of:

  • A SQL replication error cropped the user list and hundreds of accounts were disabled,
  • HR changed the way they handled contractors and thousands of contractor accounts got disabled,
  • AD accounts were moved to a different OU, putting them outside FIM’s scope, and causing it to disable accounts in another system.

All of these problems would not have happened if we only made decisions on actual data, rather than an absence of data. So make sure you still have access to information about people after they’ve left.

Never make destructive changes straight away

We should always allow for errors: perhaps a person’s contract was extended but their new end date has not been updated yet. FIM can’t know about the extended contract and can only work on the end date supplied so the correct thing is for it to disable that person’s access. Once the problem is noticed and the source data corrected we then want FIM to put everything back the way it was with no intervention.

Often IT administrators follow manual process which involve destructive actions like removing group memberships, detaching mailboxes and deleting accounts. I always insist that FIM only make reversible changes in the first instance, such as disabling login, and then proceed to destructive changes only after a suitable grace period has passed. 

Do we always need to import people who have gone?

We don’t need to know about people who have left for ever. My general rule is this: as long as I am maintaining a connection to a target account I want a link to the source object. Once all target accounts have been cleared away then we don’t need to see the source object any more.

More on Deprovisioning

I once wrote an article on ILM Deprovisioning. It is all still relevant to FIM, and the code is the same if you’re using classic.

Got something to add? Disagree? Comments are open!

About: Carol

I've been doing IT for 30 years, and IdM for 15. I live in Australia and build IdM solutions based on Microsoft Identity Manager. I also play the violin, but that doesn't help much with the IdM solutions.


2 thoughts on “FIM Best Practice: Handle deprovisioning with care”

  1. Restricting the number of deletes in the export run profile should also have a meaningful number, to avoid a disaster.

Leave a Reply

Your email address will not be published. Required fields are marked *


*