Windows Vista introduces several security improvements paving the way for limited user account operation versus the de facto practice of privileged user account operation. In this post we look at what the two modes of operation mean to a developer and how to do some common tasks under LUA operation.

Overview

Why should I operate under a limited user account (LUA)?

• Over the Internet scripts, applets, callbacks and even the occasional executable run under your limited user account. After a month running this way you realize how many (thwarted) attempts there are to read and write to your local resources.
• Put simply: you gain insight. By running under a limited user account you are forced to learn about privileges, rights, identity and elevation. You learn what it takes to develop an identity-rights aware application. You learn how to work around those that are unaware.
• You are living test early and often to the fullest. How many times have you deployed software under a limited user account only to discover rights issues late in the game? By running as a limited user account, if your software works under your identity chances are greatly improved it will work under others.
• You are supporting software vendors that develop identity-rights aware products. If we all continue to run as administrator there is no incentive to get this thing right.

Why should I operate under a privileged user account?

• Temporarily elevate privileges to perform specific tasks. Return to your limited user access once the task is complete.

What is the state of support for limited user account operation?

• Support for limited user account operation under Unix/Linux/Mac OS X has been excellent for years.
• Support under Windows is excellent now with Window Vista and Windows Server 2008. Prior versions provide inconsistent support. The latest versions of most Microsoft software operate well under limited user accounts. Your mileage from other vendors will vary. Currently all my software operates perfectly fine under limited user account. There are some tasks that are inherently higher privilege e.g. attaching a debugger to a process, installing additional components. To perform these tasks I simply choose Run as administrator and provide the appropriate credentials.

This is a deep, multi-faceted topic. I do not take it lightly by summarizing the above. There are many, many considerations including IIS Application Pool identity, Windows service identity, SQL Server identity just to name a few. Full coverage of the master topic is at least a book of material. Better to point out a few tips that developers “trying out” limited user account operation will find useful.

Operation

What follows is a few tips for common development scenarios. You may extend the basic concepts to just about any situation.

Service Control

Months after I installed Windows Vista there was one remaining thorn in my side: service control. I tend to keep most services stopped until they are needed. For example, SQL Server is normally not running on my machine unless I need it. Prior to Windows Vista I could issue a command such as runas /user:root "cmd /k net start mssqlserver".

This stopped working in Windows Vista. The only workaround I came up with was to launch Computer Management as administrator, navigate to services, find the service I want to start. It worked but I knew it was not optimal. Several weeks ago a colleague [1] challenged me during a presentation when I said this was the only way. He clued me into a better way: enter SC.

1. Open a command prompt (Run as administrator)
2. Enter your SC command e.g. sc start mssqlserver

The general principle here is to open a command prompt with elevated privileges. Many commands requiring temporary elevation can be executed this way.

Visual Studio 2005

It was not easy, but after a hotfix and a rain dance Visual Studio 2005 handles itself just fine under limited user account operation.

Installation

Back in March this is what I had to do for Visual Studio 2005 to run under limited user account. When you read this post things may have changed; check MSDN [2] for the latest information.

1. Install Visual Studio 2005
2. Install Visual Studio 2005 Service Pack 1 Update for Windows Vista [3]

Debugging

It would be nice I guess for Visual Studio 2005 to provide an option for privilege elevation from within an instance running under limited user account. That is not available and I do not see it being developed. If you want to perform a privileged operation such as attaching a debugger to a process then start a new instance of Visual Studio 2005 (Run as administrator).

The general principle here is to open an application with elevated privileges so that you may perform specific tasks.

Filtered Token

Back in the day when we lifted void ** and used imported smart pointers, there was a lot of low-level coding around logon tokens. Early Win32 API documentation coined the terms process token and thread token. If you wanted to temporarily elevate your privilege e.g. on an ASP worker thread, you would create a logon handle and impersonate the thread token using that handle. Trust me, this all worked very nicely.

The story today is similar but with some cool foresight. Under Windows Vista members of the Administrator group use filtered process tokens. This means that even those accounts cannot perform privileged operations without user interaction. So even if you think all this LUA stuff is silly, you are still protected under Windows Vista.