Microsoft Employees May Lose Admin Rights

daria42 writes "As Microsoft moves its internal desktop systems to Windows Vista, the company is contemplating whether to change a long running tradition and take away admin rights from its employees in order to improve security." From the article: "'We haven't made that final determination yet. We would like to absolutely look at scenarios where we can look at elements of User Access Control -- that is the feature in Vista -- so that we can start moving in that direction ... It is a tough balance and every company has to decide what is right for them,' said Estberg. However, Estberg said that for the moment, the company will continue to leave the responsibility of installing software with its employees."

Comments

Eat your own dog food

[mwvdlee]

"Eat your own dog food".

If Microsoft's access rights model isn't good enough for their own purposes, it isn't good enough for the rest of the world either.

If they were truely confident that it works as they claim it does, they should have had their employees in a more secure and restricted environment years ago.

Re:Eat your own dog food

[Anonymous Coward]

I hate to be the MS supporter here (and I rarely do), but Microsofts permission model is just as powerful as UNIX's. It is just harder to learn. But not that much harder.

If people suddenly switched to UNIX machines we would still have the same problem. The problem isn't that the OS has an insecure permission model (neither UNIX nor Windows NT do), but that noone wants to implement it. For the type of people who use Windows boxes, this will always be a problem. They use Windows *because* they don't want to deal with the details of system administration. If they suddenly switched to UNIX they would still not want to deal with the details of system administration (which is one of the reasons that they don't).

Re:Eat your own dog food

[XSforMe]

"they'll discover you can't run WindowsUpdate on an XP Pro SP2 machine without admin privileges,"...

I differ, windowsupdate should not be runned in user space, at least not in a default configuation under a corporate environment. In a corporate envirnomente SUS should be used to push around patches.

Re:Eat your own dog food

[Anonymous Coward]

mmmmNo. Running under a non-admin account restricts your permissions on the system the same way it does on Unix. A non-admin account cannot write to certain parts of the registry or the file system, so they cannot "infect" the OS itself, except through a privilege escalation vulnerability... and I think Linux has more of those than Windows =)

A user can download crapware all day and catch something that nukes their own "home" directories, but the rest of the system should be untouched. Not that that matters to the average user anyway, but still.

When and if most Windows users run under non-admin account on W2K/XP/Vista then the crapware writers will look for local exploits and ways to fool the user into entering credentials to run processes under administrative privileges. So far they haven't had to, because all they need is for the user to click "Yes" on a dialog to compromise the whole box.

Re:Eat your own dog food

[scot4875]

Yes it is. I don't think you understand what the grandparent poster means by "permission model."

--Jeremy

what need admin privs?

[boxlight]

I don't see why this is a big deal. Average desktop users should not have admin rights -- no?

boxlight

Excellent Idea

[Whatsisname]

Yes, having the employees run as 'regular' users would be a terrific idea. All the problems that limited user accounts have now would be encountered by those with the most ability to fix them.

"Unusual practice" ... wtf.

[Kadin2048]

Currently, the majority of Microsoft's employees enjoy full admin rights on their desktop PCs, which is an unusual practice in the enterprise space ...

An unusual practice? Where? Most places I know have their users running as admin, because there is still software around that won't function properly if it's not run that way.

If Microsoft forces its employees to run as non-admin users, I think it's a good thing, because maybe it will lessen the amount of crap software that's designed with the assumption that it's going to be run that way.

Unfortunately, that doesn't help the situation with the tons of legacy apps that assume this, and it only takes one important legacy app in a corporate environment to hose the entire security model of non-admin users.

Re:"Unusual practice" ... wtf.

[lgw]

I don't know of a large company that still lets most employees install software, have admin rights, or do anything like that. The desktop PC has to be locked down if you want to manage 100000 desktops on a modern IT budget.

It would be wonderful if Microsoft did this! The result would be that, at least for Microsoft software, the developers would be forced to care whether their software ran without admin rights.

Re:"Unusual practice" ... wtf.

[lucky130]

And you still run into those programs that don't seem to understand the concept of environment variables or the fact that you don't really need to use the registry in many situations.

Re:"Unusual practice" ... wtf.

[99BottlesOfBeerInMyF]

That sort of contradicts itself. Wheither MS runs as admin or not has absolutly nothing to do with third party developers requireing their software to do so?

