Who needs administrative privileges on a network or website? The network admin obviously does. But others ask for root access, too, whether or not they truly need it. How should an admin—or the IT manager—handle the sensitive political situation when someone asks—no, demands—admin rights for a system when he really shouldn’t have them?
This is not a hypothetical situation. Recently, I lurked on a converation in a network admin’s discussion group in which one network admin’s plight highlighted all the issues in one fell swoop. I’m reposting the meat of the original query here, with his permission, after removing specifics which might give away the poster’s identity.
“More often than not,” my online buddy wrote, “I find myself in a situation where someone ‘higher’ than me asks for access to a system, and they feel that their request is beyond question. This person may be the project manager for a project or someone above me in the food chain, but invariably they are always shocked and appalled that I asked why they need the root/admin password to the system. And then that’s when the chain of meetings start, to discuss why am I being difficult, not a team player, etc.”
“I may not be universally approachable, but I’ve always politely and respectfully asked my questions to get an understanding of what they were looking for,” he wrote. “Experience tells me that often times they think they need root access but really all they need is sudo or a certain right granted, not full blown privileges to the entire system, if they need access at all. But from where I’m sitting, their anger seems to stem from, “This peon spoke back to me; how dare he.'”
For example, at one place I worked at in a time far away, the webmaster asked for the root password to the web servers. I asked him why he needed that kind of access, and the only response I could get was, “Because I need it.” Of course I said No. A few days later I’m pulled into a meeting with the head of IT, my manager and the webmaster to discuss why I’m refusing to work with the webmaster.
Users who don’t know the operating system certainly shouldn’t have the keys to the kingdom, but sometimes that’s exactly what they demand. No admin wants to give access to a webmaster who asks, “What’s a shell?” The admin doesn’t want to be a pain. He just wants to do his job, which is to secure the network and keep it running correctly.
Other admins in the discussion offered what I think are a pretty good list of policies for the network admin to adopt. I’m sure these aren’t the only good Rules to Live By we could come up with, but they’re a good start.
But before I let you peek at the suggestions, I’d like you to think about this for a moment. Whether you’re an admin yourself, a programmer (who believes she needs root access to the production website to solve a development problem), or an IT manager… what’s your response to the dilemma? You’re the boss, after all; how would you solve this common source of friction? Even if you aren’t moved to post a response here (and really, I’d love to see your own solution), scribble down a few thoughts. What would you do?
Got that done? Really? Okay, let’s take a look at the suggestions other admins made, so we can compare their answers to yours.
Put reasonable access policies in place before someone asks for unreasonable access.
In addition to identifying what isn’t allowed, said one admin, the policy should also specify what is permitted, how determinations are made and the responsibilities for different access levels. (In creating a policy, someone has to keep records for who has access, who granted it and for what project/purposes. Who’s going to do that?)
The policy should be publicly discussed and approved by the appropriate person or governance group. “A stack of ‘IT Policies’ that were written by IT and not discussed with anyone else or approved by the appropriate people are worthless,” wrote the admin.
Ensure the criteria for root access are published.
Don’t stuff that policy in a WaySekrit drawer. The policy should be readily accessable to every employee.
First, this saves time; the admin doesn’t have to repeat herself.
Second, and perhaps more important: It turns the conversation into an external one, whereby personalities aren’t involved. That is, a “No” decision doesn’t mean you’re being petulant and insubordinate; you’re just complying with the company policy. (Even if you were the one to write it, which somehow doesn’t strike the same political button.) An admin can say, “This request would seem to go against our policy. Can you help me understand the reason for making an exception to it?”
That makes it easier for the admin to convey that her decision isn’t about a lack of trust in the person requesting access. It is an industry best practice (and in many cases, a regulatory one) in which the admin is attempting to carry out her responsibility to the organization to manage the systems and to protect everyone’s privacy and system integrity.
Which sure sounds better than, “I wouldn’t trust you to feed my goldfish.”
If formal policies are a pipe-dream, at least create a sign-off procedure.
You can’t depend on competence and the willingness of the people above you in the org chart to give this any priority. (“Yeah, tell me about it,” you’re thinking.) So if she can’t create a realistic policy with the input of the business stakeholders, the admin should create procedures with necessary sign-offs. “This sounds like a lot of paperwork, and it is,” wrote one admin, “But it helps to show your customers where the problems lie.”
An admin who gets a new request for root access should document potential risks of granting the request and identify alternatives with lower risk. The requester should be asked to sign the documentation, which the admin forwards to the admin’s supervisor.
This is a slightly more diplomatic way of telling the user seeking root priviledges that he must be willing to accept liability for the entire system and that he’ll be billed for fixing any unusual problems (since an admin will no longer be able to prove they didn’t cause problems). But it does draw the correlation between root and budget.
A user who has the global root password, agreed another admin, should be required to carry a pager, or to take a rotation in the pager rotation. This, he explained, is part of the message, “You now share responsibility for achieving the SLA [service level agreement].”
Perhaps this sounds a little harsh to the IT managers reading this message. But as one admin explained, “Everyone who has root access becomes responsible for the whole system. You are protecting these users from taking on the liability for the system. Users need this protection because they are not in a position to manage the risks that challenge any system. You are, which is why you have root.”
There’s another advantage to this approach for the admin. If an admin discovers they don’t care about the subject and won’t back up the admin on creating reasonable policies before the fecal matter encounters the air-movement device, he learns to acquire two things: a stack of CYA letters and to post a current résumé on a job search site.
A helpful attitude matters
…even if the admin has to grit his teeth. One suggested a response of “Please help me understand what you’re trying to do, so I can be sure that we’re going about this the right way.” Besides, it might actually get to the, um, root of the problem.
After all, said one admin, a user needing root access is inherently a design flaw. “If you need root on a machine, then I have failed to provide you the awesome environment I try to provide,” one admin said. He tells users, “Any time you spend as root is time you are distracted from doing your job. Please help me understand what you need to be able to get done and I’ll find a way for you to accomplish that goal without elevated privs.”
Acknowledge the politics.
“I heard that one site renamed the root account to be ‘clerk’ and nobody wanted root any more,” wrote Tom Limoncelli, author of The Practice of System and Network Administration. “I can’t prove this, but it’s a great story.” (Another good resource on the political side is the Usenix article from 1999, A Management Perspective On Privileged Access To Computer Systems.)
Those suggestions were all from other network admins, and I think they’re very good. But they don’t invoke the opinion of the dude or dudette on the other side of the desk: the IT manager or the user (including programmer) who wants the root access in the first place. I’d sure like to hear what points you would add to this list… or those you’d refute.—Esther Schindler