Using sudowin to grant administrator privileges in Windows

In a way, this description isn't completely accurate, both because of what sudo is and the way Windows works. So, for the sake of explaining sudowin properly, I'll take a moment to describe sudo in detail.

In Unix, the sudo command allows you to launch a process as an administrator, provided you can supply administrative credentials (i.e., an admin password). This allows a user to normally run in a non-elevated context, but elevate privileges on processes that need it.

Managing Windows privileges Program helps admins control user privileges in Windows Secure network folders demand secure permissions

In Windows Vista, the RUNAS command and now UAC, allow something similar to be accomplished, but in a different fashion. When you use these features to run something as an admin, the command in question is run from an entirely different user identity -- one that has administrative privileges. This is why, for instance, if you run a desktop application in Vista that can run without UAC privileges, it often doesn't interact properly with other desktop applications that are running through UAC, simply because they're not running in the same userspace. This is not fatal, but it can be annoying, and it often forces the user to elevate multiple applications at once.

When faced with the way privilege escalation works in Windows, programmer Schley Andrew Kutz decided to "take the road less traveled," as he put it, and create something that functions more like sudo in Windows. The result was named sudowin, appropriately enough, and has been designed to allow extremely granular control over how privileges can be escalated on a per-user and per-application basis. Programs that run through sudowin are not run in separate user contexts, so they can interact with each other conventionally.

An .MSI package installs sudowin, which allows it to be delivered through conventional Windows software distribution mechanisms and makes it part of a system image if needed. Once installed, it's configured in two steps:

1. The administrator adds any users that will have sudo privileges to a specially created user group.
2. The administrator then configures an .XML file that controls the way the users' sudo privileges work. This step involves the most work, although the number of settings that need to be changed in the .XML file just to get things running is relatively small. It's only when you're doing more granular or large-scale deployments that it can become labor-intensive.

Each user can have a "whitelist" of applications that they're allowed to run in elevated mode or they can simply be allowed to elevate any application, period. The allowed applications are set in the main .XML configuration file. Credentials can be cached for a period of time, as they are in conventional Unix implementations of sudo. Finally, the program has a plug-in architecture to allow extensions to its functionality (the credential-caching function is one such plug-in), and supports features like only allowing sudo to run between certain times of day.

The biggest drawback right now is the difficulty of configuring the system for many users at once, since everything is done in .XML files. But at its core, this is an extremely promising way to extend on Windows's existing security mechanisms.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter . Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!