CPAU

Summary

Command line tool for starting process in alternate security context. Basically this is a runas replacement. Also allows you to create job files and encode the id, password, and command line in a file so it can be used by normal users.

Warranty

See warranty.

PlatForms

Current Version

Version 1.11.0 - November 08, 2005

Modification(s) from previous version

Security Requirements

On a Windows XP or Windows 2003 machine, no special permissions are required. On Windows 2000 "Act as part of the Operating System" right (SE_TCB_NAME) is required.

Language

C++. Compiled with Borland Builder 6.0

Source Code Availability

None

Story

CPAU is an extremely popular tool. My original point in creating this tool was two fold, the ability to pass the password on the command line and to start up with network credentials versus local credentials. The first couldn't be done with RUNAS, the second required me to add an additional parameter and I was running RUNAS many times every day and was sick of typing /netonly.

The use of this tool has gone through the roof. Unfortunately most people use it to enhance permissions on the local PC for logon scripts and other things like that so they are all stuck using the -profile or -lwp switches which force a local interactive logon. Note I said, stuck. That's right, I am not changing that functionality. When in doubt, type in -profile or -lwp. If you are trying to connect to a foreign machine with the enhanced permissions and the ID you are using can't be authenticated through the trust channels you will get an authentication error and you will know you need to get network credentials. If you are working in workgroup mode, you almost ALWAYS need network credentials instead of local credentials.

Now there is one fun thing that people don't seem to get the hang of with network credentials. When you establish them, the password is NOT verified until you try to connect to something. So you can type in any password you want and it will fire up the process for you. When you go to touch the remote resource is when you will catch the error if you typed the password wrong, keep that in mind, it is important. Note that the program isn't broken, that is how it HAS to work.

Another thing that confused people is security of network drives. When you spawn a process in another security context, you lose access to your current network drives. This is a security function Microsoft has been implementing. It wasn't the case in Windows NT and I know of no way to help you get it re-enabled because you can't. You should use UNC's as much as possible for connecting to remote file shares. See http://support.microsoft.com/kb/180362

One function that people kept asking for that I eventually added was the ability to encode the userid, password, and command line to be executed in an encrypted file. I have done that but instead of dealing with the massive issues in making encryption work well for everyone I have set up a proprietary encoding algorithm that seriously obfuscates the information in the encoded file. Again, this is NOT strong encryption, this is text encoding. I will say that the encoding is pretty decent but I have no doubt that someone who was seriously interesting in cracking it certainly could given enough time, plus there are other underlying mechanisms available to anyone who really understands Windows API that can be used to get the userid and password being used. On the positive side there is a large use of random numbers in the encoded file and the same command with the same ID and password will not generate the same encoded file two times. This makes it much tougher to crack the file and few people are running around watching things running in debuggers.

Along with the encoding option there is a -crc option that will allow you to generate CRCs for the files and store those in the encoded file as well. If the CRC check fails, the job file will not execute.

The format of encoded file is a simple text format so if you want to copy and paste it or email it to someone, you will be able to do so without hassle.

My number one email with CPAU is about people trying to use it to run logon scripts and it not supposedly switching the context of the user to the admin context. The answer is always, use the -profile or -lwp switch. My next most common email is people doing things with spaces in the paths and not properly using quotes. If something doesn't work right, use -profile or -lwp and use quotes before trying to contact me. Note that if you are using job files, you specify the -profile or - lwp on the command line when you decode the job file, not when you encode it.

Download

You do not have to supply the email address. I would like you to fill that in though so that I have an idea on how popular a tool really is. If I see 1000 downloads with 900 different email addresses I know it is more widespread than one that has 1000 downloads and 200 different email addresses because the same person needed to keep downloading it for some reason.

Email Address: Optional
 
Sponsored Link:

Version History


As seen in


Usage

    Download and type CPAU /?

See current usage screens