Abstract
There can be ntuser.dat files from accounts that cannot received GPO's and will never be able to comply with most security policies (service account profiles, profiles created from WinRM sessions etc... and the collected item for the ntuser test should include a new element with a name somthing like "has_logged_to_windows_explorer" which would a boolean that content authors could use to filter out undesirable ntuser.dat files, much like is currently done for enabled, and days since last login.
In each ntuser.dat from a human user that has logged in via Windows Explorer, will be a key called UserSignedIn located in: Software\Microsoft\Windows\CurrentVersion\Explorer which will be a REG_DWORD of 1 or 0 to indicate if the user has logged in.
There might be other ways to determine this as well, but the SCC team has found this to be a reliable method for the past few years.
I would dare to say this is really a 'bug fix' more than a feature, so I'm interested in other OVAL board members feedback if this could be rolled into OVAL 5.12.3, and then be included in the upcoming SCAP 1.4. If we include this in OVAL 5.13 as a feature, it will have to wait for SCAP 1.5
Abstract
There can be ntuser.dat files from accounts that cannot received GPO's and will never be able to comply with most security policies (service account profiles, profiles created from WinRM sessions etc... and the collected item for the ntuser test should include a new element with a name somthing like "has_logged_to_windows_explorer" which would a boolean that content authors could use to filter out undesirable ntuser.dat files, much like is currently done for enabled, and days since last login.
In each ntuser.dat from a human user that has logged in via Windows Explorer, will be a key called UserSignedIn located in: Software\Microsoft\Windows\CurrentVersion\Explorer which will be a REG_DWORD of 1 or 0 to indicate if the user has logged in.
There might be other ways to determine this as well, but the SCC team has found this to be a reliable method for the past few years.
I would dare to say this is really a 'bug fix' more than a feature, so I'm interested in other OVAL board members feedback if this could be rolled into OVAL 5.12.3, and then be included in the upcoming SCAP 1.4. If we include this in OVAL 5.13 as a feature, it will have to wait for SCAP 1.5