As I have mentioned previously, CPAU is an app that I have on the joeware site that is amazingly popular but not something that really excites me and isn’t one the utilities that I really love. It was just sort of something I whipped up to help myself in a couple of cases with a bunch of stuff added in later to help others.
Well now I come to a crossroads, one of the big uses for CPAU is escalation of the security context to do things locally, usually from logon scripts. That isn’t what I had in mind when I wrote it but that is how the program is being utilized by a vast majority of the consumers so that is how people perceive it and as a good ~friend of mine recently mentioned to me… perception is reality. Well after going over my utilities, CPAU, because of that primary de facto use, is the one utility of the bunch of them that has the most chance of being impacted. In fact, it is a 100% chance that it is impacted.
So why did I originally write CPAU? Well I was lead ops guys for the AD in a large company and helped out on a lot of things other than that AD environment so found myself needing to use a lot of different security contexts. I am, of course, a command line guy and from the command line you use runas to start different security contexts. Specifically I would type a command like
runas /netonly /user:somedomain\someuser cmd
and then enter the password when prompted. The runas tool defaults to interactive authentication and I rarely need interactive and usually couldn’t even use it because I was often hitting machines with security contexts that I couldn’t authenticate via the trust path. That caused me to to decide to make an app that was similar but defaulted to a network auth instead… Initially I thought the API I would use would be CreateProcessAsUser… Hence the name – CPAU. In the end though I used CreateProcessWithLogonW so the more accurate name would be CPWLW but that just doesn’t flow like CPAU does… Plus the command line name I type for it is very handy in that it is a left hand character, then a right hand character, then a left hand character, then a right hand character… i.e. very quick to type because one hand isn’t doing a majority of the work, it is split up[1]. While CPWLW fits that same criteria, it is longer and just doesn’t flow. Plus now that I have taken the number one google slot away from the City of Palo Alto Utilities I wouldn’t want to give it up… I watched CPAU grow up the rankings a long time to reach that coveted first hit… And as we all know, whoever has the first hit, well they know the most about that topic don’t they? 😉
For my purposes, CPAU will be just fine as the network cred stuff will still work just fine in Vista. The folks that will be impacted will be the MAJORITY of the user base who use it for logon scripts and local escalation on desktops when their users who are ALREADY running with normal security levels need a bit more kick to accomplish something like maybe a tweak or some software installs or what not. These folks didn’t actually need MSFT to change things to run with least user permissions. They will have the option to just turn UAC[2] off[3] and have things continue working as they are or try to find new ways to do things.
The problem is that when you use CPAU to change the security context, if you change to an ID that has administrative rights but is NOT the builtin administrator ID, the administrator SID in the token will only be used for DENY access, the new process will not actually be escalated in security capability. This kind of defeats the whole purpose of escalating the security context… If you use the builtin administrator ID, happy days, no issue, the account will act like a full administrator and you can do what you want. Personally I thought that was a horrendous idea… We have spent years trying to get people to not use the built in administrator ID because it is GENERIC and you can’t really track what individuals are doing with it and then Microsoft comes along and makes it special to the point that some people will end up feeling they have no choice BUT to use it. Thanks.
The alternate options to use the builtin administrator ID for the enhanced security context is to mark CPAU to be run as an enhanced user which pops the secure desktop to get the permission to do so… Only that also defeats the whole purpose… if the user had those rights, CPAU isn’t needed in the first place.
One might be tempted to argue that CPAU isn’t needed anymore, people should be able to do everything they need to do through other mechanisms. I don’t believe that is true. I expect for at least some time there will be things that folks need to accomplish that they will not be able to accomplish because they can’t put up the mandatory requirements to to use the MSFT methods or they just aren’t willing to pay for other mechanisms from MSFT say like a full SMS setup or what not. There will be old legacy packages that are needed for Critical LOB apps, etc that for some reason or another won’t be able to be repackaged in another way to take advantage of new install techniques, the issues could be technical, political, resource based, whatever, you name it. So there will be people that need in Vista what CPAU gave them in XP.
So I am looking at the problem and trying to work out what I am going to do; if anything. My current vision is a whole new utility called CPAUEx or CPAU+. I have determined ways of pulling things off so people won’t have to jump through the hoops I mentioned above. It isn’t any special hacking or anything, just standard architecture stuff. But it means I have the ability to put something together so folks could use the existing CPAU encoded JOB files and CPAU will perform identically and the process will end up with the exact same rights/permissions it had before. It doesn’t mean whatever was launched will still work because whatever “it” is, could do something else Vista blocks, but it should help out considerably. While I have come up with a plan on how to do it, I haven’t actually decided if I will or not. If I do, I will probably add some other functionality like being able to execute something as LocalSystem and also work in the cases where CPAU didn’t work which was when someone tried to launch CPAU from a process running as LocalSystem (from the scheduler or IIS or some other service). I would also look at using actual encryption instead of encoding and finally… I would also, and don’t get sick, visualize a GUI to configure the JOB files because some folks seem to have a lot of issues with that.
If you use CPAU now, I would be interested in hearing your thoughts. I would also be interested in hearing how much you think you and others would be willing to pay per instance or for an enterprise license of this new utility.
joe
[1] Yes believe it or not, when I make command line tools, I do often think about the typing sequence for the command when naming it… Weird huh.
[2] I dislike the name UAC and user account control… It isn’t very explanatory and it stomps on the name of the userAccountControl attribute which has been around in AD for 6+ years and the user account control field which has been around in NT forever… So now anytime someone says user account control I have to try and figure out of the three things what they are talking about. What was wrong with LUA – Least User Access?
[3] I honestly do not recommend this.
Your program doesn’t work :tear:
“I would also look at using actual encryption instead of encoding”
that would be appreciated 🙂
I would really like to use your product…But I am not sure how to make it work! You have no instruction on how to use/install/run the script? We are trying to enable admin rights temporarily for a batch file which installs printers on the local machine.
Let me know what to do !!!
First off, it isn’t a script. It is a tool that may allow you to run a process in an alternate security context. I say may because some apps don’t always lend themselves to this. To get basic help, type CPAU /? or look at
http://www.joeware.net/freetools/tools/cpau/usage.htm
Encryption and a GUI would be good, but not mandatory. But whether GUI, command line, or both, the tools that produce the job files should be distinctly separate from the runtime engine that executes the job files.
The use case of creating the job file is completely different from that of executing it. It would also have the advantage of lightening the load that must be distributed to remote machines connected by low bandwith (e.g. wireless) pipes.
Not a comment but a question.
Your description of use as of 1.1100 says that you are purposely disallowing use from LocalSystem. I have a couple of apps I am trying to deploy and do not have a domain. Will I be able to install these apps using a standard local admin account on xp sp2 workstations?
Yes the localsystem change should not impact this unless you are launching from localsystem account.
I have used CPAU in several cases where the educational software I am required to support requires that the students have modify access to both the local installation of the program and or modify access to important files on a network share. Sounds incredibly stupid? You bet it is, as students (especially High School) will delete the entire program or remove a critical file so that it fails and then they get to goof off and complain to the teacher that Program X doesn’t work and of course the campus staff blames the technology department. The people who develop this software are security clueless, and are shocked to learn that students will exploit this. So, I use CPAU to start Program X in a user context of an ordinary domain account that happens to have modify access to files they require. If they start windows explorer and try to navigate through the folder(s)/file(s) they get a big fat access denied courtesy of NTFS, but the program still runs because I replace the shortcut with one that points to CPAU with the proper command line options or a script that calls CPAU. I put the job file in a folder that cpau can read but they can’t get at through windows explorer and as extra security use the encoding feature. I would appreciate true encryption. I use CPAU for other things too, like running some custom scripts to monitor student activity, and being able to start a process from a scheduled task that starts as system would be useful. Anyway, CPAU is like a dream come true for XP, but I am dreading the loss of some CPAU functionality under Vista. Please continue to develop the program. I am not that interested in a GUI version, as so far I exclusively use it within scripts or shortcuts.
Nice tool btw!
Feature Request (or if you know of a tool that will do this…)
I am using cpau to launch a networked dos app as another user for security reasons (it has a remote shell feature – scary) – I want to use the task scheduler to launch it remotely. This kind of works…
I would like to see the ability to use the -wait switch and then have CPAU kill the spawned task when its killed.
That way when I end the scheduled task, the DOS app also ends. As it stands, CPAU ends but the DOS app remains.
I may end up having to write one myself but I am sometimes lazy when it comes to writing apps for myself
Well, I ended up writing one myself using C# (had to use a hidden window to properly monitor an exit from the scheduler however)
Now sure if I can reliably do this from a true console app without some kind of watchdog app that has a message queue like a win app. Ideas?
Thanks,
Rob
CPAU ist propably one of the best runas-tools available. I’ve found no other tool that waits for the started process to complete and returns the the proper errorlevel. This two options are essential for batch use.
Please continue support/bugfixing/adding new features!!!
As for the mapped drives issue there seems to be workaround, but its complex. You have to map your drives as LOCALSYSTEM. Network drives maped from LOCALSYSTEM are available to all sessions/processes.