Pstools part 2: preparing a client

After discovering pstools, I wanted to write a batch file to make clients more compliant to pstools. I got the grand idea of putting the batch file in the netlogon script of all the users; so all the clients would magically get compliant once a user logs on that specific machine. But alas, this plan fails, because you need system rights or admin rights to run the commands e.g. reg.exe and net.exe, to bore a hole in the local firewall (also, the group policies must be setup accordingly so that admin users have these rights).

To make a computer compliant you have to either image/ghost over the to-be compliant machine with an already compliant image or run this batch file and pray that it works. Or login with a superuser account on the target client machine and run this from netlogon (netlogon is to expedite things, but this is not compulsory), as I described earlier.

This command also works on most windows (professional edition) clients:

runas /user:administrator script.bat

or

runas /user:administrator@your-ad-network.tld script.bat

@echo off
REM Make pstools and rdp work on all client machines and add local superuser
echo "-- Make client compliant for pstools --"
REM pstools - make compliant from registry
reg add "hklm\system\currentcontrolset\control" /f /v SCMApiConnectionParam /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\loggedon" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psexec" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psfile" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psgetsid" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psinfo" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\pskill" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\pslist" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psloglist" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\pspasswd" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psservice" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\psshutdown" /f /v EulaAccepted /t REG_DWORD /d 1
reg add "hkcu\software\sysinternals\pssuspend" /f /v EulaAccepted /t REG_DWORD /d 1
netsh firewall set portopening TCP 445 ENABLE
REM md %windir% - give -c a location to push
REM net share admin=%windir%
EXIT

I also wrote the following script to create a default rdp (remote desktop) local admin user account to see from rdp what pstools is doing to the (remote) local user; Caveat! Don't let the password get intercepted:

@echo off
echo "-- Make client compliant for rdp (remote desktop) --"
REM "remoteadmin" user (XP machines, untested on vista or 7)
reg add "hklm\system\currentcontrolset\control\terminal server" /f /v fDenyTSConnections /t REG_DWORD /d 0
netsh firewall set service remoteadmin enable
netsh firewall set service remotedesktop enable
net user remoteadmin Supersecretpassword123 /Add
net localgroup administrators remoteadmin /Add
reg add "hklm\software\microsoft\windows nt\currentversion\winlogon\specialaccounts\userlist" /f /v remoteadmin /t REG_DWORD /d 0
EXIT

Pstools part 1

I wrote a wee nice batch file to make a windows-based client computer in an AD (active directory) environment in case pstools, namely psexec, is not cooperative.

For people in the know, pstools is a lot like ssh for unix (linux, bsd). I understand that there's a mingw?/cygwin ssh daemon out there, but I haven't used it yet.

Imagine that you're the system administrator and your colleague, let's call her Anna, (who is not in the know) is complaining that she does not have e.g. internet explorer on her computer.

Normally a hard-working competent administrator would have to walk all over there and take over the account find the icon for them or directly find the binary for the supposedly missing application and double-click it there, physically, manually.

Say you would like to check the validity of her statement from your current computer without walking all the way over there.

This is where pstools comes in. Imagine that you can find anyone's ip-address in the lan (local area network), because you assigned names to computers used by your colleagues and put that in the dns, mind you in AD this is registered by the dhcp server.

You fire up psexec and you type:


psexec \\roomAcompA -i -U anna -P S3cr3t "C:\Program Files\Internet Explorer\iexplore.exe"


\\roomAcompA stands for the computer A in room A, suppose that's the computer where Anna works, the parameter -i stands for interactive, which means the gui (if available) will be visible to Anna.

You call her up, and ask her if anything weird has happened. She'll tell you that internet explorer has magically popped out of nowhere.

You can also take over her machine by typing:


psexec \\roomAcompA -s -U administrator -P S00p@S3kr1t "cmd"


The parameter -s stands for "system", which stands for system rights granted to the current user. This is comparable to local root permissions for unix systems.

If you're currently running pstools as a superuser on the AD network, the -U and -P parameters could be omitted.

You could also pass local commands with system rights like this:


psexec \\roomAcompA -s "cmd" /C "taskkill /pid 0"


This would unabashedly kill a certain process with pid (process id) 0 with system rights. This is just an example what you could do with psexec.

To kill processes, pstools has the pslist and pskill.