We always have at least one contractor on site and because they are involved in different products / technologies, different software needs to be installed on their PC's.
This takes up a lot of support time and is basically a never-ending stream.
Giving them admin rights would allow them to do this work themselves.
The downside is that they now have rights to do anything.
How have other people handled this?
Kia ora. Your options are:
(3) is my personal choice - I don't even run as admin on my own machines. There's a learning curve, but it's much easier on Windows 7 (and probably Vista) with UAC. A good place to start is Aaron Margolis' Non-Admin blog.
The primary benefit for not running as local admin is resistance to malware and browser exploits. This may be possible to explain to your users - "If you do it this way you won't &%#¤! up your PC" - most normal users are afraid of breaking something anyway.
Use virtualization.
Give then their own system within a system.
This way all development sandboxes are independent of each other, and cannot interfere with one another or with the Host OS.
We have a scorched earth policy with regards to granting local admin. You get local admin if you agree to not waste the desktop support techs' time. Basically, you hork something and you get your machine regenned. If the tech's nice they'll spend UP TO 30 minutes looking at your problem. This really is a win-win for us because people that get local admin typically are people who have half a clue about PC's and end up hardly ever needing to call desktop support because of something they've done (it's usually hardware related instead).
We base support costs per client device category:
Laptop users pay premium as they gain local admin rights to their machines. They understand they have a greater risk of rendering their machines unusable by their own doing, thus support for these kinds of devices cost way more than a frozen machine would, since it would require greater support time.
We support a bunch of different user populations with different needs, so customers have delegated rights and can assign workstation or local server admin rights to as many (or as few) people as they need to.
They can only do this within the system we've setup, however. For example:
A lot of organisations recognise that there is a need for users to have local admin rights and let all users have local admin.
It sounds like that is appropriate in this case, but you might want to follow up with getting them to sign some documentaion that they won't install any software other than what is on a agreed list.
You also will probably NOT want to give them Domain admin rights.
Are you worried about giving folks admin rights more because a) they may screw up their own PC's, or b) they may screw up everyone else's by poor internet hygiene?
If a) then I support the scorched-earth policy. If they're good enough consultants for you to hire them, they should be good enough to take care of their own work environments.
If b), then you probably need to look into some sort of quarantine for them. Hopefully that's a one-time thing where the lower support costs will eventually pay for it...
I, personally am a big fan of restricting accounts that are logged into the machine as non-admins, but providing them the ability to invoke installations, etc. with the "run as" command.
You could create a local admin user on the box, granting them privs and allowing them to use it to install programs?
We always have at least one contractor on site and because they are involved in different products / technologies, different software needs to be installed on their PC's. This takes up a lot of support time and is basically a never-ending stream. Giving them admin rights would allow them to do this work themselves. The downside is that they now have rights to do anything. How have other people handled this?
We have a somewhat-controlled environment; while we may grant power-user access (which is usually enough to get'er done) we don't grant local admin; in fact, local admin is considered a "safety valve" feature in case we need to get administrative access to the machine and it can't (for whatever reason) get domain authentication.
Local admin on most machines isn't too big a deal, but you do not want to give out Domain Admin rights, which opens up a whole Pandora's box of issues.
Many of the "local admin" issues we've seen have come from poorly-designed software that, despite nearly a decade of changes on the Desktop, still think they are running in Windws 98 & Friends. The software installers are insisting that you give these rights because:
If possible, try to convince the contractors to bring all their software at once and have an "install fest", so you can go through this one time and get it over with. If they are dragging this-that-and-the-other all the time into these systems, even with Admin rights, it's going to be a bit of a mess - are these going to be production systems in the future? Is the sequence of installation and the dependencies needed written down somewhere? There are some dangling loose ends that need to be tied up by letting them do what they want.
So, yeah, if you don't have a problem with security issues, trust issues, compatibility issues, and you're documenting things as needed, go ahead and let them do the local admin installs, using a password that is distinct from all of the other ones.
