IT Employment

Ask something
Discussion Locked

Admin Privilege

0 helpful
14 replies

by magatton

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I am the computer administrator for a small company. I manage 12 PC and a server. I have someone throwing a royal fit that they do not have admin privleges for "their" PC. They ask me why they can't and are not satisfied with any of my answers. "you don't trust me" They say. Ahhhhh. Anyone have a list of why they can't?
Mike

14 replies

by wayne m.

State the reasons you have and leave it at that. Repeating reasons submitted by people who don't know your situation is simply condescending at best.

Review your list of reasons for not giving out the admin privileges. Toss out any that don't really hold water and keep the rest. As long as one reason stays on your list that you feel is truly valid, then stick to your guns and keep the privileges reserved. Explain your rationale, but is someone continues to disagree with your judgment, pass the buck to your boss, then do as directed by your boss.

You know your situation better than us. Set the rules that you feel are appropriate and set up an evaluation process for cases where the rules need to be bypassed.

by charliespencer

You're paid to make sure the systems stay secure. Not giving end users admin access is standard practice. Quite simply, no, you don't trust them not to load unauthorized apps, ignorantly open an infected attachment, accidentally delete system files, etc.

You don't have to justify why you won't give it to them; they have to justify why they need it.

by stress junkie

As I've written many times here, the standard security model is to deny everything to everyone and then to enable individual features on a person by person basis. In practice there is a basket of abilities that everybody needs but the principle is important to understand.

by jaqui

there is no justification why they need admin priviledges if they are not it staff.

by wayne m.

IT is a support function. Its purpose is to enable business functions to run more efficiently and effectively.

I am not saying it is inappropriate to withhold privileges from end users; I agree it is a best practice. This, however, is quite different from saying that the restrictions do not require justification. There needs to be more than just that "I, system admin, says no."

Remember, the people using the system likely do not report to the system admin staff. The best policy is to treat them as peers and explain the rationale behind the restrictions imposed. See if you can negotiate an acceptable middle ground, and if not, suggest that you both take the issue up to the next level in the chain of command.

Treat the users as equals. The "Just say no" approach only perpetuates the bad image of IT departments everywhere.

by jdmercha

Maybe there is a legitamate reason they need admin access. But respond to:
"you don't trust me"
with:
"I trust you alright, it's the 1000's of hackers on the Internet I don't trust"

by stress junkie

I think that the posts from Palmetto and the respondents did not intent to imply that the IT department should adopt an inflexible policy about enhanced privileges. I believe that we all intended to convey the idea that enhanced abilities are only granted when there is a business need to do so. I certainly have never supported the idea that IT people should treat the end users with disrepect or to impede the ability of the end users to do their jobs.

My own post is a perfect example. I said that the standard security model is to deny everything and then to grant access to whatever is needed based on the needs of individuals. That certainly doesn't imply that end users should be denied resources that they need to do their jobs. It also doesn't imply that IT people should treat end users as menial. I would further say that IT has no right to deny an end user resources that they need to do their job. If THAT were to happen then the management could sort that problem out quickly.

The question of granting end users privileges is often very complicated. Many times the end user that wants the enhanced privileges will not have considered options that would be in the best interest of the business. Usually end users haven't even considered having privileges on a machine on a development LAN for instance. In many cases where the end user legitimately requires some kind of system privileges the potential for that person causing problems can be addressed by giving them an isolated test environment.

That's only one possible resolution to this sort of situation. Many times a nontechnical users doesn't know all of the possibilities that are available. That's where IT and end users need to work together. Very often the end user doesn't want to find a safe solution. They have gotten the idea that they have a need for privileges and they are all excited about being inducted into the group of privileged users. When you suggest various options they don't want to hear it because they have their heart set on having privileges on the corporate LAN. They think it makes them special. They think that it sets them apart from their departmental peers. They don't want to talk about options.

Your first sentence is actually the best evidence against just doing whatever end users think that they want or need. IT is a support function whose job is to safeguard ALL of the corporate resources in order to allow EVERYONE do to their job. We sometimes have to deny one person's request in order to protect the resources for the rest of the corporation. We have to protect the ability of the USER COMMUNITY AS A WHOLE against potential problems that could be caused by one person. Balancing the business requirements of one person against the business needs as a whole is the ONLY legitimate basis for granting or denying user requests for enhanced privileges.

In each case there is only one correct response. It's not as if we have any real latitude. We simply have to do the equation and find the correct answer. It's nothing personal.

by amcol

I've wrestled with this issue a lot in my organization and you've given me some things to think about I hadn't already. Thanks.

My approach may not work for some because we each have our own particular situational imperatives. The policy I've implemented is relatively simple:

1. End users (customers) are supplied PC's that restrict admin privileges by default.

2. A customer whose job responsibilities require travel (in our case all travel is international and to very remote locations) will be granted limited admin rights so that in the event software necessary for the performance of job functions in the field must be installed the customer will be able to do so.

