Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Microsoft Employees May Lose Admin Rights 502

Posted by Zonk from the root-to-moot dept.
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."
This discussion has been archived. No new comments can be posted.

Microsoft Employees May Lose Admin Rights More

Microsoft Employees May Lose Admin Rights

Comments Filter:

  • It'll turn out just fine (Score:4, Funny)

    by PrescriptionWarning ( 932687 ) on Tuesday May 23, 2006 @10:44AM (#15386966)
    they'll probably just install linux instead :-O
    • No, they want real security, so the choice should be BSD.

      >> Runs for cover

    • I used to work nights as a Photoshop guy at a color pre-press shop in the burbs of Chicago. They had an SGI server running IRIX and the people that ran it were two guys that knew a little about computers. One used to be in the sales department, and the other guys dad got him his job there straight out of high school. Neither one had any formal training in IT or even a basic computer course...let alone Unix security. To be fair, I wasn't a computer expert either, but I read a lot and knew a few things...but

      • Re:Reminds me of where I used to work (Score:5, Funny)

        by haleyeah ( 691260 ) on Tuesday May 23, 2006 @01:14PM (#15388139)
        I got hired at a 'mom & pop' to be the general IT jack of all trades. They had a peer to peer network running with some wierd ip scheme some consultant setup. Of course I setup a file server as well as upgraded the PCs from win 98/95 to XP. I took away local machine admin rights. Well in a couple of days I got support calls from all the old ladies who worked there. Their webshots no longer worked plus they couldn't install those damn web games. I was able to hold out by throwing around some technobabble and scaring the boss about all those security risks on the internet. Well after a few weeks serious support calls dropped to nothing. After setting up a linux box to run mysql and developing some applications in VB to replace the myriad of excel files they use,I had run out of projects. Between boredom and the boss eyeing me everytime he passed my office, I enabled local admin rights again. Lets just say between cleaning spyware and adware I've been staying busy.

  • Only makes sense... (Score:3, Interesting)

    by TripMaster Monkey ( 862126 ) * on Tuesday May 23, 2006 @10:44AM (#15386969)


    From TFA:
    Currently, the majority of Microsoft's employees enjoy full admin rights on their desktop PCs, which is an unusual practice in the enterprise space as it makes possible for users to install unauthorised software and introduce unwanted pests -- such as spyware.
    No wonder:
    • There's so many poorly designed apps out there that demand admin rights to run, even though they don't actually need that level of access,
        - and -
    • Windows itself handles rights failures so poorly (erroring out or worse, instead of just providing a prompt for the user to enter admin credentials).

    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:
    According to Estberg, Microsoft's employees provide an excellent test-bed for the company's products and by providing honest feedback, they also have an opportunity to influence future products.
    I'd hardly call an environment where users have full admin rights to their systems an adequate test-bed.

    Once more from TFA:
    "We are not smarter than any other enterprise in terms of knowing how to address security. We are in the same boat as everyone else," he [Estberg] added.
    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.
    • 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. (Score:5, Insightful)

        by lgw ( 121541 ) on Tuesday May 23, 2006 @11:00AM (#15387081) Journal
        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. (Score:3, Informative)

          by 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. (Score:5, Insightful)

            by EvilSS ( 557649 ) on Tuesday May 23, 2006 @12:38PM (#15387893)
            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.
            • 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.
              • 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.
            • .....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 Applic
        • I worked at "stork worksphere" in the netherlands, which is really a big company, and all have admin access to there local pc.

        • My company does. (Score:3, Interesting)

          by FatSean ( 18753 )
          They support a few more than 100,000 desktops :)

          They make Slashdot every now and then too.

        • Re:"Unusual practice" ... wtf. (Score:5, Interesting)

          by vought ( 160908 ) on Tuesday May 23, 2006 @11:21AM (#15387254)
          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.

          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.

      • 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
        • 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
      • If Microsoft forces its employees to run as non-admin users... ...If only we could make stupidity more painful...

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

    • Contrast this with Sun (Score:2, Interesting)

      by Anonymous Coward

      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.

      Compare and contrast this approach with Sun. Employees in Sun are all equiped with Javacards which they can insert into a Sun Ray appli

    • I'd hardly call an environment where users have full admin rights to their systems an adequate test-bed.
      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.

  • Let's hope they do (Score:5, Interesting)

    by creepynut ( 933825 ) * <teddy(slashdot)&teddybrown,ca> on Tuesday May 23, 2006 @10:46AM (#15386986) Homepage
    Who better to test and actually use the "User Access Control" than Microsoft's own employees?

    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)

    by mwvdlee ( 775178 ) on Tuesday May 23, 2006 @10:47AM (#15386993) Homepage
    "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 (Score:3, Insightful)

      by 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
      • Most people on Unix machines already run as normal users. Granted, since a lot of them are home machines they're also admins, but they don't escalate their privleges unless they need to install software or do some sort of maintenance. In normal day-to-day work they're normal users.

        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
      • "Just as powerful" and "harder to learn" in the same sentence is an oxymoron. Windows Access Control Lists APIs are a nightmare to program with that is also badly documented (or was the last time I looked at it).

        When you have two APIs that provide/achieve the same thing, the 'simpler' one is by far the most powerful.
    • Agreed. Although, I don't think this will improve security directly, as much as it will improve their QA processes, which in turn makes more secure and stable products. Maybe now they'll discover you can't run WindowsUpdate on an XP Pro SP2 machine without admin privileges, and fix it!
      • "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.
      • Maybe now they'll discover you can't run WindowsUpdate on an XP Pro SP2 machine without admin privileges, and fix it!

        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)

    by boxlight ( 928484 ) on Tuesday May 23, 2006 @10:47AM (#15386998)
    I don't see why this is a big deal. Average desktop users should not have admin rights -- no?

    boxlight
    • I think one of the biggest problems is that a lot of software was originally designed and implemented for Win9x. It doesn't have a security model like Win NT, so developers wrote code obliviously writing to HKLM (or open keys for reading but request ALL_ACCESS) or C:\Program Files\xxx\.

      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
    • Admin rights are required in order to spellcheck your Office documents (in older Office versions).

      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)

    by fishdan ( 569872 )
    would be if they'd remove admin rights from friggin Outlook

  • Excellent Idea (Score:5, Insightful)

    by Whatsisname ( 891214 ) on Tuesday May 23, 2006 @10:48AM (#15387006) Homepage
    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.

  • su got you a vist from security (Score:5, Funny)

    by DrDitto ( 962751 ) on Tuesday May 23, 2006 @10:49AM (#15387011)
    I used to work for a Fortune-50 company and we had Unix workstations for software development. The system was configured such that if you tried or accidently entered "su", you got a visit from security within 5-10 minutes.

    It happened to me when I mistakenly typed "su" instead of "du".

    • Re:su got you a vist from security (Score:5, Funny)

      by limabone ( 174795 ) on Tuesday May 23, 2006 @11:01AM (#15387095)
      That su*(#@&(*@&#NO CARRIER
    • You must've had a lot of in-house support if they treated developers like that. That is, most of the environments I've worked in required having to do many tasks considered admin jobs and these required getting in as root (usually sudo'ing). Even for satellite control systems I was constantly going in as root for drive admin, installs, etc. It would've taken twice as long to do anything if I had to rely on getting a hold of a full-time admin, submit a request, wait for them to take care of it, get a conf
    • I can just see the security guy now seeing "su -sk * | sort -n", and saying "Looks like DrDitto is trying to exploit su, better pull the shotgun out of storage."
    • That's stupid. There's perfectly acceptable reasons to use 'su'. And I work for $LARGE_US_BANK. I su from 1 user account to another all the time, depending on the task or application thats needed. And I'm not an admin.

  • Won't fly (Score:5, Insightful)

    by Utopia ( 149375 ) on Tuesday May 23, 2006 @10:50AM (#15387018)
    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 (Score:3, Insightful)

      by arivanov ( 12034 )
      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.
      • You may need admin rights to test and to package, but you should not need admin rightsfor 95%+ of the development cycle.

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

    • Since when does 'cc' require root privileges?

      Sure, testing installation would require it, but development? No.

      I'm sure one can run a per-user web server for testing web apps.
      • Ever heard of a thing called a "debugger"? It requires, at a minimum, the debugging privilege, which is as good as root because if you know what you're doing, youc an give yourself root with it.
        • Bullshit. I've used the debugger in VC++ and never needed anything
          of the sort.

          • Re:Won't fly (Score:4, Informative)

            by Anonymous Conrad ( 600139 ) on Tuesday May 23, 2006 @12:56PM (#15388010)
            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.
    • Hmm, I guess that lots of chairs will go flying...
  • I wonder what made them think about it in the first place... too much Banzai Buddy?

  • Would this mean... (Score:5, Interesting)

    by zappepcs ( 820751 ) on Tuesday May 23, 2006 @10:58AM (#15387065) Journal
    Would this mean that if they switch MS employees to Vista with only user rights, that Vista would be delayed yet another couple of years while they work out the bugs? If it doesn't work for MS employees, it can't possibly work well for anyone else. Surely, they have to make sure it works since its part of securing the system. Right?

  • If they want to installed firefox or opera... (Score:3, Interesting)

    by cyfer2000 ( 548592 ) on Tuesday May 23, 2006 @11:01AM (#15387092) Journal
    They will need to go to the administrors...Aha! No more firefox and opera from M$ campus.
  • i can't believe that an enterprise like microsoft has gotten away with employees having admin rights all these years. how did they prevent all those worms, viruses and trojans from infecting their pcs? i assume that at microsoft people mainly use IE and outlook; and this in conjunction with admin rights all around should really spell disaster.

    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)

    by omeomi ( 675045 ) on Tuesday May 23, 2006 @11:04AM (#15387116) Homepage
    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...
    • Win2K and XP Pro have had this feature for a while now.

      runas /user:DOMAIN\Administrator %ApplicationLocation% Now it would be a wonderful world if that worked in all cases. However installing HotSync or ActiveSync using another user does not work. You have to temporarily promote a user, install, then demote.

      My hope is garbage like above will be flushed out with vista.
  • Not only does Microsoft not restrict their own users to unprivileged accounts, but their Director of Internal Security has no qualms about stating that in an interview for the press?

    Advertising soft-chewy insides is for candy companies, not computer security experts.

  • If they don't, who can (Score:3, Interesting)

    by swanriversean ( 928620 ) on Tuesday May 23, 2006 @11:05AM (#15387122)
    If Microsoft can't implement this for their own employees, any CTO looking at Vista would be foolish to think that he could in his company.

    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)

    by Anonymous Coward on Tuesday May 23, 2006 @11:09AM (#15387153)
    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.
  • Er, I hope MSoft has a bit more sense than that. An employee isnt all that generic. Your basic manager just might be able run as a underprivilidged user, but the maybe 30% of actual coders will have a hard time of it. Quite often system coders need lots of privilidge, like to install dll's and drivers in %systemroot%, run kernel debuggers, mess with the registry etc....

    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)

    by suv4x4 ( 956391 ) on Tuesday May 23, 2006 @11:28AM (#15387299)
    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).

  • Firefox (Score:2, Funny)

    by lolindrath ( 149889 )
    How will they install Firefox then?
  • PCs have always been about having a bit of computing power under the user's control, which can be molded to projects that the MIS team are too busy/sleepy/detached/uppity to implement on big iron. That is the heart of personal computing in the workplace, and it has much less to do with a specific OS's philosophy than with a workplace's need for flexibility and initiative.

    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)

    by dindi ( 78034 ) on Tuesday May 23, 2006 @11:36AM (#15387373)
    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 ....

  • Here is the timeline here:

    (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

  • 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)

    by Nijika ( 525558 ) on Tuesday May 23, 2006 @11:46AM (#15387469) Homepage Journal
    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 (Score:5, Insightful)

      by naelurec ( 552384 ) on Tuesday May 23, 2006 @01:00PM (#15388035) Homepage
      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.

  • Yep... that WILL improve security. (Score:3, Funny)

    by Vo0k ( 760020 ) on Tuesday May 23, 2006 @11:54AM (#15387540) Journal
    The employees instead of typing the admin password will actively look for holes to get the admin rights, spot them and eventually later patch them. Things like "cancel" button in Win98 login screen won't get overlooked :)
  • 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.
    • 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, rea

  • Anything less would be hypocrisy (Score:3, Funny)

    by seniorcoder ( 586717 ) on Tuesday May 23, 2006 @04:41PM (#15389497)
    Seeing as they have already denied many rights to non-Microsoft people, they were looking for another segment of humans to restrict. It seems they have found it.

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close