Actually, it does. MS makes userland software as well. Major applications they develop do not run, or run properly (or at all) as a regular user. Now developers may consider making their software work for normal users, but if MS does not, why should they bother? Obviously no one is going to run as a non-admin anyway, since the built-in software doesn't work. MS sets the standard for their own OS. They also write the most common dev tools for their OS, which determines how easy it is to make applications work for non-admin users. If it takes extra work due to the APIs and dev tools, enough extra work that MS does not bother, then it will be enough extra work for third-party developers as well.

And as you say the legacy is going to be a big hold up anyway, so I doubt anyone will listen to MS telling people to not use old apps - especially if some of them are proprietary apps with no upgrade solutions.

MS bought Connectix. With half a clue, Vista would run a VM environment for all apps, both old and new and this would not be an issue at all. The rest of the industry is already moving that way.

Re:"Unusual practice" ... wtf.

[BVis]

Among normal companies where computers and software are tools for achieving some other goal, it is extremely rare to have admin rights. I'm talking about banks, telecommunications companies, etc. For these firms you either have to use special management software to install software, or you have to request that IT come out and do it.

I disagree. I've worked at multiple (non-technocentric) Fortune 500 companies where all users have administrative rights to their computers. Why? Because they don't want to hire enough IT staff to do things properly. Users whine and generate support workload far more when they can't install their home printer, or their online poker client (or whatever they might want to put on there) than they do if you just let them do what they want. If you go so far as to tell them they're not allowed to install anything, congratulations! You've officially created a Career Limiting Event. I've worked at places where there was no Acceptable Use Policy because of the costs (both in wages and employee turnover) of enforcing one. (The turnover comes when some poor helpdesk drone doesn't realize that they're speaking to the Vice President Of Things That Begin With H On Alternate Tuesdays, reminds them that what they're doing is against the AUP, and subsequently get fired. Gotta love at-will employment; you can be fired for any reason or no reason at all.)

Think I'm exaggerating? Why do you think I don't have those jobs anymore?

Re:"Unusual practice" ... wtf.

[quantum bit]

That's just because oracle writes some of the most retarded software ever. Come on, it's 2006 and they still haven't figured out how to deal with spaces in directory names? Or to actually register COM objects correctly during the install rather than try to do it every time you start up the program (ADI is really bad about this). How about the fact that you need an astonishingly bloated software install just to talk to their database at all?

That's just on Win32. Don't even get me started about requiring X/Java for installs on their unix stuff.

Oracle is definitely one of the companies that's responsible for the mess the windows world is in. It's a major pain to get their crap working under non-admin accounts.

Re:"Unusual practice" ... wtf.

[EvilSS]

Are they Microsoft Applications or third party apps? Everyone is quick to blame MS for this but in reality it's usually the fault of the application developers that can't follow Microsoft's guidelines for writing software. 99.9% of the time it is the result of one of the following:

1. Storing user information in HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER (even MS is guilty of this with their TS licenses)
2. Writing files to the program directory instead of to the user profile, temp, home drive or other user writable location
3. Writing files to C:\ (this is just inexcusable and lazy)
4. Some other bonehead move by the developers (such as registering components on run instead of during the install, trying to store files in winnt, using freaking INI files!)

[insert rant about under-trained programmers and lack of proper software engineers here]

If the programmers would actually learn how Windows works most of the "x software package requires admin rights" could be avoided.

Re:"Unusual practice" ... wtf.

[Anonymous Coward]

You are exactly right. The cost to properly do this will be and enormous an ongoing expense and even then it will not work because of basic human psychology. Controls freaks rule in such systems because they are exactly the people who seek out these sort of administrative jobs. Because the easiest way to do this is one size fits all, those people who need higher level of access are always left hanging. Tell me has anyone here tried to compile and test an application with any higher level of functionality without administrative rights to the local machine? Well let me tell you it does not work. In addition do you all have any idea how much work gets done by the local tech gurus that would otherwise have to go to tech support? Imagine every single little problem with a printer, file, driver, application, plug in-in or installation need requiring a tech support call. This is not Car-Max with one sales app running these people use at least 5 or six apps everyday an many less frequently. I worked for CBS when they did this. It took about a year an half before half the staff were made back into Admins and for months before that the local gurus learned that special password they needed to fix things which also meant they had higher level access to the domain than they ever had before. This costs a lot of money while saving none, enables personnel with psychological issues too much power, and treats employees who have tech skills like fools. The problem with this is that it does not look at the human reality of most work places. It is trying to create a one size fits all scheme where flexibility is most needed. Finally and to clinch it, I hate to say it but those most likely to break the system are the very ones who will get the Admin access the lonely tech staff guy surfing or gaming or the executive staff members whose 6 year old is always playing games on their parents office PC. Did I mention how hateful and bittler such places become and how there is now an excuse for every problem. If ever there was a sign MS is falling this was it. The mark of poor management is the expression of the need for more and more control.

Re:"Unusual practice" ... wtf.

[TuringTest]

Are they Microsoft Applications or third party apps? Everyone is quick to blame MS for this but in reality it's usually the fault of the application developers that can't follow Microsoft's guidelines for writing software

Third party developers don't follow MS guidelines because their apps work fine without following them.

Re:"Unusual practice" ... wtf.

[Anonymous Coward]

using freaking INI files

Yeah, god forbit I'd be allowed to move my settings between windows installs (including no longer bootign ones) in a simple manner.

Re:"Unusual practice" ... wtf.

[EvilSS]

Yes, they work so fine you need admin privileges to run many of them! Like it or not Microsoft wrote Windows. Believe or not they made it so the vast majority of software could easily run without admin privileges IF the developers would take the time to learn how to write their software correctly.

Re:"Unusual practice" ... wtf.

[arminw]

.....Everyone is quick to blame MS for this.....

Which is where the blame rightfully belongs. Why should any program, other than an installer need access to the system areas? Apple's OSX can manage this. No OSX programs need admin access other than to initially install, and then non even always. Many programs may be installed by drag and drop by a non-admin user into the users own space and the system is never molested. If the program is to be used by many users, then it must be placed into the system Application folder, which of course can only be done by an admin user. If Apple can do this, why can't Billy and Co.? Could it be that there are some very fundamental design flaws in Windows itself?

Won't fly

[Utopia]

With a huge percentage of the people being developers, these people need full control over their system.
I don't see how they can even implement this scheme.

May be they can take the admin rights from their Managers computers.

Re:Won't fly

[arivanov]

Not necessarily.

You may need admin rights to test and to package, but you should not need admin rightsfor 95%+ of the development cycle.

With the current crop of vmware and CPU based virtualization the necessity of having admin rights to your machine for 99% of the development cycle is no longer there.

Linux Users

[omeomi]

It's not uncommon for Linux users (even developers) to use user accounts, because it's very easy to su any administrator tasks. So, maybe Vista will fit this model better, and having developers using user accounts won't be all that ridiculous...

Give them average-sized monitors too, dammit!

[Anonymous Coward]

Hell, make them work in monitors the size the average office supplies -- 15" or 17" where I work.

I'm so damn tired of apps that open big windows needlessly in the middle of the screen (MSWord's 'find' for example) covering whatever it is you wanted to actually operate on -- because some programmer had a 29" monitor -- or two -- to work in and never thought about fitting stuff into a real user's working screen.

