PSExec runs with any or no credentials after running once.

Hi,

After a fair amount of hassles and great advice from EE users, I was able to run a vbscript on a remote server. ( http://www.experts-exchange.com/Programming/Languages/Visual_Basic/VB_Script/Q_22789041.html )

It works so wel now that it'll work with any username and pasword or even no username & password.

C:\Windows\System32\PSExec.exe \\192.168.10.111 wscript \\192.168.10.111\Export$\Export.vbs -accepteula -e -u 666666666666666 -p 9999999999999999999999

This code works even though the user doesn't exist. ?!?!?!?

PSExec seems to have locked the credentials or is using the system account.
The import results in Exact shows that it worked.

I have tried stopping the psexec service on the remote Win2K3 server and tried running the command again. This gave me the same result.
I am connected via a Cisco VPN client, which users different credentials than the ones the script should be using.

Anyone know what's happening?

LVL 2
DennisPostAsked:
Who is Participating?
 
RobSampsonConnect With a Mentor Commented:
Hi Dennis, would it be possible that you have some sort of cached credentials for the 192.168.10.111 resource?  Check in Control Panel --> User Accounts --> Manage User Accounts and see if there are any cached credentials for that resource.  If there is, remove them and try again.

Secondly, I would check the share and NTFS permissions on the Export$ share on 192.168.10.111.
The Share permissions should be Everyone at Full Control, and the NTFS permissions should be set as restrictive as you need it.  My guess would be that the share may be allowing even non-authenticated users to access it.

Lastly, if that is still not an issue, I'll take a look again at the export.vbs file and see if that may be somehow writing to a non-explicit folder (resulting in the Default User thing).

Regards,

Rob.
0
 
ubigConnect With a Mentor Commented:
Run at command line command NET USE. If you see connection to \\RemoteServer\IPC$ or to any RemoteServer disk drive, remove it by typing net use \\RemoteServer\IPC$ /del. Could be that somehow interprocess communication channel is created so you have to deactivate it.
0
 
DennisPostAuthor Commented:
Hi,

Thanks for commenting. :-)

Net use doesn't display any \IPC$

It does display \\192.168.10.111\Export$. I run "net use \\192.168.10.111\Export$ /del" and successfully removed it.
Windows explorer no longer allows me to connect to it. It cannot find it or I might not have permissions to it. It does not promt me to enter a username and password.

When I run the command again I get:
Couldn't access 192.168.10.111:
The specified user does not exist
This is also returned when using the administrators account and another non-admin account.

The VPN connection is still open.
I can ping the remote machine.
RDP to the remote machine works fine.
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
ubigConnect With a Mentor Commented:
Check if PSEXEC command works locally on the LAN to find out if that could be a VPN problem or local computer problem. If it works locally then it is very likely that your VPN connection somehow blocks Windows authentication. Try to open up everything for your VPN connection on router side and locally. If you are using domain accounts then you have to ensure you can reach all your domain controllers as they provide authentication and you can't tell in advance which one will. You could also try PSEXEC with remote server local account if that is not a domain controller (they don't have local accounts).
0
 
DennisPostAuthor Commented:
Sorry for the delay.

PSEXEC works fine on the lan.
I have no rights to do anything ith the VPN box.
All DCs are available.

I just used Process Monitor to find out what is going on.
The file I am starting imports financial data into a financal system.
The information does go into the system but does not save the XML with failed invoices in the right place.
For some reason it is saving it in the my documents folder of Default User. Instead of the my documents folder of the user used with PSExec.
0
 
DennisPostAuthor Commented:
Hi Rob,

Thanks for the idea's.
I have indeed check both share & ntfs permissions. I have also used Process Monitor to monitor everything on the server. I could see that the script was being run as the expected user but Exact was still dumping the xml in the wrong place.

I have decided to work with this problem instead of against it.
Exact version 380 will allow me to place the xml file with failed invoices in any location I choose.
In the meantime I will just pick up the failed invoices xml from the unexcpected location.

I will close and accept your answers because of the very usefull troubleshooting tips. :-)

Thanks again guys !!
0
 
RobSampsonCommented:
No problem.  I hope you can make it run smoothly.

Regards,

Rob.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.