Microsoft Employees May Lose Admin Rights 502
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."
Eat your own dog food (Score:5, Insightful)
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.
what need admin privs? (Score:4, Insightful)
boxlight
Excellent Idea (Score:5, Insightful)
"Unusual practice" ... wtf. (Score:5, Insightful)
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.
Won't fly (Score:5, Insightful)
I don't see how they can even implement this scheme.
May be they can take the admin rights from their Managers computers.
Re:Eat your own dog food (Score:3, Insightful)
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:"Unusual practice" ... wtf. (Score:5, Insightful)
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:Won't fly (Score:3, Insightful)
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 (Score:5, Insightful)
Re:Eat your own dog food (Score:3, Insightful)
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.
Give them average-sized monitors too, dammit! (Score:5, Insightful)
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 ... (Score:4, Insightful)
At least one application has got the idea, even if it is from the company behind the OS.
Re:Who cares? (Score:5, Insightful)
Re:"Unusual practice" ... wtf. (Score:2, Insightful)
Ouch (Score:3, Insightful)
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 ... (Score:4, Insightful)
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.
Re:"Unusual practice" ... wtf. (Score:3, Insightful)
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.
oh well that needs remote admin as well (Score:4, Insightful)
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
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
Re:"Unusual practice" ... wtf. (Score:5, Insightful)
Think I'm exaggerating? Why do you think I don't have those jobs anymore?
Re:"Unusual practice" ... wtf. (Score:3, Insightful)
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.
Admin rights (Score:5, Insightful)
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:Actually (Score:1, Insightful)
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.
Comment removed (Score:3, Insightful)
Virtual Machines to the rescue? (Score:3, Insightful)
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:"Unusual practice" ... wtf. (Score:5, Insightful)
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:Admin rights (Score:5, Insightful)
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.
Comment removed (Score:3, Insightful)
Re:"Unusual practice" ... wtf. (Score:1, Insightful)
No Virutal Machines to the rescue (Score:3, Insightful)
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.)
Re:"Unusual practice" ... wtf. (Score:3, Insightful)
Third party developers don't follow MS guidelines because their apps work fine without following them.
Re:"Unusual practice" ... wtf. (Score:2, Insightful)
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. (Score:3, Insightful)
The reality of admin rights (Score:2, Insightful)
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:Eat your own dog food (Score:1, Insightful)
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:"Unusual practice" ... wtf. (Score:3, Insightful)
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?
Re:Eat your own dog food (Score:3, Insightful)
--Jeremy
Re:It'll turn out just fine (Score:3, Insightful)
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?