Windows Without Admin Rights

It’s normal for Microsoft to transition their corporate environment to the latest and greatest software, especially as they transition towards RTM (release to manufacturing). However, it was quite interesting to hear that Microsoft is considering revoking local admin-rights during the Vista company-wide rollout.

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.

Live by the sword, die by the sword. I find it shocking that in a large corporate environment the policy allows for most everyone to run Windows as a local admin. Though this easily explains why it is such a pain to work as a regular user; Microsoft hasn’t had to struggle through the process yet.

Take installing software in the typical corporate environment.

In UNIX:

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 support.
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.
Software ties into centralized package management system so IT can keep tabs on security notifications, updates, etc and roll it (easily) into the centralized update mechanism.

In Windows:

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.
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.
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.
IT installs the software as administrator. IT logs out and notifies the user the software was installed.
A little while later, user contacts IT saying 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 repeats step 2 and 3 to finalize the software install. Unfortunately, the software refuses to run via RDP. IT has to either have local user login as a temporary admin to run the software or admin has to physically access the machine.
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.
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.
Admin decides to notify software company so hopefully next version is fixed.. software company’s support is not interested and state “admin access required”.
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.

I’m not jaded though – honest. Gah!!!

4 Comments

Kirk June 16, 2006

Very interesting article and something I hear all the time from people who eventually purchase our product. Bit9 provides the logical ability to allow Admin rights to all users, while still transparently creating a locked-down environment, including the ability to create different policies based on user or departmental level. For the enterprise that must be secure yet Open and Available, Parity makes perfect sense.
How we would work under the situation you illustrated so perfectly above…
1. user needs new software has admin rights but
machine is locked down via Bit9 Parity
2. IT receives the request and centrally approves
new software via Parity console
3. IT notifies user software is approved
4. User is running new software in minutes with
no technicians dispatched. Just a streamlined
approach to IT responsiveness and a dramatic
increase in both IT and end user productivity

check us out at http://www.bit9.com
Raemann June 22, 2006

I hope to not come off as a “windows flag waver”. Many of the problems can be centered around the familiarity to windows by common users, the tendency of users to own software that they have on home PCs and invariably install at work, and the number of windows PCs in the market compared to other computers make them a “hack target”. None of these are issues noticed in the Unix market. I will admit that there are grave issues with running the PC as a user rather than as an administrator, but the benefits outweigh the challenges in many situations and if they do not – DUMP the application for one that is written to work in a networked environment.
Until vendors realize a pinch in the pocket they seem unable to update/configure for non admin operation. We find that vendors we are calling as we add 3000 PCs to a MS Windows 2000 domain are saying, “Well, I don’t know where the registry hack to fix (you choose the problem) is but – if you find out LET US KNOW!” then you hear nervous laughter in the background. We can change this attitude but, it won’t be easy. I just hope that we can do so sooner than later.
Raemann June 23, 2006

More rant :

The landscape is changing. We in security and IT oversight have long noted that “home PCs” in the workplace were a security risk. Primarily because of the familiarity to practices which their users had grown accustomed. More specifically the notion that since this is the same OS, look and feel of what people have at home they are not “on their toes” and awake when it comes to business practices. What we found to be a common tendency involved users overlooking physical security practices on their PCs.
Among the myriad of additional weakness is the precursor to all failings in the notion that “This is MY computer”. Until we convince users that they are using a tool – much akin to a mechanic going to a tool crib for a wrench – we deal with a mentality that refuses to believe that they must conform to standards, practices or principles involving common use. I fear that the security fix may involve a great deal more work in carbon than silicon.
Adam June 23, 2006

You’re spot on Raemann, and i’ve never really thought of it that way before – I’m referring to the entitlement or ownership that users in the workplace feel towards their PC.

Generally, a mindset change can happen if a psuedo cause & effect situation occurs. User does not comply with procedure or standards put forth by the company, resulting in said problems with the PC – leaving the user without the tool to do his job. The catch22 is, as the person who must support my users, its in my job’s best interest to get them back up and running ASAP – so that they can continue doing their job and in turn, bring money into the company. However, should the users start seeing their tools disappear for longer stints of time – directly by their own mis-doing – then perhaps the attitudes would start to change? It’s a pretty cynical approach (the stalling of problem solving), but you are 100% correct that the change has to occur in carbon.