We are going to let one of our sysadmins go in a few weeks. He has access to our entire infrastructure, so we'll have to reset the passwords on everything. This is going to be really time consuming though, with the number of servers and devices out there we would have to reset. A few things are tied into Windows domains so that's easy enough, but problematic depending on whether any services run as that user.

Is there any way to easily revoke access to everything for that user? I guess I'm asking for cross platform single sign-on...maybe RADIUS can do this? Or is there a turnkey solution out there like RSA SecureID? What have you guys used?

  • Feel free to tell us something about your systems, such as what you're running. – John Gardeniers Jun 22 '10 at 3:00
  • A mixture of Windows and Ubuntu servers, a few Cisco and Juniper routers, a few HP Procurves, quite a few VMs running on top of VMware vSphere, and a lot of websites we use regularly (support sites, remote logins, etc.) – zippy Jun 22 '10 at 13:59

When I left my last job, they had to go through much the same process. I had managed to get access to pretty much every root-like password we had. There was a mini-project to map out everything I had access to, and I gave them lists of where I knew I had access. My whole last week I had steadily reducing rights as various passwords, ACLs, and group-memberships were changed. The Telecom guys were giving me evil looks since they hadn't changed their password in FAR, FAR too long and were having to do it on each and every device (some required a site-visit); at least they took that chance to deploy a central passwording system at the same time. On my last day I was asked to spend time trying to get into things in order to see if they got it all. In fact, they did.

This is what a polite transfer of power SHOULD look like in the SysAdmin world.

  • 1
    As a contractor my aim is never to be NEEDED back, but wanted back. – PP. Jun 22 '10 at 7:18
  • This sounds like the safest and most thorough way to do it, although I really wish there was a less labor intensive way. – zippy Jun 29 '10 at 15:24

We've used SecurID via Radius to control all external access into the network. This means limiting the number of remote access points (analog lines anyone?) and making sure that those that remain (1) use the SecurID solution as a factor of authentication (for SSH, RDP, webmail, etc) or (2) are on a checklist of termination procedures (rotate password on "in case of outage" box plugged into DSL, etc).

Access from the outside thus secured, you deal with rotating all the static passwords, cleaning up user accounts, etc on the inside.

Regarding "depending on whether any services run as that user" -- best practice would be that nothing run in the context of a human user account for this very reason. Audit your cron, at, etc jobs now and move what you can to non-human service accounts.

It's not an easy task to set up your environment to deal with this sort of thing gracefully, and likely not something you can arrange in the next few weeks.


Make a register of all your systems with static root passwords, which password they are using (hopefully they are distinct enough that you can identify them without revealing them), and the date when they were last changed. If you can, switch to using several "root" passwords of different levels - a low-level password that isn't used for outward facing devices won't necessarily need to changed if those devices are using a unique password with limited uses.

There's also an important lesson for managers here: don't aggravate your IT staff, because they effectively have the keys to business. Good hiring policy - hiring staff that you can trust not to abuse their knowledge once their employment ends - is often easier (and better) than a technical solution.

  • 1
    I find this a bit rich. Do folks try to not aggravate restaurant waitstaff because they can poison your food? Or gas station attendants because they can drop a match in your fuel tank? Sysadmins have their role. Implement proper technical security controls and "do unto others as you would have them do unto you." – medina Jun 22 '10 at 4:49
  • @medina: Regardless of how well an employee is treated there are always going to be those that have an ax to grind. The departing employee could be your brother or your best pal but prudence and good judgement dictates going through an exercise as described by the OP. – joeqwerty Jun 22 '10 at 11:15
  • @joequerty: Of course; comments like "don't aggravate your IT staff, because they effectively have the keys to business" and "Good hiring policy [...] is often easier (and better) than a technical solution" are a bit silly. – medina Jun 22 '10 at 11:52
  • @medina: beware the psychopaths. The OP is talking security, so "paranoia mode" seemed appropriate. Disgruntled employees in most industries just flip out and kill people, but an ex-sysadmin can potentially wreck the business from the comfort of their own home. – Andrew Jun 22 '10 at 22:58

Even using some type of single sign on mechanism doesn't avoid having to go through the exercise you're going to have to go through. Single sign on is an abstration layer that essentially abstracts the various individual sets of credentials into a single credential (from the user's perspective), but it does not "merge" the various entities into a single entity. If you have a Windows login and a Linux login and utilize single sign on to allow the user to authenticate once in order to access both systems, you still have two logins that need to be dealt with when the user leaves. For the average user, single sign on would be effective but for an admin or an experienced user, they'll know how to gain entry to a system (router, server, etc. while bypassing the single sign on mechasnism. Why go through the single sign on mechanism when I can just telnet directly to the router?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.