Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


September 23, 2009

Security Steps: Firing a Systems Administrator

The first step in firing a systems administrator is to disable their user account
RSS
Subscribe to Windows IT Pro | See More Systems Administration Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!
back to blog index

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 account

Step 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.

End of Article



Reader Comments
I hope companies big and small have some procedure for managing outgoing personnel on the IT side.

We would also consider removing admin rights from their account where they remain in the office for a period after giving notice and change the actual administrator account logon password as well.

wlefkovics September 23, 2009 (Article Rating: )


Even when the user's account is disabled, those same admins also often know the credentials of privileged accounts in the network. These are accounts that run services, applications, tasks, are included in scripts, web services, the built-in admin or root accounts, etc.

These privileged accounts get changed less often than admin's accounts because of their impact on the business if something is missed during a change.

The trick is to get these account's passwords changed when these admins leave, or better yet, get a solution in place to control those passwords so that no one ever knows what they are but must go through another system to get access to those passwords which of course audits the user's access to those accounts. Then, after those accounts are used, re-randomize the password so no one knows what they are once again.

The problem with changing these accounts is the locations that these accounts are used, just as Orin mentions is a problem with disabling the fired admin's account. Luckily, there are tools such as Lieberman Software's Enterprise Random Password Manager (http://www.liebsoft.com) to help discover the systems, the accounts, and how those accounts are used on the systems so that when it changes a password, everywhere that the account is used also gets updated. Then, if the password is needed, it can be retrieved through an audited web interface.

Many of the break-ins that have occurred have taken place through the use of these privileged accounts by these fired admins.

cstoneff September 28, 2009 (Article Rating: )


You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor? Register now





Search Hyperbole, Embellishment, and Sys Admins
 
Hyperbole, Embellishment, and Sys Admins
NOVEMBER 2009
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30      
or

 Recently in Hyperbole, Embellishment, and Sys Admins
Security Steps: Restricted Groups Policies
Make a Comment
Security Steps:Use Syskey on Windows 7 to encrypt the SAM to stop someone resetting the local admin password on a netbook
Make a Comment
WSUS, Server 2008 R2 and BranchCache
Make a Comment
Security Steps: How to block the installation of the Chrome Frame add-on for Internet Explorer
Make a Comment
Security Steps: Firing a Systems Administrator

Last Comment
Even when the user's account is disabled, those same admins also often know the credentials of privi...
(2 Comments)

More blogs about technology,
software, and Windows.

Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement