#246 GroupProbe ignores the domain name

[Michael Chisholm]

GroupProbe calls WindowsCommon::ExpandGroup()->WindowsCommon::GetLocalGroupMembers(), and WindowsCommon::GetLocalGroupMembers() splits off the domain and ignores it, so you could put anything you want as a domain for a builtin group, and it would work. I tried "foo\Users" and it produced an item with that as the group name. The group object entity is then just copied over to the item entity.

The domain name needs to actually be checked, and the object entity values should not just be copied over to the item entities. The operation has to actually be satisfied.

[Michael Chisholm]

Copying Chris's comments from bug #260 over here, since I think they're dupes.

ovaldi returns data for local group account when using a non-exisiting qualifier but an existing local group account name (e.g., nodomain\groupname) for a group_object\group entity. Specific to the group_test.

Solutions:
a. Report ‘does not exist’ when a non-existing qualifier is used in a group_object\group entity. This is a defect and we should most definitely update ovaldi.

Examples (current ovaldi behavior):
E1. Input: nodomain\Administrators
SC Output: nodomain\Administrators…
System1\User1
System1\User2
Domain1\Domain Admins

Used ovaldi-5.10.1.5-x64 on Windows 7 SP1

[Michael Chisholm]

This was mostly fixed in r1748, as a side effect of the group expansion changes. The group probe itself was not changed in that rev. Object entity values are still copied to item entities; it's probably safest for now to not fix this, for the sake of backward compatibility.

(Some details fwiw: WindowsCommon::ExpandGroup() now tries to resolve the trustee name to a SID with LookupAccountName(), and the latter does support domain prefixes. It will correctly indicate not-found, if the domain does not exist.)