Securing MSIs to prevent theft

[MadDHatteR]

We provide a number of licensed applications (Adobe Acrobat, Office, etc.)
to our users via machine-assigned GPOs. In order for self-repair and
installation to occur, all our domain users must have read-access to the
MSIs. By hapenstance, the users have discovered where the MSIs are stored,
and have taken to copying them and installing them without authorization (at
home, or on other computers).

How have other admins dealt with this issue? How does one secure an MSI to
prevent theft, yet still allow self-repair and automated GPO installation?
(I'm all ears for ideas, links, or in-use solutions.)

Thanks,
\\ MadDHatteR

 

[Guest]

I could think of a couple of ways to stop this.

1. use UNC paths in your sourcelists but hide the shares.

2. put custom actions in the system that require something [%UserDomain] = "your domain" run a type 19 CA if the condition is not met.

darwin sanoy has a couple of scripts which can achieve this.

 

[MadDHatteR]

JOhnM

Thanks for the ideas -- it's nice to get some kind of reply. I was really
hoping someone had a sure-fire answer already figured out. As I suspected
however, it seems this feature was left out of the MSI and/or GPO software
deployment specification.*

The ideas I've come up with include inserting a custom action, altering the
UI Execute table so the MSI will not install by "just double-clicking"
(since these MSIs are strictly intended to be deployed via GPO), copying
MSIs local to the boxes and using "install elevated" so normal users can't
copy them, and of course what you mentioned below.

A custom action is limited in usefullness because many MSIs we deploy we
cannot edit/recompile/transform -- usually because they are not written well
(I can't think of an example right now... but I know we've run into this
problem before). I haven't looked much into modifying the UI Execute
table -- I only suggest it because I suspect with a GPO installation that
table might not be used... I need to do more research on this. Copying MSIs
locally is a cubersome option and the install elevated introduces security
risks I'd rather avoid.

In short, I don't think there's a GOOD answer, so I guess it's a
hack-something-together sort of thing :-(.

* If a Microsoft employee reads this, please consider including a means to
specify public properties (like the license key, for example) of an MSI when
deploying via GPO. This would simply and securely provide access control for
MSIs and prevent users from making illegal use of software. The license key
would live in Active Directory with the GPO's ACL (i.e. users couldn't see
it), and would remain separate from the MSI so the MSI was not usable
without authorization from IT.

\\ MadDHatteR

I could think of a couple of ways to stop this.

1. use UNC paths in your sourcelists but hide the shares.

2. put custom actions in the system that require something [%UserDomain] =

"your domain" run a type 19 CA if the condition is not met.