In a previous article on WindowsNetworking.com called Running Windows Under Non-Admin Accounts, we looked at the difficulties associated with having desktop computer users run as ordinary users instead of administrators and examined some workarounds for getting around these difficulties. I asked for feedback for that article from readers, and I received a lot - some telling stories of non-admin problems they haven't been able to resolve and others providing tips from their own experience about how to resolve certain issues. I thought I'd share some of this feedback with you below (edited slightly for clarity) and add some comments of my own while pointing readers to some additional resources for enabling their users to successfully run as non-admins on their machines. Note that while my original article was published on WindowsNetworking.com, this follow-up is being published on WindowsSecurity.com since running as non-admin is really all about running with the least privileges possible, which is a security issue as much as it is a networking issue.
Stories from the Trenches
Hans Vaarkamp, a system administrator in Utrecht, says,
"With great interest I read your articles on the internet; I like to write some comment, although my English writing (not to mention my way of speaking) is not so good... The problems with users not being local-admin is today for our business a daily issue. Our business counts 400 employees with XP-client-machines (www.pkn.nl), spread out over 10 locations in the Netherlands, with our main-office at Utrecht. We use domain-policies, which we recently re-organized after your recommendations in your articles about policies. So, we use domain policies, not only for distributing software, but mainly for displaying a common desktop-environment and security. To our experience such policies are only effective on the local machine, when the users are non-admin, otherwise it won't work there. Our main security reason is the user itself: a lot of people are still not familiar with a lot Windows-possibilities, and very often our helpdesk had to get on their way to put back the disappeared quick-launch bar, find the disappeared (most of the time: replaced-) folders, remove accidentally downloaded software ("which my son recommended as the best antivirus-software, so what's the problem"; "it conflicts with our company's antivirus software, sir"), etcetera, etcetera. Sometimes we had to run a complete image over the machine (RIS), so in basic we are happy with a common desktop and users not being local-admin. In our experience only 10% of our employees complains about this. For them we created separate OU's with separate GPO's, and in some cases we had to made their account local-admin. But, as you are writing in your article, the main trouble is being created by the fact that a lot of applications will not work when the user is not local-admin. Today this took time-spending research, and indeed, most third-party software does not work properly or does not work at all with the user being not local-admin."
Hans's experience is typical of administrators in large enterprises, for if you're going to use Group Policy to lock down desktop computers then you can't give them local Administrator accounts on those machines or they'll be able to override those policies. Hans's solution for users who complain is a logical one too - putting them in a separate OU and giving them admin privileges - but it can quickly complicate your Group Policy infrastructure and could cause problems if any of these "super" users turn out to be unreliable employees. His comment however that many third-party software simply won't run properly (or even at all) unless users have admin privileges on their machine is a problem that there's no easy answer to, and much of the blame must rest not on Microsoft but on third-party vendors who failed to follow Microsoft's guidelines for developing applications to run under non-admin privileges. Windows Vista will change things in this respect (I hope) since it will force vendors to either make their software non-admin compliant or fail to achieve logo certification as "Certified for Vista" (or whatever Microsoft decides to call it) but it's likely that not all vendors will have their software updated for this feature by the time Vista is released, we'll just have to wait and see.
Stephen Eldridge found he
"had to shut off admin privileges for one group in my company. There were several younger guys in the group and they were constantly getting their machines corrupted with spy ware and other trash from installing file sharing apps. I took away admin privileges for everyone in that group and managed their requirements through group policies. The rest of the company I was able to leave as admin or power users and it works well."
Stephen's comments highlight that one of the main reasons users should run as non-admins nowadays is the danger of spyware infections on their computer. Spyware that installs with administrative privileges can basically do anything on your machine, so running as non-admin can limit the damage such infections can cause.
Simon Vart had a number of good comments and questions, and I'll deal with some of them inline:
"To make a long story short, my experience would summarize in few points...Using software often requires having an admin account. This is because of the precedent point: all software is in Program Files, in which non-admin user cannot write or modify anything. Developers usually don't bother using profile folder (documents and setting/application data) to write and modify program settings - so this is the same problem as installing software...This is not a windows default (despite the fact MS did encourage developers to use program files default folder), but essentially a conception problem when writing apps. It is possible to create software that would requires admin rights to install, but user rights to works. It is even possible to create apps that do not require installation."
Simon hit the nail on the head here i.e. third-party developers often don't write their applications to properly save settings in the user's profile folder, and this can often result in software that won't run except under admin privileges.
"You can't burn a CD without being admin. This is bad and shouldn't be, and is a windows problem relating to hardware management."
I personally haven't had this problem - I run as an ordinary user on my workstation and can successfully use RecordNow! Deluxe to burn both CDs and DVDs without any problems, so maybe this is more an application-specific issue.
"The most annoying problem which cause real security trouble is that the automatic install of windows update do not work properly without being admin. I let you draw conclusion of that, but if i'm using non-admin account, it is for security reason; but by using non-admin account, I cannot install updates (security center didn't trigger by the way) and my system becomes less secure." Simon later followed up with "By the way, it seems that windows critical updates are applied when using non-admin account. But the process is invisible (no yellow shield into taskbar)."
I don't know the answer to this as I've found that on my own machine some updates are installed and my machine reboots successfully without my intervention, while other updates seem not to get installed until I log on as local admin for some reason and see a help bubble informing me that Windows has downloaded updates and I need to restart my computer for them to be applied. Simon also says,
"I don't understand why .msi cannot install with "run as" option - and i tried in command line, without success."
This has also been a common complaint from many, but there's a solution! Open Registry Editor as administrator and create the following key under HKCR\Msi.Package\shell: HKCR\Msi.Package\shell\runas. Now set the default value of this key to the following: Install &as... Now create the following subkey: HKCR\Msi.Package\shell\runas\command. Set the default value of this subkey to the following: msiexec /i "%1" Now you should be able to right-click on a .msi file and select Install As from the shortcut menu. Finally, Simon concludes with
"I'm still testing non-admin use of Windows ; and I could add that it saves my computer for a infection some days ago. The virus opens but couldn't write itself into /windows/ so it just died when I close the computer."
The benefit is clear: running as non-admin can save your computer from virus infections and other malware, so even though it can be a hassle sometimes, everyone should try and do it.
Pablo Garrone says,
"I'm the admin of some labs in a university and I can tell you the pain of having to admin lots and lots of bad made software that does not run properly if you do not belong to the local admin group More than 500 students a day use the labs so imagine that I cant give them admin privileges on the PCs as if I did so I'd have to clone the machines daily. I cannot run the "trouble software" with RunAs because that would result in thousands of calls from the users to "put the local admin password" in the RunAs dialog. Fortunately we found software called "tqcrunas" that makes the RunAs command scriptable. So users double click the icon of Photoshop7 (one of the many problematic softwares) but this icon does not point to photoshop.exe, we make it point to xxx.tqc (photoshop.tqc for example) and this file contains (in a secure way) the desired username and password that can run the software without problems. The file is executed by tqcrunas.exe and... magic!! The software that needs admin privileges to run, runs perfectly being that the user logged in windows is not administrator of that PC." Thanks Pablo for pointing us to the tqcrunas utility, which readers can obtain here from Quimeras Software. Pablo continues: "That's the basic thing, then you need to fine tune .tqc files to avoid some little problematic details. For example, if you do not configure the .tqc file correctly a non admin user runs Photoshop (for example) via this tqcmagic and when the user saves a file in "my documents" tqc stores the file in the "my documents" that belongs to the profile of the user who executed the software and in this case its not the same "my documents". But being careful with these things it works. Its the best solution we found to this annoying problem. Yes it has some drawbacks but its worth the risk. For example running Photoshop this way means that if a intelligent user from Photoshop goes "file...open.... etc" inside these Windows dialogs has admin rights and could eventually go to c:\winnt..."
Obviously readers may want to look into using tqcrunas but you should read the documentation carefully to make sure you implement it securely.
Naresh Maharaj from South Africa says,
"Mitch, you are right on the money, I have the same feelings, problems etc. Maybe its time we go back a few steps, I have found that lots of companies are now moving toward a smart/thin client environment, using virtualization on their server environment thereby having one central point of administration."
That's an excellent solution too though obviously not for everyone. Using Terminal Services or Citrix to centralize your applications on your servers and use thin clients instead of desktop PCs can reduce a lot of security and manageability issues, and businesses may want to look into the cost/benefit of doing this, see the case studies here for some helpful guidance in this area.
Kari Farrell says,
"Thank you for the article 'Running Windows Under Non-Admin Accounts'. I too have been challenged. The current problem is trying to run the wireless adapter software (not using windows Wireless Zero program) as a User. The program starts up, receives an IP address and connects to the network, only when I am logged in as Admin. As soon as I log out and back in as User, the program will not initialize. I have been told to use the 'runas' command but I do not want the User to know the Admin password! I am an administrator at a school and I really would rather not assign Admin privileges to students. All other software for the User group seems to work except the wireless program. I am running Win XP Pro with all recent service packs and critical updates. The wireless adapter is by Phoebe 802.11g and b, 54mpbs and I have WEP encryption. The software is not digitally signed. I must say that I have a program called FilterGate running on every machine and when a new user logs in it asks if the program should run for that new user. What a great feature! It bothers me that some vendors won't go that extra mile to make their software friendlier! Thanks for any input you may have."
I haven't personally had problems running wireless networking products as non-admin, but I can sympathize with Kari's problems every time I want to use my wireless-enabled Tablet PC away from my domain-based network as I have to use RunAs to open the wireless configuration to change the TCP/IP settings as local admin. FilterGate by Internet Filtering Solutions may be part of the problem but I don't know for sure, but it looks like a great product. Which only goes to show though, the more security you add to a network, the harder it gets to manage.
Finally, Holly Lewis, a network administrator for a public school system in Georgia, gives her own take on how she handles this issue in her own work environment:
"We give the teachers and lab logons administrator privileges on their computers. Because of the "open" creative environment needed in education we feel this is necessary and cannot find a good way around it. Teachers want to experiment with educational software and be free to install it. They want to be able to customize their computers too. Since technology in education is such a high priority we need to make it as easy as possible for the teachers to use, otherwise they will not. Also, a lot of student applications used district-wide need admin privileges to run, such as Renaissance Learning's Accelerated Reader program, which is one of the highest priority applications that we use. However, we do have a huge problem with spy-ware/ad-ware resulting from this "open" environment. We don't have much of a problem with the users (teachers anyway) tinkering around with system files though. We run several anti-spy ware apps including Microsoft's AntiSpyware Beta, but they do not get everything. For lab logons I do use Group Policy to restrict Internet Explorer. All browsing has a high level of security restriction, approved sites are in the Trusted Sites Zone. This can be a headache because every site using Active X and Java etc... must be manually put into the Trusted Sites Zone. If the URL changes while using the site that URL must be added too. But it does prevent a lot of computer problems. If we just cannot get a site to work properly using Trusted Sites Zone the lab teacher has an option to log the computers on with an alternate logon that is unrestricted and has a password that the students do not know (hopefully). I also use Group Policy in the labs to lock down desktop settings, prevent access to the root directory, run command, etc... This has helped immensely in keeping the students from doing "things" to the computers. One high school is experimenting with individual logons for each student. This is mostly so that they can have home folders in which to securely store their projects. Of course we cannot make each student an administrator on every computer in the school, so this will present new challenges for us. In the media center (has a lab) they can always fall back to the media center logon that has admin privileges if needed. For the teachers and other employees we rely on their own common sense to try to keep the problem of spyware/adware down. We send out TechNotes giving tips on how to avoid the problem and instructions on how to use our anti-spyware applications. Hopefully they will be able to help themselves out of their problems now and then."
Wow, what a complex situation to handle with all the different user needs, but it sounds to me that Holly has got a workable solution going and I think readers can benefit by carefully reviewing some of the steps she takes to maintain a balance between security and usability/manageability within her networking environment. And ultimately anyway, you just can't get around this tradeoff between security and usability/manageability-it's just a fact of life we have to deal with as network administrators as best we can.
Got more suggestions or frustrations regarding users running as non-admin? Feel free to email me and maybe we'll follow this article up with another one with more reader comments on the subject!