I have two personal rules I always follow when implementing disabling and deprovisioning:<\/p>\n
<\/p>\n
Never make decisions on an absence of data<\/strong><\/p>\n 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.<\/p>\n Items disappear off lists for all sorts of reasons. Here are some real examples I know of:<\/p>\n All of these problems would not have happened if we only made decisions on actual data, <\/em>rather than an absence of data. So make sure you still have access to information about people after they’ve left.<\/p>\n Never make destructive changes straight away<\/strong><\/p>\n 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.<\/p>\n 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.<\/p>\n Do we always need to import people who have gone?<\/strong><\/p>\n 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.<\/p>\n\n