Added new 'user_has_signed_into_explorer' element to ntuser state/item per #306#323
Conversation
solind
left a comment
solind
left a comment
There was a problem hiding this comment.
Can't this test already just be implemented as a relatively straightforward ntuser_test?
|
This is for filtering out the entire ntuser.dat from being in scope for other tests, which I don't think we could without it being part of the item/state |
|
Oh. Well, you could do it using an object, and then a filter using a state and entity var_ref that points to something in that object like the SID. But I confess that would be cumbersome to author by hand. |
|
@solind I would agree that it's quite likely possible, but combersome for sure, and no new content author would ever think to do it. Adding it to the item/state makes it trivial and understandable from a content author perspective, with very little R&D on the application side. |
… with last_logon documentation
…add-new-itemstate-entity-user_has_signed_into_explorer-to-allow-filtering-out-of-non-interactive-user-profiles
|
@balleman-ctr given your comment on issue #306, I'd like your review of the PR if possible, so we can proceed with it. |
|
@solind and @balleman-ctr I'm wondering if this could be better implemented as a behavior? Probably eaiser and faster for content authors vs filtering with a state, as I'm not sure how much value the item element really has to end users? I don't have a strong opinion either way, but we could add exclude_users_never_signed_into_explorer = "true" with the default being false. |
|
@vanderpol that's an interesting idea as well -- and even simpler to implement as a filter. I feel the need to ask... "Windows Explorer" is not the thing now known as the Edge browser, is it? Do you mean "Windows File Explorer"? |
|
Good catch, I didn't realize Windows Explorer (not Internet Explorer) is now officially Windows File Explorer. I'll change either the new element or behavior if we come to consensus and approval |
|
@balleman-ctr or @jspearman19 any thoughts on a new behavior, vs a new element to use in a filter? |
|
On the behavior vs filter question - I think we could work with either - but I'd lean toward a filter. The reason is that we already use ntuser_states to filter out disabled users and user profiles not modified in 35 days. So I see adding another filter as more readable than having a filter-like behavior, but then still having two filters. @balleman-ctr or @jspearman19 , let me know if you disagree. |
|
I lean towards adding as a state/item element (filter approach) over behavior. This lets us collect and see that piece of information, which would be helpful while troubleshooting. As for “Windows File Explorer” vs “Windows Explorer”, the file description on explorer.exe is still “Windows Explorer” (at least for me on Win11 25H2). I wonder if the “File Explorer” label in the "start" menu is more of a user convenience than a formal name change. The aspect we’re concerned with is its role as the default Windows shell. Alternatively, we could describe it as explorer.exe instead; maybe they will be less likely to change that over time. |
|
It appears the consensus is for it to remain as an element, with plans to use it as a filter. As for Windows File Explorer vs Windows Explorer, based on @balleman-ctr suggestion, would this text update suffice? "The user_has_signed_into_explorer element describes if the user account has ever executed explorer.exe" |
|
@vanderpol, the change makes sense to me. |
5 participants
Added new element to state/item which allows content authors to filter out users that have not logged in interactively and can be a source of false negatives, as this partial profile does not receive GPO's