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."

Re:It'll turn out just fine

[tehcyder]

No, they want real security, so the choice should be BSD.

>> Runs for cover

Re:"Unusual practice" ... wtf.

[Anonymous Coward]

I work for Intel. Because XP is a piece of crap, all Intel employees have administrative rights on their own desktops. It's the only way to make way too much software work. If they took away my local administrative rights at least three applications I depend on for my job would stop working properly.

Re:"Unusual practice" ... wtf.

[msh104]

I worked at "stork worksphere" in the netherlands, which is really a big company, and all have admin access to there local pc.

Re:"Unusual practice" ... wtf.

[Anonymous Coward]

Symantec. Ditto what the above say, admin for everyone. Though they do at least use GPO's that make it dificult to fiddle around with the SAV and SNS stuff. Not like a local admin can't get around a GPO, but anyone with that level of skill is probably okay as an admin anyway.

Re:Stop perpetuating the myth ...

[lucky130]

Just so you know, not all of these programs need admin rights to run; they need certain privs on certain folders (usually either write or modify to their program directory).

Re:Stop perpetuating the myth ...

[colganc]

Are you sure on Windows Media Player? I'm able to run it at work without admin rights. I can rip MP3's with it as well.

Re:Stop perpetuating the myth ...

[gnuyarlathotep]

Here's a partial list of programs that require admin rights to run (not merely install): * Kodak Share software * Autocad * Any serial port emulation program * PowerDVD * Oracle * Windows Media Player

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 rights.
I run Windows Media Player on every machine we have, around 1,5000, and only a few have admin rights.
And these machine run the software as well as you can expect windows to work.

Re:Stop perpetuating the myth ...

[hackstraw]

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

Here is a more complete list: http://www.pluralsite.com/wiki/default.aspx/Keith/ HallOfShame.html [pluralsite.com]

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?

Re:Actually

[bhalo05]

Sure, that must be the reason

http://portableapps.com/apps/internet/browsers/por table_firefox [portableapps.com]

It comes with me everywhere I go (well, almost :-) )

Re:Won't fly

[Anonymous Conrad]

Then you've never had to attach to system processes like IIS from a non-admin account, e.g. to debug a COM+ or an ASP.NET application.

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]:

In Visual Studio .NET, there are two things that determine if a user can debug. One is the Debugger Users group, and the other is user privilege, such as administrator, power user, or SEDebug.

The Debugger Users group determines if the user can access the VS debug component (mainly MDM-Machine Debug Manager, which is part of Visual Studio), so being a member of the group means that you are guaranteed for accessing MDM. So at this point, you can debug your open process and see the list of process on your machine.

But after this, whether you can debug other user's process is decided by your privilege. For example, if you want to debug other people's native process, you should have SEDebug privilege. For the other users' Managed process, you should be administrator on the machine.