/build/static/layout/Breadcrumb_cap_w.png

custom action xcacls - need to be run by a spesific user

Hi,

I've got a custom action running xcacls.vbs to set permissions on a folder that's getting installed by my msi package.
the problem is that when I install the msi file, the permissions are not added as they should.
What I've figured out is that when I run the xcacls.vbs command locally on the server as a user from a certain domain it works as planned.
(an important detail is that the domain user I need to add is from another domain than the domain the server is a member of. this is why it's more complicated.)
Is there a way I can run my custom action as a spesified user?
In the msi script session I've used the "execute program from destination" and placed it in the "Execute deferred" secion.

Thanks!

0 Comments   [ + ] Show comments

Answers (11)

Posted by: jcarri06 14 years ago
Senior Purple Belt
0
Have you already tried specifying the permissions through your packaging tool? In WPS, for example, you can specify what permissions you want on any directory through a couple of mouse clicks :).
Posted by: anonymous_9363 14 years ago
Red Belt
0
The problem with that, J, is that it populates the LockPermissions table, well known as The Spawn of The Devil, in that the permissions that it sets are not additive. Thus, you have to ensure that you add all the users which require permissions, including all the usual groups (Administrators, etc.) and you have to use their SIDs to do that. Of course, those usual groups's SIDs are equally well-known but it's just a bit of a palaver.

Having said that, what the OP actually wants is to run the CA as a different user, which is easy enough: just use RunAs. Whilst it is indeed easy, its use obviously exposes that user's password, unless you go through substantial hoops to encrypt/decrypt it.
Posted by: jgb 14 years ago
Orange Belt
0
Thank you both, I've been thinking about the same solutions already.
The reason why I haven't used the "builtin" option in WPS is that I don't want the new permissions to overwrite/prevent other permissions.
The RunAs command is a solution, but I'd prefer to avoid the RunAs command if possible to prevent revealing the user password...
Posted by: anonymous_9363 14 years ago
Red Belt
0
I don't see how else you're going to run a CA as a different user (other than using a similar tool to RunAs). Alternatively, you may want to emulate the CA via a different route, e.g. from a script run against a machine or user group...
Posted by: jgb 14 years ago
Orange Belt
0
I've done some more testing, and this is what I've found out so far:
When I first started my test I copied the command which I'd put in Custom Actions and tried to run this in a command prompt locally at the server.
Still had problems, but running as a another user went fine in the command prompt.
So I tried to use icacls.exe instead, and when I tested this command in a command prompt locally at the server I didn't have to change user.
I thought I had solved the problem, but nope, when I put the same command in the Custom Action/msi script - deferred, I still had a problem.
So I'm confused now. How come I could run the command in the command prompt as local administrator without any problems, but still have problems running the msi file with the same user credentials? any clue?
Posted by: anonymous_9363 14 years ago
Red Belt
0
I suspect you have the CA set to run in System context. If you will always be installing the package with local admin privileges, change it to run in User context.
Posted by: jgb 14 years ago
Orange Belt
0
I've been looking in the wrong direction! Turns out it was an IF condition -which leads me to another question: When making a condition, choosing "ignore case" in the condition builder - shouldn't that make the value case insensitive?
Turned out that one letter was uppercase instead of lowercase, and that was enough to stop the IF condition happen!
Any way I can make the values case insentive?
Posted by: AngelD 14 years ago
Red Belt
0
Any way I can make the values case insentive?
Property:
MY_PROPERTY="TEST"

Below condition will resolve to true:
MY_PROPERTY~="TeSt"
Posted by: jgb 14 years ago
Orange Belt
0
Thank you all!
Posted by: jmcfadyen 14 years ago
5th Degree Black Belt
0
assign the perms to a local domain group.

put the user into the group. Then the fix is scalable, individually adding a user account is a bad idea.
Posted by: jgb 14 years ago
Orange Belt
0
Thank you for your feedback! I was a bit unclear, but I'm already using a domain group.
And after the IF problem got solved, both xcacls.vbs and icacls.exe works :-)
In my experience the pro about using icacls is that all W2K3, SP2 servers already got it installed, so I don't have to put the xcacls.vbs file in the package.
it also seems to go faster and doesn't seem to be dependent on a domain user running the command. (if the permissions is assigned to a user/group in a domain)
The cons about icacls is that there is a reported bug concerning editing inheritance permissions and ownership, but there is released a hotfix from Microsoft which should take care of this
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