(imported topic written by SystemAdmin)
Looking at the analysis for Interactive Logon “Number of Previous Logons to Cache” (values “cachedlogonscount” of keys “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon” of registries as string) I see that some machines are returning a value of “0” and others return a value of “” - what’s the difference?
(imported comment written by SystemAdmin)
In what context are you seeing “”? (i.e. the Console)
(imported comment written by SystemAdmin)
From time to time, I see a result of “” while looking at the results of various analyses in the BES Console…
(imported comment written by SystemAdmin)
Ok, so I ran this relevance through the fixlet debugger : values “cachedlogonscount” of keys “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon” of registries as string
And using the “graphical” tab, it says that the registry key has an undisplayable result… What would cause that?
(imported comment written by SystemAdmin)
That generally means the value doesn’t exist. I’m unsure of what the behavior would be at that point as it isn’t explicitly listed in Microsoft documentation (possibly would result in default value being used, which depends on the operating system).
What site is this in?
(imported comment written by SystemAdmin)
Well, that’s what is odd about this situation - I have manually checked the registry to see if that key exists, and if so, what value it is set to. The registry setting matches the relevance… I.E. BigFix (and by extension, the Fixlet debugger) should return a value - the key DOES exist and is set to a value… so I can’t come up with a reason why BigFix is reporting the value as on some servers, and why it’s returning a “undisplayable result” message in the Fixlet debugger…
Could it have anything to do with the BigFix agent execution settings? I.E. - since the BigFix agent is running with system account privileges? I’m not sure why that would matter since system accounts execute applications with the same permission sets as administrator accounts, but it’s the only thing I can think of…
(imported comment written by SystemAdmin)
Oh, and it’s a custom site with custom written fixlets…
(imported comment written by SystemAdmin)
Hm, that is odd. Can you export the fixlet/analysis and attach it here?
(imported comment written by SystemAdmin)
The analysis is attached…
(imported comment written by SystemAdmin)
Just for grins, I decided to compare registry permission settings (using the powershell command get-acl) on two different boxes - I wanted to see if that might be the cause of the conflict.
Registry Permissions - Server 1 (Correctly reports value of registry key)
Path: Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Owner: BUILTIN\Administrators
Group: G:S-1-5-21-397955417-626881126-188441444-513
Access :BUILTIN\Users Allow ReadKey
BUILTIN\Users Allow -2147483648
BUILTIN\Administrators Allow FullControl
BUILTIN\Administrators Allow 268435456
NT AUTHORITY\SYSTEM Allow FullControl
NT AUTHORITY\SYSTEM Allow 268435456
CREATOR OWNER Allow 268435456
Audit:
Sddl: O:BAG:S-1-5-21-397955417-626881126-188441444-513D:AI(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)
Registry Permissions - Server 2 (Incorrectly reports value of registry key)
Path: Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Owner: BUILTIN\Administrators
Group: BUILTIN\Administrators
Access :NT SERVICE\TrustedInstaller Allow FullControl
NT SERVICE\TrustedInstaller Allow 268435456
NT AUTHORITY\SYSTEM Allow FullControl
NT AUTHORITY\SYSTEM Allow 268435456
BUILTIN\Administrators Allow FullControl
BUILTIN\Administrators Allow 268435456
BUILTIN\Users Allow ReadKey
BUILTIN\Users Allow -2147483648
Audit:
Sddl: O:BAG:BAD:AI(A;ID;KA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;CIIOID;GA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)
So, I can’t see anything in these results that would indicate that BigFix is mis-reporting data… Also, Server 2 doesn’t is only providing false data (i.e. a result of “”) for a few analyses…
(imported comment written by SystemAdmin)
Is this a personally developed content or is this from a TEM site? Also, what versions of QNA and the client are in use?
In regards to the given relevance in the analysis, the base relevance (prior to casting) should be as follows:
values “cachedlogonscount” of keys “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon” of (if x64 of operating system then (x64 registry; x32 registry) else (x32 registry))
I believe using “native registry” would also work in this instance.
I did some testing on various platforms, and it seems in 64-bit operating systems, the lack of an result in the 32-bit registry (in spite of having one in the 64-bit registry) coerces the results into an empty result set when using “registries”.
Do all those affected machines use 64-bit operating systems?
(imported comment written by SystemAdmin)
Well, it looks like changing the base relevance to “native registry” has done the trick (for the most part) - there are still a few machines that are returning “” on a few of the fixet/analysis statements, but it’s been reduced by 90% or so.
Thank you very much for that piece of information - it’s definitely helped.
Also, to answer your first question, it’s all personally developed from my organizations security policies.