Open find. Drag stupid window off the text area. Find. Damn, window moved back to the middle. Lather, rinse, repeat.

Sure, the IT department could supply larger monitors. But those are commodities and they're saving their budget for bells and whistles to impress top management.

Re:Stop perpetuating the myth ...

[jacksonj04]

Windows Media Player 11 *doesn't* need admin rights, hopefully in preparation for Vista.

At least one application has got the idea, even if it is from the company behind the OS.

Re:Who cares?

[Eideewt]

It matters to anyone who was hoping for useful limited user accounts in Vista, because if they have to use them then there's a chance that they'll actually work.

Ouch

[suv4x4]

If Microsoft doesn't think Vista's user accounts are usable how did it end up as one of the top features of the whole product :P?

The actual fact they are thinking whether to use it or not makes me fill with doubt. And I really thought they had it right this time (honestly).

Re:Stop perpetuating the myth ...

[debest]

Here's a partial list of programs that require admin rights to run (not merely install): ........

        PowerDVD

Can't attest to any of the other examples you listed (I don't use WMP, and haven't installed any of the others), but I can attest that I use PowerDVD on my limited-priveleges account just fine, thank you.

oh well that needs remote admin as well

[dindi]

If in my college years, when I was working for different companies (as support/admin), they had that feature, I maybe wouldn't have become such a windows hater and concentrate only on unix-like systems.

