Protecting MSI's... after deploying them via SMS
Alright, I need some help and ideas from anyone willing to input on this.
We have an SMS server that deploys packages, we'll call it SMSSERVER. Now, when we create packages, they go onto a different server/share, namely \\PKGSTOR\data.
The problem? Well, currently we have the permissions set so that "Authenticated Users" have read access to \\PKGSTOR\data. I really don't like this. That means that ANYONE with a domain account, can obtain our packages and use them without our permission.
The reasoning as to why Authenticated Users have access? The MSI self-healing process. If a package is installed on an individuals machine, we'll say Office XP, and that person needs a component or whatever it may be- they have access to the original install location so that it can self-heal it's self.
In addition, if a new profile is created, the values under HKEY_CURRENT_USER need to be written, and this is usually solved by the MSI executing and putting those registry keys in place.
My question? What would be the best method of doing this? Is this a common problem in networks using SMS / MSIs?
Is there a solution to my worries?
Please give me some input, I'd appreciate it!
We have an SMS server that deploys packages, we'll call it SMSSERVER. Now, when we create packages, they go onto a different server/share, namely \\PKGSTOR\data.
The problem? Well, currently we have the permissions set so that "Authenticated Users" have read access to \\PKGSTOR\data. I really don't like this. That means that ANYONE with a domain account, can obtain our packages and use them without our permission.
The reasoning as to why Authenticated Users have access? The MSI self-healing process. If a package is installed on an individuals machine, we'll say Office XP, and that person needs a component or whatever it may be- they have access to the original install location so that it can self-heal it's self.
In addition, if a new profile is created, the values under HKEY_CURRENT_USER need to be written, and this is usually solved by the MSI executing and putting those registry keys in place.
My question? What would be the best method of doing this? Is this a common problem in networks using SMS / MSIs?
Is there a solution to my worries?
Please give me some input, I'd appreciate it!
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
dunnpy
17 years ago
liaisons,
There is no real way around this, as you said these authenticated users do need access to the package source.
However it appears that your packages are on a visible share, so someone browsing the resources on that server will be able to see the shared folder.
If you create your share with a $ after it, it won't be visible to someone browsing around, but packages will still be able to refer to it if necessary.
SMS does this by default if you are using SMS servers as DP's.
The below Microsoft KB link explains some of the principles - don't won't to appear to be teaching you how to suck eggs [:)]
How to create and delete hidden or administrative shares on client computers
Hope this helps,
Dunnpy
There is no real way around this, as you said these authenticated users do need access to the package source.
However it appears that your packages are on a visible share, so someone browsing the resources on that server will be able to see the shared folder.
If you create your share with a $ after it, it won't be visible to someone browsing around, but packages will still be able to refer to it if necessary.
SMS does this by default if you are using SMS servers as DP's.
The below Microsoft KB link explains some of the principles - don't won't to appear to be teaching you how to suck eggs [:)]
How to create and delete hidden or administrative shares on client computers
Hope this helps,
Dunnpy
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
