How to Develop .NET Security Code as a Non-Admin

• By Keith Brown
• Nov 18, 2004
• Sample Chapter is provided courtesy of Addison-Wesley Professional

This chapter is from the book
.NET Developer's Guide to Windows Security, The

The trick to developing code in a nonprivileged environment is to have your main interactive logon be nonprivileged but to keep an admin logon in your pocket for those times that you need it. Look, it doesn't take administrative privileges to edit a text file, and that's what you're doing most of the time when you're programming, right? And you don't want your programs to require admin privileges to run, which is the point of this whole exercise. So your main logon, where you write, compile, link, and test your code (and where you surf the Internet, of course) should be nonprivileged. However, during development you will occasionally need to create a virtual directory in IIS, add a user account, or add an assembly to the global assembly cache, and that's where your secondary logon comes in handy.

By far the easiest and cleanest way to get a second logon is through Terminal Services. For example, if you develop code on Windows Server 2003, just run the command mstsc to bring up the remote desktop connection dialog; then press the Options button, fill out the form as I've done in Figure 9.1, and press "Connect." You'll get a window running in a second terminal services session, with a new desktop, running as whomever you specified when you filled out the form. Just minimize this window and bring it up whenever you need to do something as an administrator! If this doesn't work for you at first, then bring up the System control panel applet as an administrator. On the Remote tab, check the box that says "Allow users to connect remotely to this computer."

Figure 9.1 TermServ into your own computer!

Unfortunately, as of this writing this trick only works on Windows Server 2003, not on older platforms like Windows XP, because of licensing restrictions. With the version of Terminal Services that's built in to the operating system, you're allowed only a single connection to the console on Windows XP. Even on Windows Server 2003, you may not be able to use this feature because it's mutually incompatible with the "offline files" feature, which you may already be relying on. If for some reason you can't use this mechanism, don't give up hope. You can use the Secondary Logon Service instead. Read on.

The Secondary Logon Service

This service, introduced in Windows 2000, allows you to easily run with multiple logons. If you're familiar with UNIX, this facility is similar to the su command, at least in spirit. The secondary logon service can be accessed three ways:

• Programmatically (via CreateProcessWithLogonW)

• From the command line (via the runas command)

• From Explorer (via the "Run As" context menu item)

If you're not familiar with this service, try the following experiment. Running as an administrator, log out and log back in as a non-admin (create a normal user account locally if necessary). Once you're running as a normal user, press the Start button in Explorer and navigate into All Programs, Accessories, and select (but don't click) the Command Prompt shortcut. Once it's highlighted, right-click it to bring up the context menu (if you're running Windows 2000, you'll need to hold down the Shift key while you right-click—for some screwy reason this feature was hidden in that operating system). When the context menu appears, you should see a menu item called "Run As." Click it to bring up the Run As dialog. Select the radio button that says "The following user:" and notice that the built-in local administrator account is selected by default. Type the password for the admin account and press OK. You should see a new command prompt appear—this one running as the administrator. Verify this by running the command whoami ^[1] from this new command prompt or, if that's not available, just type set username instead. Now, imagine keeping a little command prompt like this down at the bottom of your desktop, always open, always waiting to execute your commands in a privileged security context. Any program you start from this command prompt will run as administrator. Nifty, eh? But we're nowhere near being done yet. Read on.