But then again, it is not enought to take away the admin rights from users completely, you will need a decent way of remote administrating those damn machines.

Before people start trolling on me: yes, you can take away admin rights in 2000/XP (to a cenrtain level) and there are remote tools......

Admin rights should completely go away, the user should not have right to install, modify, not even change the screensaver dammit. And not run programs at all, only from a secure pool of programs.

That includes "i-know-it-all" managers, who tend to fsck everything up, because they know it so-well they are playing in the registry, and deleting folders/etc ...

Now on the remote tool: the nightmare of a a support/admin person is a multi-level building, where you keep going for all those machines, instead of ssh-ing into them and fixing/installing remotely ....

Not because they are easy, but they are computer people and not PR monkeys and are probably sick of interacting with all the workers of the companies, who probably do not wash their hands after peeing, and then you have to go and touch 100 keyboars in 100 rooms ....

Oh well ... just a flashback from my early years of computer support :) and I am not doing anything with customer machines anymore ..... but still, I feel it is a problem ...

Ohh, and that's why you have to wear the suit and not cargo pants and something that actually keeps you warm in the server room, or climbing on that roof yagi in the european winter to spot the balloons 5kms away on the rooftop with the compass and the binocular, to re-align the connection ....

Admin rights

[Nijika]

I've seen a lot of people comment that they work at large companies and have admin rights on their Windows boxen. I (pretty much) had the same setup at both of the larger companies I worked at where MS was enforced on the desktop (at both places I wouldn't have been able to interact with the work environment without Windows).

I suspect one of the other big reasons for this is it's cheaper to do a bare-bones re-install when the Windows box goes teets up than to have an admin action every user need that is required on a box where the user is actually treated as a user.

Imagine how many real-life admins you might need to handle the hour to hour needs of a company where access rights in Windows were restricted.

This of course applies to no company that does NOT run Windows. Almost any other company would be able to handle that easily.

Talk about hidden costs.

Re:Admin rights

[naelurec]

Your absolutely right. The *nix way:

1. User needs a particular application. Depending on company policy, the user may be able to install in their own home folder. If not, they could submit a request to suppot.

2. Support authorizes request, does a remote SSH connection to the users machine, installs the software (while the user is still working) and notifies user that the software was installed.

3. Software ties into centralized package management system so suppot can keep tabs on security notifications, updates, etc and roll it (easily) into the centralized update mechanism.

The Windows way:

1. The user needs software and does not have admin rights. The chances the user can install in their home folder is close to 0%. User requires IT to install.

2. IT receives the request and approves it. Perhaps IT gets lucky and the software is packaged as an MSI that can be installed via group policy. IT adds the install files to a network share and adjusts group policy. Tells user to restart or wait until next boot to get the update. Most likely the software cannot be installed via MSI (no auto-install MSI exists) and manual installation will happen (lets face it, creating an MSI is a PITA, especially for non-standard software).

3. IT contacts the user to tell them they will access their system remotely and to log out (no concurrent users in XP). User logs out and IT logs in remotely via RDP rendering the computer inaccessible for the user.

4. IT installs the software as administrator (via remote share). IT logs out and notifies the user the software was installed.

5. A little while later, user contacts support that the software does not run properly. Apparently the software needs to be run as admin first time to initiate some files in the program files folder. Admin repeates step 2 and 3 to finalize the software install. Unfortunately, the software refuses to run via RDP. Great. Support has to either have local user login as a temporary admin to run the software or admin has to physically access the machine.

6. Admin decides to go to the machine to step through the install. Runs the software, logs in as the user account and it still is not operational. Admin then has to pull out regmon/filemon to determine the issues (as the regular user). Once done, admin has to re-acquire admin level rights (ie runas or admin shares) to make file permission changes/registry security changes.

7. After a debugging session, the software finally works as expected for the user (hopefully). Admin then writes down all the steps required in the event of a software upgrade, future install, etc..

8. Admin decides to notify software company so hopefully next version is fixed.. software company's support is not interested and state "admin access required". Blech.

9. There is no central management of the software, so admin has to manually check for updates (along with the myraid of other software). Perhaps in the spare time, the admin writes a script to assist in the installation.

While I *will* say the _ideal_ corporate installation scenario on Windows is much better (load up MSIs and set a group policy to do auto-installs), there is WAY TOO MUCH software that simply does not fit the mold. Even software that does manage to utilize this method sometimes requires elaborate step-by-step (slipstream, etc..) to make it function right (ie MS Office 2003) in this scenario.

