Last week, I wrote about why you should try not to use administrative accounts unless you really need to. Several readers wrote to explain various scenarios and problems they've encountered while trying to use a nonadministrative account for certain tasks. Some of the problems involve using Windows Explorer, running debuggers, creating Data Source Names (DSNs), and accessing Control Panel items. Obviously, you'll need to log on as the administrator in some instances; using RunAs, even with the /netonly switch, might not always suffice.
There are other possible solutions for some problems too. For example, Microsoft's OS resource kits include the su.exe tool, which can elevate privileges. Another tool, which I've mentioned before, is MakeMeAdmin, written by Aaron Margosis at Microsoft. The tool adds your account to the local Administrators group, spawns a command shell with your new elevated privileges, and then removes your account from the group.
So, effectively, MakeMeAdmin gives you a command shell running with a new security token. You can perform whatever actions you need to in the shell. If you also need privileges on the network, you can initiate some kind of network access and authenticate by using whatever account you prefer. For example, you can map a drive by using the command
net use
and specifying an account with the required privileges. Or you could launch Windows Explorer on the desktop with elevated privileges by using its /root switch. You could also launch Control Panel applets by simply entering the applet name and extension (.cpl) as if it were any other executable program. If you run Microsoft Internet Explorer (IE) with elevated privileges, you can use Margosis's PrivBar add-on that shows which security level your browser is running under.
http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx
http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/195350.aspx
Another reader wrote to point out that Microsoft has published a document that explains some of the problems you can encounter when you run applications on the desktop with nonadministrative accounts. The article offers tips about how developers can remedy some of those problems and offers some insight into how the next release of Windows (codenamed Longhorn) will address the matter in more effective ways. One change will be a Protected Administrator status, which, if I understand correctly, will allow a user to use an administrator account but with the fewest privileges necessary for a given task.
http://msdn.microsoft.com/library/en-us/dnlong/html/leastprivlh.asp
Another topic I want to discuss this week is root kits, which as you know, can be a real problem. A Microsoft paper discusses research the company has done regarding ways to discover such nuisances. The paper mentions a related tool, Strider Ghostbuster, developed in the labs, which isn't available to the public.
http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=775
However, Sysinternals has a root kit discovery tool that you might find helpful. The new tool, RootkitRevealer, is still undergoing development, but you can download a copy and try it out.
http://www.sysinternals.com/ntw2k/freeware/rootkitreveal.shtml
F-Secure will release a beta version of its new root kit detection tool, F-Secure BlackLight Rootkit Elimination Technology, this week. You can learn more about that tool in the related article on our Web site.
http://www.windowsitpro.com/Article/ArticleID/45631
