This seems like strange behavior, unless I’m just misusing it.
In Relevance Debugger these produce True or False
q: effective read permission for “Power Users” of dacl of security descriptor of windows folder
q: effective execute permission for “Power Users” of dacl of security descriptor of windows folder
Any other trustee produces
Singular expression refers to nonexistent object
So if I use “Users” or “Administrators” or the name of any local user or local group it’s a nonexistent object
I thought I might have used singular where it should be plural, so I tried
q: effective execute permissions for “Power Users” of dacls of security descriptors of windows folder
q: effective read permissions for “Power Users” of dacls of security descriptors of windows folder
Those produce True or False. Any other trustee produces no answer, including “Administrators” and the user name of the administrator. (I get evaluation time and type plural boolean, but no answer.)
This is in Windows XP, BES client 7.2.5.22, relevance debugger 2.0.0.3
Have you tried running that Relevance via a simple custom action? That is, the Debugger sometimes produces different results than the Agent due to permissions, so it is useful to try running the Relevance outside the Debugger when an issue like this comes up.
I got the same results. “Power Users” true, “Administrators” failed and aborted the script.
if {effective read permission for “Power Users” of dacl of security descriptor of windows folder}
regset "
HKEY_LOCAL_MACHINE\SOFTWARE\test\acltest
" “ReadWinPU”=“true”
else
regset "
HKEY_LOCAL_MACHINE\SOFTWARE\test\acltest
" “ReadWinPU”=“false”
endif
if {… “Administrators” …}
etc
I repeated it with the plural version, “Power Users” true, “Administrators” and “Everyone” false. (I’m not sure “Everyone” exists as a local group, but “Administrators” does.)
Then I ran relevance debugger as system and got the same results as running it as me. (Custom action run cmd.exe, run debugger from that command prompt.)
Careful with “effective permissions” properties deployed widely… Depending on your AD setup, we have seen that these Microsoft APIs will automatically query AD (not in our control) from each agent, which can drive load to your AD server…
Thanks for the warning, that’s a good reason not to try to make this method work. Though I’d still like to figure out why it’s only working for one group.
Here’s the problem I was working on when this came up:
A while ago, pre-BigFix, I applied a Deny Execute permission to the Everyone group for one folder and a few files related to Outlook Express, now I need to remove that permission.
The removal script is easy, the problem is detecting that permission with a relevance.