Ability to perform nested group searches using MemberOf field

[Borgquite]

Noted under the documentation that:

_'TameMyCerts uses the MemberOf (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-ada2/cc24555b-61c7-49a2-9748-167b8ce5a512) Active Directory attribute (against the mapped accounts domain).'_

and that one cause is that 'nested' group memberships are not supported.

I wondered if it would be possible to lift this restriction using the LDAP_MATCHING_RULE_IN_CHAIN LDAP search string - so you can perform an LDAP search which returns whether a user is a (nested) member of a given group simply by using:

(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)

It's part of Active Directory and described here - would make role-based access control a possibility?

Just a thought

[virot]

After reading through the entire source. TameMyCerts currently reads the MemberOf for the user and does not do a search per say. A change like this could be implemented, but it would require rewrites and could/would affect performance on the connected Active Directory.

[Sleepw4lker]

Hello @Borgquite and @virot. I have this on my backlog and was thinking about mitigation the performance concerns by making the behavior configurable. But I also had talks with AD experts who told me it should be absolutely tolerable performance-wise. So @virot if you plan to make another awesome contribution, you're highly welcome and i happily handle testing and documentation. Otherwise please give me some time to implement it myself ;). Cheers

[virot]

My plan would be to do a boolean option. One question, do we have version limits for Windows?? I know there are some "never" stuff that only exists in Windows 2016 and later..

PS C:> (Get-ADObject -SearchScope Base -SearchBase (Get-ADUser "$env:username") -Properties memberof -Filter ).'memberof'.count 10 PS C:> (Get-ADObject -SearchScope Base -SearchBase (Get-ADUser "$env:username") -Properties msds-memberOfTransitive -Filter ).'msds-memberOfTransitive'.count 57

But if we want to have support for Windows 2012 ADs, I would recommend to just code with old fashioned: (get-adgroup -LDAPFilter "(member:1.2.840.113556.1.4.1941:=$(Get-ADUser "$env:username-s"))").count

Just doing Powershell, to give example pre implementation.

[Sleepw4lker]

When I started the project, I targeted it for Windows Server 2019 (thus .NET 4.7.2 as this is the pre-installed LTS version), but with support for all Windows OSes in mind that were supported by Microsoft at that time, including Windows Server 2012 R2. Now that Windows Server 2012 R2 is out of support, and we are a security project, I would argue we could drop support for it.

I have built a Pester testing framework for everything that cannot be done with Unit tests / requires a fully deployed CA - so basically automatically create an AD Domain with CA and templates and then run against all supported OSes. I'll upload that soon, that should ease the testing a lot.

I think it is also time for a contributing document explaining some thoughts that I have architecture-wise.

Again, thank you so much for your work!