Welcome to the Privilege Authority Community

PrivilegeAuthority is a product from ScriptLogic that allows administrators to elevate privileges for specific programs, windows features or ActiveX controls, without running every user as an administrator.

Privilege Authority provides a powerful, flexible way to tighten overall security on a workstation, without preventing people from doing their jobs. It is available from scriptlogic.com and other popular download sites as a Professional edition and a free community edition.

Professional edition includes additional security capabilities and technical support from ScriptLogic. This community is for all Privilege Authority users to collaborate, brainstorm new elevation rules, share rules with other users, and provide bug reports and enhancement requests back to ScriptLogic.

Unanswered Active Topics Forums Search
Forums > Privilege Authority Community Forum > General Privilege Authority Discussion
Rule trouble
Last Post 06 Dec 2011 01:36 PM by Don Reynolds (ScriptLogic). 8 Replies.
Printer Friendly
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Evan SullivanUser is Offline
New Member
New Member
Posts:14

--
01 Dec 2011 05:09 PM  
I am creating a rule for an install. I have tested other rules and they are working fine. The install is in appdata\temp|<Numbers>\IDS-76.02.exe

The rule I have is for *\ids*.exe

That's right, right? It's not working.

Any help I would be grateful

Thanks


Don Reynolds (ScriptLogic)User is Online
ScriptLogic
ScriptLogic
Posts:61

--
01 Dec 2011 09:37 PM  
Hello Evan,



I would like to take a look at the client side log file to see what is happening.  Before trying your rule again, ensure that that logging is turned on the client (see the following blog for info on turning on logging: http://privilegeforum.scriptlogic.c...ion.aspx).



After setting the registry key to turn on logging, you should either restart the PA client host service, or just restart the computer to make sure logging is turned on.



Once logging is turned on, try running the process again and then attach the the CSEHostEngine.txt file to this posting (location of log file can be found in blog entry link above).



~Don


Evan SullivanUser is Offline
New Member
New Member
Posts:14

--
02 Dec 2011 01:23 PM  
I get a server error from that link (I found it though) Also I changed the rule to be the exact name of the EXE. I do need it to be *\IDS*.exe, because of the version numbers

Thanks

Said filetype not allowed so I zipped it.

CSEHostEngine.zip
Evan SullivanUser is Offline
New Member
New Member
Posts:14

--
02 Dec 2011 01:44 PM  
I've been looking through the log, boy it is hard to understand lol!


Don Reynolds (ScriptLogic)User is Online
ScriptLogic
ScriptLogic
Posts:61

--
02 Dec 2011 08:35 PM  
I agree that the log files are hard to read, but I can't find anyplace in that log file where the "IDS-76.02.exe" program was attempted to be started (or any program from the ".\appdata\" folder as mentioned above)



Log entries that begin with "New process event created (PID:" indicate when a new process is being started by Windows, so I would have expected to see a log entry like the following:

New process event created (PID: xxxx; Parent: xxxx; Path: C:\Users\user1\AppData\Local\Temp\isi9DE5\IDS-76.02.exe; Params: <>)

Am I missing something?  Can you try to capture this process launch again with the log file?



Thanks


Evan SullivanUser is Offline
New Member
New Member
Posts:14

--
02 Dec 2011 09:19 PM  
Well its a software updater program that downloads the installer and then runs it, could it be running under that process? So I would have to enter the executable name for the software update program and include all children processes?


Don Reynolds (ScriptLogic)User is Online
ScriptLogic
ScriptLogic
Posts:61

--
05 Dec 2011 01:23 PM  
Which process is the "software updater"? Is it the "IDS-76.02.exe", or is that just an installer that is downloaded and installed by the "software updater"?

If "IDS-76.02.exe" is actually just one of the updates downloaded and installed by the "software updater", then just as you inferred above, it might be better to create a rule for the actual "software updater" program (set to include all children processes) so that whenever the names of the updates change in the future (when they are no longer called "IDS-76.02.exe"), then your rule should still work to elevate these future udpates.




Evan SullivanUser is Offline
New Member
New Member
Posts:14

--
06 Dec 2011 01:05 PM  
That did it! Thanks!

I thought that you could just look at the executable that the UAC was catching and displays and THAT'S the EXE you put in. I must be wrong on that.

Is there an easy way to find out the name of the EXE to put in an elevate?


Don Reynolds (ScriptLogic)User is Online
ScriptLogic
ScriptLogic
Posts:61

--
06 Dec 2011 01:36 PM  
In general the technique you used should work, but when reading the your log file that .exe name did not show up, so I am not sure why it did not work that way for you this time.

Glad to hear that it is working for you now.


You are not authorized to post a reply.
Forums > Privilege Authority Community Forum > General Privilege Authority Discussion
Active Forums 4.2