Group recursion

[Meatballs1]

Should be faster as we dont have to query individual objects in a loop, the search results will return all the required properties.

Downsides - higher CPU load on the DC especially if there are lots of nested groups.

[HarmJ0y]

So just realized that there's a downside to this- if the nested groups include groups cross domain trusts (like in a forest), then the -Recurse option will only return groups within the current domain.

The other option seems to be going back to processing individual results. Any idea if there's a way to get the ldap "1.2.840.113556.1.4.1941" working across trusts?

[Meatballs1]

Ah bummer, does it show the external group so you could at least identify you are hitting the issue manually or does it just not display the external group at all in the results?

If it doesn't could we change &(objectClass=user) to &(|(objectclass=user)(objectclass=group) or similar and see if group gets shown? In which case we can then do a recursive query on the target domain?

[Meatballs1]

Or drop the objectClass completely...

[HarmJ0y]

Dropped the objectClass/samAccountType -> $GroupSearcher.filter = "(&(memberof:1.2.840.113556.1.4.1941:=$GroupDN)$Filter)"

This is still the result for a parent/child basic forest, with "Group3" in the child having a child member, a parent member, and a group in the parent (only the child domain member shows up):

[Meatballs1]

Hmm that sucks, have you double checked the count of $Members just to make sure some of the additional logic isn't filtering out accounts?

[HarmJ0y]

Yep, looks like it's borked unless I'm missing something:

So unless we can figure out some way to get the rule to work across relationships, we can revert to the old/slower way of manual enumeration, or keep the faster LDAP optimization, or maybe keep the LDAP version as default and have a flag that reverts to the old behavior? Thoughts?

[Meatballs1]

I think having both would be useful - probably default to the more accurate version and have the faster one as a fall back?

Advanced googling reveals that searching by tokenGroups might be the another approach for all recursive users and across domains as long as Global Cache is available..? Only brings back SIDs so you would have to query the user details, but at least you dont query each nested group individually?

[HarmJ0y]

Looked into that but couldn't get it working correctly- I'll play with the tokenGroups a bit more, and if I can't get it working I'll start porting back the old code and implement the flag component.

[HarmJ0y]

So tokenGroups storing the SIDs would mean that we would have to query the tokenGroups for every user in each domain in the forest (which takes some effort as it's a "special constructed attribute") and then comparing the SIDs of the target group against the complete user token set, correct?

I think this approach might be useful for "Get-NetGroup -UserName X" to enumerate the effective group memberships of a single user. For recursive group member enumeration, I'm thinking the best might be reverting back to the basic enumeration with the flag option.

[HarmJ0y]

Just pushed some changes - https://github.com/PowerShellEmpire/PowerTools/commit/2642d94c4973c92ee1a1e1c308ff80376e27d0eb

Get-NetGroupMember now reverts back to 'old' recursive enumeration functionality unless the -UseMatchingRule flag is specified (this flag name can be changed if you think of another term that's better). Should now enumerate relationships across trusts.

"Get-NetGroup -UserName X" now uses the tokenGroups method to enumerate all group membership for a particular user (https://github.com/PowerShellEmpire/PowerTools/blob/2642d94c4973c92ee1a1e1c308ff80376e27d0eb/PowerView/powerview.ps1#L3747-L3771) , including groups across trusts (previous functionality had the same domain-only results).