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."
It'll turn out just fine (Score:4, Funny)
Re:It'll turn out just fine (Score:2, Informative)
>> Runs for cover
Reminds me of where I used to work (Score:3, Interesting)
Re:Reminds me of where I used to work (Score:5, Funny)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re:It'll turn out just fine (Score:3, Funny)
Leave Rosie outta this, nerd!
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 wh
Only makes sense... (Score:3, Interesting)
From TFA: No wonder:
- and -
Mabye if M$ developers were forced to run as non-privileged users once in a while, they'd realize that there's a lot of problems with trying to get through the day on a non-admin account. With any luck, this will spur them to design a better way of handling applications that fail due to insufficient privileges, as well as get tough on application developers who sloppily code their apps to demand admin rights.
Again from TFA: I'd hardly call an environment where users have full admin rights to their systems an adequate test-bed.
Once more from TFA: Saying that Microsoft is 'not smarter than any other enterprise in terms of knowing how to address security', while technically true, is deeply misleading. Any company that purports to "eat its own dog food", but performs their testing with full admin rights to the box clearly has a dangerous lack of understanding of security...a lack that we all pay the price for every day.
"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.
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:"Unusual practice" ... wtf. (Score:3, Informative)
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:"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:3, Insightful)
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 Applic
Re:"Unusual practice" ... wtf. (Score:2, Informative)
My company does. (Score:3, Interesting)
They make Slashdot every now and then too.
Re:"Unusual practice" ... wtf. (Score:5, Interesting)
You forgot about Apple. You know - the little company that makes iPods.
Over 10,000 employees, each with admin rights. No viruses, no malware, no screwed up OS that lets any process run with global read/write priviedges...no kidding.
The only difference is that they don't run Windows on those desktops.
Re:"Unusual practice" ... wtf. (Score:4, Interesting)
Well, it isn't the support costs. When I worked there, IS&T was located in (should I say?) a place where grapes grow, many miles from Cupertino - and they didn't do normal help desk work. That was for ATCs - regular Apple employees trained to do help desk-type stuff. In AppleCare, we had one for about every 30-40 people, and the arrangement worked quite well.
More interesting than anything else would be a support cost per employee breakdown between Apple and another computer company - say, Dell - excluding headcount from the support organization to normalize things a bit.
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:5, Funny)
Maybe it was because you're prone to exaggeration and it was interfering with your job performance
Re:"Unusual practice" ... wtf. (Score:2)
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.
Almost every compagny i worked for (as contracted) and work with NT4 or higher.
As a developer I always hate day i get a new PC. It is very hard to install oracle without admin rihgts. It is also very hard to let the normal it drones make a oracle installtion (I am not talking the default client. It only takes 2 or 3 days to convince f
Re:"Unusual practice" ... wtf. (Score:3, Insightful)
That's just on Win32. Don't even get me started about requiring
Re:"Unusual practice" ... wtf. (Score:3, Funny)
I suddenly felt a disturbance in the Force. It was as if thousands of non-admin users cried out at once and then suddenly rebooted...
Re:"Unusual practice" ... wtf. (Score:2, Insightful)
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
Contrast this with Sun (Score:2, Interesting)
Compare and contrast this approach with Sun. Employees in Sun are all equiped with Javacards which they can insert into a Sun Ray appli
Re:Only makes sense... (Score:2)
True, but Microsoft should be able to afford a test environment where the testers work as power users or even as user only. In that environment, an application that fails due to lack of admin rights should be caught soon.
Or even simpler, the users could create secondary accounts without admin rights.
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:Stop perpetuating the myth ... (Score:3, Informative)
Re:Stop perpetuating the myth ... (Score:2)
A few of those (Oracle I'm looking at you) are so bad that I've gone so far as to chuck their installer completely and replace it with one of my own that sets appropriate permissions.
Even that's a band-aid, though. Programs really shouldn't be trying to store per-user data in a system-wide program folder. Not even counting the potential security hole, it's a pain if users can't change settings with
Re:Stop perpetuating the myth ... (Score:2)
Do your users have Power user rights? The default reg permissions in XP allow power users to create new entries in the system-wide CLSID key. I see a lot of programs that work if you have power user but not standard user rights. Honestly I don't really see the point
Re:Stop perpetuating the myth ... (Score:3, Informative)
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:Stop perpetuating the myth ... (Score:3, Informative)
You are misinformed on most of these:
I run Kodak Share on about 40 of our Windows boxes, none of them have admin rights.
I run AutoCAD on all of our Engineer's windows boxes (about 25), only one has admin rights.
I run PowerDVD on over 1,000 windows boxes, less than 20 have admin
Re:Stop perpetuating the myth ... (Score:2)
Re:Stop perpetuating the myth ... (Score:2)
Re:Stop perpetuating the myth ... (Score:2)
Re:Stop perpetuating the myth ... (Score:5, Informative)
Here is a more complete list: http://www.pluralsite.com/wiki/default.aspx/Keith
Not running as admin should have been eliminated back when multiple users were first introduced with NT.
But hey, from what I hear this new Vista OS will have new features like using config files instead of the registry, shell scripting, regular updates to keep the thing working via a paid subscription, and other nifty new things.
What's next? A web browser that is not integrated with the entire operating system?
Let's hope they do (Score:5, Interesting)
Clearly, they weren't "trying out" the Limited User accounts when Windows XP was in its infancy. Otherwise, it might actually be useful to us today.
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.
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
Re:Eat your own dog food (Score:2)
If you're sharing a Unix machine with other people, then you're pretty much guarenteed to be running a user account.
You know why people do this on Unix? Because it works. You don't run into fiddly problems all of the time
Re:Eat your own dog food (Score:2)
When you have two APIs that provide/achieve the same thing, the 'simpler' one is by far the most powerful.
Re:Eat your own dog food (Score:3, Insightful)
--Jeremy
Re:Eat your own dog food (Score:2)
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.
Re:Eat your own dog food (Score:2)
You really want regular users to be able to effect system-wide changes? (applying patches that may or may not break something, or might not even be from MS if somebody spoofed the windows update site)
You can come pretty close though -- with automatic updates there's a group-policy option that allows non-admin users to see and apply the updates.
what need admin privs? (Score:4, Insightful)
boxlight
Re:what need admin privs? (Score:2)
Another big source of problems I've had to work around is that the code generated by MSVC 6 for COM DLLs requires admin rights for RegisterServer calls. Most of the code can be converted to use HKCU allowing limited users t
Re:what need admin privs? (Score:2)
Admin rights are required to run LiveUpdate.
It may be fixed now, but I remember a year or so ago reading that MS's own Media Center software couldn't be run under a limited user account and if you tried to get all wily on it and launch it with Run As... you'd still have limited functionality.
It's just horrifically implemented.
Better still (Score:2, Interesting)
Excellent Idea (Score:5, Insightful)
su got you a vist from security (Score:5, Funny)
It happened to me when I mistakenly typed "su" instead of "du".
Re:su got you a vist from security (Score:5, Funny)
Re:su got you a vist from security (Score:2)
Re:su got you a vist from security (Score:2)
Re:su got you a vist from security (Score:2)
Exactly! (Score:5, Funny)
If at any point anything unusual is detected our sensitive corporate data is automatically protected from being compromised as C4 charges in the walls and floors are detonated, immediately annihilating the entire building and everything within ten meters of it.
Some say that our approach might be a bit too proactive, but =%&/(&%/%&$/"$?=(/)&%=/%/)+NO CARRIER
Re:Exactly! (Score:4, Funny)
At my company, the entire system is run by a benevolent AI known only as ALICE. If you visit any porn sites, ALICE will have you run out the building. If you start going to sites you normally don't, ALICE will get suspicious and have you run out the building. If you stop going to sites you normally do, or start getting some real work done, ALICE will get suspicious and have you run out the building.
If you want software installed, you have to ask her directly for it.
However, there is only one microphone terminal to access Alice. First you have to go into the basement vault, which is locked behind two keys which are 10 feet apart and have to be turned simultaneously. Thermal scanning ensures that only one person is in the room at any given time. Once you're through the door, you'll meet an old man by the name of Razael. Trust nothing this man tells you, but gain his confidence at all costs. After the swamp of misery, you'll find the server closet hidden in a disused lavatory. It's the disused lavatory with 5' thick reinforced steel and concrete walls. That's when the trouble starts.
There you will find an a NeXT cube and a Sparc station. Be warned, these are both cooled by Nitroglycerin, a highly volitile liquid explosive. You must synchronize the "keymaster" file on these two machines within 20 seconds using nothing more than an Appletalk network. Failure to succeed in this time frame will warm the Nitroglycerin enough to trigger a reaction that, when combined with the ball bearings and shards of glass stuffed in the machine, would be most unpleasant.
The keymaster file gets you as far as the login prompt on the mainframe. But if you want to talk to Alice you need the second layer password, that of the Lowest access User, or LUser. Only Razael knows that password. Once he has input it, immediately kill him. Don't worry, we have more. No, I'm not at liberty to explain that last sentence.
Be very careful with ALICE. She gets grumpy sometimes and is known to take things the wrong way. Once you have LUser access, just plug your microphone in and carefully ask ALICE for whatever it is that you need. You did bring a serial microphone with you, didn't you?
No? Oh dear, back to square one.
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: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.
Re:Won't fly (Score:2)
I think this is less about "need" than "want" -- I was just bitching about not having access to change [Unix environment tweak] and having to go through a sysadmin for it, but it hardly rises to the level of "need".
Re:Won't fly (Score:2)
Sure, testing installation would require it, but development? No.
I'm sure one can run a per-user web server for testing web apps.
Re:Won't fly (Score:2)
Re:Won't fly (Score:2)
of the sort.
Re:Won't fly (Score:4, Informative)
There's two debug privileges on Windows: the "Debugger Users" group that the Microsoft Debug Manager checks before allowing you to call through it, and the SeDebug priv that allows you to attach to non-.NET processes that you don't own. See this article in MSDN [microsoft.com]:
Re:Won't fly (Score:2)
Re:Won't fly (Score:2)
I develop software myself. I don't use MakeMeAdmin that you mention.
Instead I have sucessfully used Drop my rights [microsoft.com].
And I have zero infections in last 14 years of computer usage.
Although I have had lots of fun infecting Virtual Machines with various virii and malwares.
spyware addicted MS employees (Score:2, Funny)
Would this mean... (Score:5, Interesting)
If they want to installed firefox or opera... (Score:3, Interesting)
Re:If they want to installed firefox or opera... (Score:2)
At least until I block ports 80/443 at the firewall and demand that they route thru the proxies.
IE + outlook + admin rights = disaster (Score:2)
in a sense, it's nice for those working there because i've seen myself how limited one can get in certain situations without some non-standard rights, but from the I
Linux Users (Score:5, Insightful)
Re:Linux Users (Score:2)
runas
My hope is garbage like above will be flushed out with vista.
Re:Linux Users (Score:2)
Do I understand this right? (Score:2)
Advertising soft-chewy insides is for candy companies, not computer security experts.
If they don't, who can (Score:3, Interesting)
Others have given the example of XP, and so true.
If you have to manage Vista the same way you manage XP, that is one less reason to upgrade, and another reason to look at alternatives.
Look at Novell with their internal deployment of Suse. They've had to suffer for a while, but slowly they are starting to show it can be done, and have gained a bunch of knowledge doing so. Novell customers may actually believe them when they suggest they can deploy Suse for some systems instead of Windows. Who believes you can run Windows without adminstrative rights?
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.
Employees may be fungused, but not fungible (Score:2)
Plus as others have noted, the Windows security "model", is less like Jessica Alba and more like Herman Munster. The choice has always
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).
Firefox (Score:2, Funny)
MS still a PC company if they do this? (Score:2)
So I question whether Microsoft can take admin rights away from their workers and still claim to be in the PC business.
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
Experience from the field... (Score:2)
(large ~2000 R&D center, users on NT/2000 depending on the time)
- we had admin right
- they (the all-knowing corporate IT nazis) removed it, were asked to put it back for some people.
- devised a complicated process to allow for it, with the suitable delay and approval hurdles: You had admin rights but just for a week, etc...
- as the request flowed in, overloaded manager asked to simplify the process, which eventually decayed to
- as the request flowed even more, the delay b
Logic (Score:2)
Thinking about this logically, admin rights should only be given when necessary. If they aren't needed, there is no problem with taking them away, and if they have set up their system environment properly, the employees won't miss it at all. Employees that do need some special priveledge can be given limited access (kind of like sudo, etc).
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: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.
Yep... that WILL improve security. (Score:3, Funny)
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.
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, rea
Anything less would be hypocrisy (Score:3, Funny)
Re:Justice, (Score:2)
Sales people? Admin Assistants? Sure.
Re:Justice, (Score:2)
Admin for install.
Non admin for ALL testing of ALL non-admin software.
I know, it's out there, eh?
And maybe require that same testing for an official Vista sticker.
Re:Justice, (Score:2)
the right option when prompted (my clueless admin thought that shared meant
full control). Even then, it's still "usable", but changes to preferences are
lost.
Re:Who cares? (Score:5, Insightful)
Re:Personal Compter? (Score:3, Interesting)
Of course, this was back before anyone realised total cost of ownership was far greater than the purchase price of the machine. And viruses and worms hadn't been invented, and you needed to be a guru to change the machine configuration, and they only ran a single application at one time, and we weren't connected to a vast global network filled with script kidd
Re:Personal Compter? (Score:2)
We aren't really going back to a central processing model. We are trying to regain some of the management and security benefits the old central processing model had by default and that general purpose networked personal computers can only acquire with a lot of hard work.
This is true, but only to a point. It is not just that the individual configuration model is inherently insecure, it is that the market has not been able to demand more security in the default configuration and with easier, more understan