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. 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 off 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.
 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.
 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?
 I honestly do not recommend this.