AdminPrivative: Design Specification for Partially Trusted Software Installation Delegation on a Windows Domain

In some Windows enterprise environments, it may be useful to grant certain people the ability to help users install stuff on their computers (probably laptops) via over-the-shoulder elevation without making them full domain admins. I outlined a strategy for doing something like this yourself, but now I have a pretty interesting idea that I might start developing.

Let's suppose you have issued laptops to a bunch of people on the assumption that each one is owned by a specific user and that the domain account for its owner will essentially always be the logged-on user. Suppose also that your users run as non-administrators and aren't allowed to do administrative things to their laptops, because it's usually a good idea to set things up that way. But your users occasionally do need to install programs, and you don't have enough time to OTS-elevate them, so you appoint a few people to do that. Since these people are supposed to just be administrators for the purpose of installing software onto these machines, they shouldn't be allowed to the domain or anything scary like that.

One possible option is to use Group Policy (or some system preparation script at set-up time) to set that group of installation helpers to be local admin on each machine. This has the major disadvantage of, well, letting them be local admin on every machine. Especially in a domain where remote server administration services are operating, having local admin is a very powerful thing. A group of people who you may or may not trust has full access to everybody else's stuff.

I thought of something better.

Forget about giving the install helpers' domain accounts any privileges. In this system which I call AdminPrivative (a pun on "alpha privative" and also a fairly accurate description of what it does), local temporary accounts are created whenever a normal user requests a software installation. The activities of those accounts are monitored, analyzed, logged, and reported to the real domain administrator's archives. A sketch of the design specification follows.

An AdminPrivative system consists of the following:

• Windows domain infrastructure
• A single authentication server/service, running as domain admin
• Local service on each computer eligible for AdminPrivative elevation

The AdminPrivative central server is a program running as a full domain admin. It should be under the control of the real domain administrator, not the install helpers. (All the install helpers have no special privileges at the domain level.) Its job is to listen for network requests (maybe serve a web form to gather the data) from the install helpers and authenticate them and get the control request. It then uses RPC (probably through PsExec or Sc.exe) to spawn the AdminPrivative service on the target computer.

The connection to the controller could be made on the target computer, but that would require entering credentials in a possibly compromised workstation. This system is designed in such a way that authentication to the central server should be done on a computer under the control of an install helper.

The local service prompts the machine owner to allow or deny the account creation. If the owner OK's it, the service prompts the owner for their domain password, checks it with Directory Services Account Management, and creates a local admin account. This account is added to the "Deny access to this computer from the network" list (using NTRights.exe) to prevent remote tampering. If the owner denies it (i.e. it was unsolicited), the local service tells the controller, which screams loudly into the e-mail box of the domain admin.

At this point, the local service tells the server that the account creation was successful, hands over the password to the install helper, makes a note of the time, and starts using WMI to monitor process creation. The server sends the temporary account's password to the install helper, who walks over to the laptop to perform an OTS elevation. The installer runs to completion, and after a few minutes, the local service destroys the temporary account and any processes laying around that it owns. It sends the log of processes created using that admin account to the controller, which generates a report of the entire transaction and sends it to the domain admin. If any issues are encountered (e.g. the local service stops responding), the controller complains to the domain admin.

The purpose of this entire system is not to try to stop the install helpers from doing bad things to the computers after they are granted control by the owner, but to log everything so that the domain admin can know what happened and who did what when.

Developing this would be a complex undertaking. I'm sure it will be an adventure!