I was wondering if you could assist me with a relevance statement/problem, I searched the forums but couldn’t really find an answer. I’m trying to run the relevance below but getting the below statement.
q: owner of security descriptor of file “C:\windows\system32\vbscript.dll"
a: The expression could not be evaluated : Windows Error 0x5: Access is denied.”
So while this isn’t what I wanted it is helpful because it let’s me know that the file has different ownership, and I can’t access the file, but I don’t know how to turn this into a relevance statement to check prior to using my action script that will take ownership of the file.
Overall problem : I’m trying to figure out a relevance statement for file ownership of the vbscripts.dll file, so I can build in my relevance to check if the machine’s vbscript.dll has Administrator as the owner or if something else has taken ownership of the file. Has anyone ran into this before and can offer more information?
I have tested on a few (4) computers, and it seems like the varied results are only on my machine. Going to remove the validation part from the original post.
q: (it as string = “NT SERVICE\TrustedInstaller”) of owner of security descriptor of file “C:\windows\system32\vbscript.dll”
A: True
T: 0.833 ms
It seems like in your example you’re saying you get an access denied error in QnA when the ownership has changed because you can’t access the file. When BigFix evaluates the relevance it’ll do it as SYSTEM, so presumably it won’t have the same access issue? In any case, if it errors or returns false you’ll know something is amiss.
Q: (it as string = “NT SERVICE\TrustedInstaller”) of owner of security descriptor of file "C:\windows\system32\vbscript.dll"
E: The expression could not be evaluated: Windows Error 0x5: Access is denied.
T: 23935
I understand that if I don’t get a expected result, something is amiss, but how can I build in relevance to check for this so it can only hit computers that I am getting this access denied message? Then I can blast it to multiple computers without having to worry…
The solution to this issue is to use the “Client Evaluation” mode of the Fixlet Debugger or to Just create an analysis with limited scope and make tons of properties while testing, then clean them up after.
The reason is that the client eval will happen as the SYSTEM account, which should not have this permission issue.
Windows is locking down permissions more and more over time so that certain things can only be done by the SYSTEM account and typical Admin privileges are not sufficient. Some relevance will evaluate just fine on Windows 7 as an Admin account, while the same relevance will require the SYSTEM account on Windows 10.
If the values still cannot be read from the SYSTEM account, then that would be highly unusual, but possible. I would definitely try the relevance through a bigfix analysis property and check the results, because BigFix running as a privileged service as the SYSTEM account may have more access than just typical SYSTEM privileges.
The other thing to try is getting the desired values WITHOUT relevance. Can it be done on the command line successfully through various methods, accounts, and privileges? If it is not possible to get the values outside of relevance, it might be similarly impossible to get them with relevance.
Another thing to consider, is that you might have antivirus or security software that is getting in the way of the relevance evaluation, preventing it from working. You might need to whitelist the BigFix client, which you might need to do for a variety of reasons.
Thanks for the response, I’m going to try the creating a analysis route and see if I can capture it that way and will report back. Also I have already confirmed that the antivirus/security software we use is whitelisted so it won’t get blocked that way.
(multiplicity of it, it) of unique values of (it as string) of owners of security descriptors of files "vbscript.dll" of (system x32 folders; system x64 folders)
You should note that there are 2 of these files, one in each system folder.
ALWAYS use plural relevance, particularly for reporting.
You don’t need to use the analysis to figure out which ones are affected if you put the relevance in the fixlet/task that actually does the fix, like this:
exists unique values whose(it != "NT SERVICE\TrustedInstaller") of (it as string) of owners of security descriptors of files "vbscript.dll" of (system x32 folders; system x64 folders)
If that is TRUE, then that means at least one of the files is not set to NT SERVICE\TrustedInstaller
The “Best Practice” when it comes to BigFix fixlets/tasks/actions is that they should only be relevant on the systems that require it, which also means they should no longer be relevant once a system has been fixed, thereby validating that the fix worked.
That said, I would also consider it a “Best Practice” to test relevance in an analysis property before trying to use it in a fixlet/task/action. You should read raw text values from systems to see what is there before trying to figure out how to turn that into a TRUE/FALSE result for a fixlet/task/action.
Awesome, I was actually just about to respond that I was doing what you mentioned and testing it out shortly (my relevance isn’t as clean/nice as your statement though lol). Thanks for all the assistance, really appreciate it.