3. A customer whose job responsibilities do not require travel does not require admin rights. Any and all installations will be performed by IT, and then only once all the appropriate QA/QC activities have been completed. We guarantee rapid turnaround time for this via published SLA's.

4. We protect our laptops with the same set of controls we establish at the network perimeter. Theoretically the laptop security is sufficiently strong such that it can't be defeated no matter what the customer does. In the event laptop security is breached, the network perimeter controls are sufficient to avoid system infiltration. (In the last 12 months we've undergone hundreds of intrusion attempts and have been 100% successful in repelling the attacks, so we don't think we're kidding ourselves.) Under no circumstances is anyone outside IT granted any level of network admin rights.

5. In the event any customer performs an operation as a consequence of having local admin rights that affects the laptop in any way, IT will not attempt to diagnose or repair the problem...we will simply reimage the machine. If any data loss is experienced as a result, IT is not responsible since we require all files be network resident. Customers violate this policy at their own risk.

This entire policy is published, and we require all network users to sign a technology use and security awareness policy...when they join the organization and every year on their service anniversary...acknowledging they understand and will adhere to the policy, accepting sanctions for non-compliance up through and including termination.

I don't know if this is helpful, and I'd actually appreciate a little feedback on what folks think about how we do this.

by stress junkie

It's clear that these rules are the product of a lot of thought. They appear to me to be a good application of the principles that I had in mind. It certainly is possible, and preferable, to find common configurations for groups of people. You don't have to think through each new employee's admin rights requirements. Most people fall into a larger group. In your case there are the local users and the remote users. You've already researched the possible requirements of remote users and you have a policy in place to prevent ad hoc problem resolution for predictable requirements of the remote users. This keeps the remote users productive and reduces help desk calls from remote users.

It is certainly desirable for any IT department to research common user requirements and to have a policy in place. Corporations that have an in house software development staff could have a physically separate LAN for the development and testing of software. IT departments that have out sourced various services such as email or web hosting may have some users that require a particular configuration. It makes a lot of sense to think these situations and requirements through in advance. That helps to prevent overlooking details when you have to identify and implement the special requirements.

I developed my guidelines for dealing with users over a long time of working on mini-main frames. (VAXen). I would often have user communities that included management, administration, and software development on the same machine. Tuning user account privileges was pretty important to maintain security and the reliability of the machine to remain in service. As a contract employee most of my career I would often walk into a situation where a VAX has chronic mysterious problems. Many times some user account privilege pruning and some routine preventive maintenance would fix everything. I spent a lot of time figuring out how software developers could accomplish their job with fewer system privileges than they originally asked to have granted. I also always treated all of the end users that I supported with respect. I never acted like some authority figure to decide whether I would grant end user requests or deny them as a show of my power. Many system administrators in the 1980s did act like they owned the computers and end users were only allowed to use the computers through the magnanimity of the system administrator. When I entered the field in 1985 I immediately decided that the job was all about customer service, not customer control or customer humiliation. I always made sure that I was very friendly to and approachable by the end users. I always adopted the attitude that my job was to facilitate end users while balancing the needs of the entire user community and of the corporation. When people wanted special privileges I wouldn't dismiss them out of hand and send them packing. I would always say "Let's see what you need to do and how we can make that happen." These days that's not so unusual. In 1985 it was extremely rare for an IT person to think like that.

by tony hopkinson

and I'm one of those awkward people with admin rights on his own machine.
This sort of thing to me is more than OK, it's when retentives starting saying you can't choose a reasonable desktop, access the net or want to put a keylogger on your machine I get p!ssed off.
I did work at one place where IS had a strict rule that no one outside of them would have admin access to any machine. It lasted three days.
If it's a serious concern, you can always isolate them from the rest of your network with an internal firewall.

by master3bs

The most likely reasons the person wants the admin rights is to do something non work related anyway. Anything you would need admin rights to do, such as install software, should be done by IT anyway.

That's not to say that I have never given admin rights to people but in most cases it is unneccesary.

Let them know it is standard practice.
Ask them why they need it
Ensure them that the taks they need to perform are your job (assmuming this is the case.)

by tony hopkinson

developers for instance, but's that what they should be exceptions. Never met an IS department big enough to cope with more than four developers without a serious drop in their's and IS' productivity.
I get admin rights as self defence from IS otherwise they would be spending more time on my PC than I do.
Course if I screw it up, it's not a secret and I'm the poor twat who has to rebuild his environment from the basic image, and then explain why the deadline wasn't met.

by tonythetiger

for them to do their jobs (limited to what is within your authority to grant, of course). Ask the user what aspect of his job function requires him to have administrative (or power user) access to the computer. If his reply sounds reasonable, consider granting it. If not, ask him to submit the request in email to his supervisor with his reasons, and cc you and your supervisor. You will then have the opportunity to explain why it's not a good idea to all of them at once. Then do what your supervisor says.

by sbrooks

Ask them to put in a written application explaining the reasons they want admin access, then compare it to the list of reasons people need admin access. If they really need it they should be able to make a convincing argument, if they can't make a convincing argument for it then they shouldn't have admin access.

This discussion is closed to new replies.