When you say goodbye to an employee

...what do you do with his or her account? Recently this question came up -- someone was asking for guidance on how to handle this very situation. And, as often happens, the question was more about process and policy than anything to do with the technical issues of account management.

Those of you who've followed my writing and speaking will agree when I admit that I've become somewhat of a policy wonk over the past few years. Awhile back I spoke at an executive event in Taipei. I asked this question: "Who here can claim that their network is completely secure?"

Much to my surprise, a gentleman in the front row said "I can."

I honestly wasn't expecting that answer, so I decided to probe a bit. "Really? Wow. That's cool. How can you know that?" I asked.

His response: "Because I've installed every security product I can find."

...uh...hmm...it's unusual for me to be at a loss for words! But sensing a teaching moment, I talked for a while with the audience about risk assessment, about business drivers as the source of policy and process, and about technology as the implementation of some (but not all) process. It was a good conversation, one I've had many times since then.

You can twiddle all you want with various pieces of technology, but unless you have well-tuned processes that derive from policies reflecting the needs of the business, then your technological efforts are wasted. Very likely you'll end up focusing on threats that don't exist while ignoring those that can seriously bite you.

There are some elements, though, where you really don't need to worry so much about extensive process or looking to map from business drivers to policy to process. One of these is what to do with the accounts of ex-employees. While people become ex-employees for a variety of reasons, there's really only one threat that exists: all access by ex-employees is by definition unauthorized access. So as I see it, there's actually a very simple process for handling their accounts, and here it is:

  1. Immediately disable accounts when users quit, get put on probation, or are fired
  2. Delete these accounts when you no longer need them for recovering data

There's certainly no business requirement for keeping an ex-employee's account active. That's why you should disable it right away. If you instead immediately delete an account, you've made it nearly impossible to retrieve information that the employee has encrypted. The default recovery agent is a backup for EFS, but you need to have configured it correctly when you implemented EFS. However, for S/MIME there is no backup. Plus, in case you need to conduct any kind of investigation, you might need to log in to an ex-employee's account. So to be safe, disable it -- but keep it for a while.

Only after you're certain that you won't need it anymore can you then delete it. You don't want it to hang around forever, because for so long as it exists, it's something you have to manage. So when you're finished with it, after you've completed any investigations and have recovered whatever data you need, get rid of the thing. Now you can forget about it.

I see two remaining considerations. The first: it's up to you to determine the time interval between disabling and deleting. Here's probably the only point worth some thought in this process, and it's mostly about responsiveness. How much time can IT give the business units for completing an investigation and recovering data? Perhaps you'll have two time limits:

  • one for when no investigation is required (say 30 days for general collection and clean-up)
  • one for when there is an investigation (it's out of IT's hands, let the legal department decide -- but the duration should never be infinite!)

The other policy/process consideration is determining what data of the ex-employee to keep. I suppose "keep it all" would be one choice...but do you really need all the MP3s and porn that guy has collected? Unless you're investigating resource abuse, probably not! Here's an opportunity for you to work with the business units to decide -- most likely on a case-by-base basis -- which data to keep and which to discard.

Handling the accounts of ex-employees is pretty simple, really. So don't get too mired in arcane process work here. There's far more important work you need to be doing.

Comments (6)
  1. Anonymous says:

    Recently in the newsgroups ( news:microsoft.public.security , to be specific) the question of password

  2. Anonymous says:

    Why DoS and DDoS attacks are the plague of the InternetHackers use evasive manuevering to escape detectionMitigate the effects of a DDoS attackDraft Special Publication 800-53A, Guide for Assessing the Security Controls in Federal Information Systems

  3. Arie de Haan says:

    Hi Steve,

    Totally agree, also it is easy to set the expiration of an account in AD, if it is to be used by hired personel for a specific time. So you don’t have to think of it yourself all the time. User can’t logon-> time to renew the contract 😉

  4. Christian says:

    Hi Steve,

    like always – good points. Just two comments I would like to add:

    1) "for S/MIME there is no backup". Well, I hope you agree that if this is the case the company had some knowledge-free consultants. PKIs – including the Microsoft one – have best practices on how to backup and recover keys and there is typically no dependecny to the user object. Especially in comparison to EFS it is much more likely – like you sad – to have some non-managed EFS encryption happen than to have people using S/Mime without central policies and repositories.

    2) To me there is an additional question I try to find a good answer when saying goodby to an employee – it’s the mailbox. It starts very easy that you have to take care the account is moved away from all distribution lists because of the annoying internal NDRs when disabled but it gets much more complicated regarding incoming mails. One can say it is best practice that all the communication partners receive an "account unkown" but maybe there are better solutions than this? In addition, what about mail enabled password resets the biz unit has to do on service subscriptions or other web services the account was responsible for… should a collegue watch the incoming mail? Can this be combined with privacy?



  5. AdamV says:

    The user mailbox is always an issue. Good client care indicates that some sort of out-of-office reply is warranted such as "John no longer works, here, please contact Mary instead via <email> or <telephone number>…"

    Once the account is disabled, OOF no longer works natively on Exchange.

    So, what to do?

    a) create a new user account called "John OOF" which is a member of no security groups except those used to DENY access to things (such as UsersWithNoInteractiveLogonRightsAnywhere). Remove John’s SMTP address(es) (and prevent RUS updates) and add them to this new account instead. There could be licensing implications of this of course – you now have an extra Exchange mailbox

    b) create a Distribution List which goes to a sink account which is periodically or continuously emptied, add SMTP addresses for all users who leave, and make the text more generic – "The person you are trying to reach is no longer with the company. Please call our main office on <X> and we will connect you to an appropriate person."

    c) do the OOF with a rule on your edge mail filtering device instead

    d) Treat left users just like non-existent users and NDR them, but customise with a telephone number to contact – this helps real people and does not simply create more spam to your info@ addresses when NDRing for accounts which never existed.

    e) if you have a clear usage policy covering owenership of their data post-termination and there is no overriding jurisdictional issue with privacy (as there would be in Germany for example) then you could use a one-member-DL to redirect mail to their replacement member of staff

    Of course, you only want an OOF message there for a short interim period (1 week – 6 months) which will depend on the person’s role / importance and how quickly they left (has a handover been done or were they marched out for stealing paperclips?).

  6. RobK says:

    Don’t forget external providers that aren’t federated with your directory.  For example you ought to pull someone’s MSDN account when they terminate!  Or, someone in your finance department may have access with a payroll outsourcer you need to delete.

Comments are closed.

Skip to main content