Running Windows Under Non-Admin Accounts

Everyone knows that one of the most important principles of network security is least privilege: grant ordinary users only those rights and permissions they need to get their work done and no more. For example, if ordinary users don’t need access to sensitive data stored in the Accounting share, don’t give them any permissions on that share, either through shared folder permissions on the share itself or NTFS permissions on the folder underlying the share.

Least privilege is more than a security principle, it’s also a lifesaver as far as the day-to-day job of administrators is concerned. Reason is, users are curious creatures and tend to push the envelope of what company policies allow and forbid them to do. Give a user local administrator privileges on their computer and they’re likely to try all sorts of things like installing additional software, changing configuration settings, and even poking around the registry to see if they can “tune” their machine to make it run better. From an administrator’s point of view however, this can be disastrous since the wrong tweak might break some application or even render their machine unusable. The user then cries for help and as an administrator you pretty much have two choices: wipe their machine and re-image it from your standard desktop image or spend useless hours trying to troubleshoot their problem. The second choice is usually a waste of time unless, contrary to company policy, the user has been saving important files on their machine instead of on the network. And the first choice is almost like spitting in the wind—you re-image the user’s machine and he just goes and fools around with it again.
Group Policy is one way of locking down what a user can and cannot do on their computers and using their credentials. But what if company policies (or culture or politics or on the job realities) mean that your users need to have the ability to install their own software and configure settings on their machines? If this is the case, you have two choices: give your users local admin privileges, or don’t. Since the first option causes the troubles I’ve described above, let’s explore the feasibility of the second option.

Installing Software As Non-Admin

So how do you install software when you don’t have admin privileges on a machine? The tedious way is to log off, log on as Administrator, install your software, log off, log on again with your ordinary user account, and then start using the software as an ordinary user. The fancier way of course is to use the secondary logon feature (the Runas.exe command) of Windows 2000 and later. With .exe files (and .msc files or consoles) you can right-click on the icon and select “Run as…” and then specify local admin credentials for installing the program. Unfortunately the “Run as…” option doesn’t appear when you right-click on .msi files, but the workaround here is to use Runas to open a command prompt (cmd.exe) window using admin credentials and then run the .msi file to install the app.
Unfortunately, some programs after they’ve been installed with admin privileges using Runas still don’t work properly when you try and run them as an ordinary user. This is because when you use Runas to install something, any per-user settings that the install routine creates are written to the user profile for the local Administrator account instead of to the user profile of the currently logged-on ordinary user account. And of course that causes problems when you try and run the installed program later as an ordinary user. Once again, the developer who wrote the program could have worked around this issue, but why bother when everyone runs Windows as Administrator anyway?
I’ve experienced this kind of thing myself several times with both third-party Win32 apps and also .NET Framework applications, and it’s frustrating. For example, I recently wanted to take an e-learning course in ASP.NET application development from Microsoft. Unfortunately for some reason I couldn’t download the course (a .NET app itself) when logged on using my domain user account, so I opened an instance of Internet Explorer using local admin creds and successfully downloaded the course. But when I tried to run the course locally on my machine, it wouldn’t run when I was logged on as ordinary user. So I tried using Runas to run the course under admin privileges and it still wouldn’t run. In the end I had to log off, log on as Administrator, download the course, and run it while logged on as Administrator in order to get it to work. Frustrating! Maybe if I investigated the problem further I might have discovered why it didn’t work the first time, but that just illustrates in the first place why most people run Windows under admin privileges all the time—if you aren’t running as admin, you can waste a whole lot of time trying to make things work.