I'd honestly be happy with the sudo equivilent. Allow specific software to run via sudo w/o password (transparent to the user). This could solve the legacy issue while forcing future software development to test against regular user accounts.

Re:Actually

[Jon Peterson]

They need to lock down their boxes to make sure that their employees don't discover the utility of free software (like firefox).

Oh _that's_ why they are doing it. That figures. Everyone knows, you always give Linux users root access, so they can install all that great free software. And, equally, we know that if you don't have administrator rights on a Windows box, it's impossible to install Firefox.

And someone gave you an 'insightful'. Geez.

Re:Actually

[squiggleslash]

I don't think that can be true. Microsoft would be shooting itself in the foot if its own employees remained in the dark about what's going on in the real world.

Virtual Machines to the rescue?

[WhiteWolf666]

Is there any reason not to use some kind of virutalization solution, and allow employees to "admin" their images, while forcing user privelidges for the host operating system?

Except for device driver development (even USB and some other stuff would work correctly in a VM), are there any disadvantages?

Are there any OS developer situations that require the performance of native access at the same time as requiring administrator privlidges?

The only arguments I can think of against this are developers that require close hardware access, but with paravirtualization solutions like Xen even thats not a big issue. Well, except on Windows, of course.

Re:Reminds me of where I used to work

[jcr]

Excuse me? The COMPANY deserved it, so you violated your CUSTOMER's copyrights?

You unbelievable, thieving asshole.

-jcr

No Virutal Machines to the rescue

[amcdiarmid]

Good idea, but flawed from a security perspective:

If the idea of not having Admin rights is to keep virusX off the network, running Admin in a virtual machine just means virusX runs in the virutal machine & infects the virutal machines on the network: Stuff is still borked bacause all those developers have viruses on the virtual machines...

Note: Personally, I don't see developers wanting to develop in User-Mode. I also don't see why at least the non-developer staff is not running in User-Mode. (OK, realistically I do, but thereotically I don't.)

The reality of admin rights

[dave562]

I work as a consultant slinging warez for the evil empire in the SMB sector of the world. Most of my clients have less than one hundred users. It has been my experience that with the exception of poorly written third party software, 95% of the users can get away with generic "user" or "power user" rights to the local workstation.

Even in cases where admin rights are necessary, virii and malware can be mitigated by a combination of tools. With Symantec AV, MS Defender, and a good firewall at the perimeter with content control, the only people who cause problems for me are bored users who get to sites that aren't on the content control deny list. Once I explain to their boss that they're paying me +$100 an hour to clean up a mess that could have been avoided if the employee was doing their god damn job instead of jacking off on someone else's time, the problem usually goes away.

When a workstation blows up, a re-image gets things up an running again in an hour or two.

Even though it's possible to work around the 'dangers' of admin rights, I do agree that it is a problem. Microsoft took a step in the right direction with the Windows XP RunAs. I've found that at my clients who have XP and need admin rights for a particular application, setting up a shortcut that uses the RunAs functionality gets the job done most of the time.

Re:It'll turn out just fine

[70Bang]

Why can't they "RunAs" for installs (when needed)?

On a similar note, near the end of my mainframe days as a systems programmer & tech support, I worked in a group where everyone worked with God privileges even though they weren't needed 7x24.

I didn't. I usually only had one window open on the 3270 emulator running on OS/2 (this was near the demise) and my coworkers would have tons, but nothing which had regular privileges. If someone (another IS/IT/MIS) staff member went to one of my teammates who were closer physically to them, they'd say, "I don't have that problem." and leave them hanging, not even willing to bring up a "standard" account to see if they could repeat the problem. Once people found out I worked with Joe Q. Citizen privileges, except when needed, I'd either test it or switch to a userid where I could test it.

In the case of Microsoft, if they spent a lot of time working & testing as something other than "Administrator" (userid or privileges), they might get a better appreciation for their users' plights & frustrations. And if they're caught switching back to Administrator unnecessarily, or forgetting to go back to a regular user after fixing a problem as Administrator, then it's time for a public flogging - make them spend the next week as the buildmeister, relieving the person who would earn that privilege when their code breaks the build (is that how it's still decided?).

In terms of those who perform testing, if they're testing as an end-user, how many of them actually need Administrator privileges?