Security Steps: Firing a Systems Administrator

This might seem hopelessly obvious, but if you look through the news headlines about administrators who go crazy and attack the organizations that they worked for you will find that in almost all cases the operative word is “worked”. In almost all cases the administrator had been let go before they launched their damaging attack. The main reason that they were able to successfully attack was that the organization that they worked for had not disabled or removed their administrator account once their employment had ceased.

Although large organizations tend to have excellent policies when it comes to deprovisioning user accounts when the users are let go, small to medium sized enterprises are less likely to be diligent when it comes to disabling or removing the user accounts of users once they have left the organization. Almost every administrator I know has stories of looking through the Active Directory database and seeing the fully enabled account of an administrator who has long since left the organization. One reason that these accounts don’t get disabled is that there is a nagging fear in the back of people’s minds that there may be some job, in the bowels of some server on the network, that relies on that account being active in the domain. That disabling the account will cause something in the background to quietly go clunk. In reality if that is the case better that you know about it now because, at some point, you need to make sure that damn account is disabled – you can’t leave it there just in case! Another thing the history of these sort of breaches shows is that it is not just employees that leave under acrimonious circumstances who turn around later and attack organizations. Employees who have moved on to greener pastures quite amicably have been known to come back and trash some servers when they find out that they still have access. Just because they left under a pink fluffy cloud doesn’t mean that they didn’t harbor some deep unresolved animosity and thirst for revenge. So what can you do when an admin leaves the organization? Step Zero. If they give notice, configure their account to expire at the time their employment ends. That way you don’t really need to remember to disable the accountStep One. When they do leave, manually disable the account. This is relatively straightforward. At some point you should delete the account, but it is safe to leave the account in a disabled state in the short to medium term. Step Two. Configure the Logon Hours so that the user is denied logon at all times. This is particularly effective if you have group policy configured to forcibly log a user off when their log on hours expire. If a user is logged on with an account that is disabled after they are logged on, they remain logged on until they manually log themselves off. If you change their logon hours so that they aren’t authorized to log on at any time, then they will be forcibly booted during the next refresh cycle. You should also change the account properties so that the computers that the account can log on from is set to a null computer account. You probably only have to use step two in the case where an admin is getting fired as you may want to lock them out when they are still possibly logged on.