1. KiXtart having access to the socket object is only half the story. KiXtart does not handle binary i/o at all well, so you will be restricted in what you can do.

2. You cannot expose the mechanism for getting authentication or password information in a script, as it can then be simply hijacked.

What you can do is have a client which connects to a service running on one of your servers, authenticates and requests a password. This can then use that password locally to initiate tasks and change security context.

In most real-world cases this is safe so long as:
  • Your handshaking protocol and conversation encryption are at least as strong as the one that MS uses when authenticating.
  • Your executable validates itself (MD5 cheksum) to ensure that it hasn't been messed about with.
  • All tasks are internal to the executable or on a trusted server. Never execute binaries or scripts on the local machine. Never execute a script which executes binaries on the local machine. If you "shell" out a command in any way, you are inviting disaster.
  • No member of staff who has access to the binary has the skills to extract the authentication routine and link to his own executable, or overwrite text strings in the executable so that it runs arbitrary code.


All-in-all it is a very tricky business. Using something like the task scheduler method to get jobs done is currently about the safest and by far the simplest method.