The Windows platform has always struggled with administration and privilege. In its early days, Windows typically filled departmental and small-business niches, where one or two human beings needed to wield essentially unlimited power over their handful of servers. As Windows grew to fill roles in larger networks, both the OS and the server products built upon it did not always evolve to include more granular permission structures for administrators. The result has been an industry that, in general, relies on fully-privileged administrator accounts to accomplish even minor administrative tasks. We know it is a poor practice, but what else can we do?

Fortunately, several different events and technologies are converging to provide an exciting new opportunity.

The Problem with Administrators: Too Much Privilege

The traditional problem with server administration has been that administrators simply have too much power. The well-known and –established Principle of Least Privilege (PoLP; sometimes called Principle of Least Access or PoLA) states that a user’s account should have only enough privilege to perform the task at hand. In reality, that would require administrators to have dozens and dozens of user accounts, each one carefully crafted permissions for various specific tasks. That is obviously impractical. Actually, it is often impossible, simply because server products rarely offer security settings that are granular enough to make such a thing possible. There is just no way to configure products’ permissions so that users can be restricted to perform very constrained, specific tasks – and nothing else.

This situation creates two unfortunate results. First, administrators typically use a single “normal user” account and a second “all-powerful” administrative account – essentially, “all or nothing” when it comes to privilege. Second, it is often difficult to give every user in the organization the ability to do their jobs efficiently. Because products do not offer highly granular security, many users are prohibited from performing administrative tasks simply because they can’t be given a user accounts that has less-than-total powers. “In order to perform that one task, I have to give you permission to basically do anything, so I’m not giving you permission to do anything.”

The industry’s approach, thus far, has been scattershot. Individual Microsoft products address the problems in different ways. SharePoint Server has its own internal users and groups; Exchange Server has its own unique Role-Based Access Control (RBAC) system. SQL Server uses it own system of server and database roles. Every product is different, creating a mess that’s difficult to configure, difficult to audit, and difficult to even figure out.

Organizations often attempt to compensate through the use of home-grown tools. Administrators created scriptbased tools like HTML Applications (HTAs) and packaged PowerShell scripts that are run under a highly-privileged account, giving “normal” users a limited user interface with which to accomplish specific tasks. These are also a security nightmare: They often rely on hardcoded high-privilege credentials; they create ongoing maintenance overhead, and often offer little in the way of formal logging and auditing. They’re “hacks,” brought about by necessity and the lack of truly granular permissions in the server products.

That’s why, in most organizations, Principle of Least Privilege is observed more in thought than in deed.

A Solution is Right in Front of Us - Almost

Administrators who create home-grown “proxy tools” – tools that run with high levels of privilege but restrict their users’ capabilities by internally limiting what they can do – actually have the right idea. In fact, there’s a long history of thirdparty software vendors who create well-architected tools that use the same approach.

Essentially, vendors create proxy administration servers. Administrators use the vendor’s management interface, which provides its own granular permissions. The interface limits what admins can do, and the proxy service itself performs the actual actions under a highly-privileged account. Professionally built tools provide better management of highprivileged accounts, better audit trails, and so forth.