[wpkg-users] wpkgCreateReport Update

[Malte Starostik]

Hi Mark,

Am Samstag, 22. August 2009 20:28:00 schrieb Mark Nienberg:
> I tested with the "Execute After" command and could not get it to work
> correctly.  In my case the share where I need to copy the file is a samba
> share and I don't really want to make it world writeable.  It appeared from
> my testing that wpkg tried to connect using the SYSTEM account, which has
> no password and no account on the samba server.

The SYSTEM account will use the client's machine account (which does have a 
password, just one you don't personally know) iff you're using AD.  Please 
refer to my reply to Lukasz' mail.
Without an AD, you will have to use some "regular" user account to access the 
share and configure the clients to use it.  The password storage is pretty 
much as secured as the machine password is with one major drawback: unless 
you're going to add a separate user account for each client, a compromised 
machine will force you to change the single password and propagate the change 
to the remaining clients.  With machine authentication, all you need to do is 
deactivate or delete the machine account and it will no longer be able to 
access your server(s).

> Eventually I decided to do the copy as a wpkg package with "Execute
> Always", so the user/password specified in the client is used instead of
> SYSTEM.  This has the disadvantage that it might be out of date by one
> reboot, unless someone can tell me how to make this package execute last.
>
> Another option might be to use a daily Windows Scheduled job, since you can
> specify user/password there.

The task scheduler is one option, some others come to mind (not intended to be 
an exhaustive list):

* The connection to the distribution share the WPKG client set up is still 
connected when the Execute After script is run.  You could then have just one 
subdir writable to the respective user and deposit the XMLs there.  This is 
quite viable and rather secure, only with the bad taste of a storing the 
password for a most probably shared account.

* You could point Execute After to a batch file that sets up its own 
connection via net use - but this is a lot worse than the above as you'd need 
to include the password in plain text in the batch file while the WPKG client 
stores it in the LSA database instead.

* You could sandbox the clients' access by creating a subdirectory for each 
client machine and setting up a share for use with one of the above means or 
even anonymous, including the machine name in the path via samba's variable 
expansion, so the share is called e.g. \\setup\reports on every client but in 
fact points to a dedicated directory like /srv/reports/host1 on the server.  
This option's security level is basically determined by what variable you use 
for the path name and what it takes for a rogue client to forge its value.

* Instead of a simple copy, you could somehow upload the file to a web server 
that authenticates the client by other fancy means.

Regards,
Malte