Make System.DirectoryServices.DirectorySearcher cross-plattform (Linux/macOS support)

[rklec]

Description

In #14734 support for Windows has been added, in #23944 (comment) / #35380 Linux support for System.DirectoryServices.Protocols has been added.

#84831 and #37100 tracks related progress for making System.DirectoryServices.AccountManagement cross-plattform.

However, I'd really only like to use DirectorySearcher to simplify search the AD/LDAP for users.

Reproduction Steps

There are other simple wrappers around System.DirectoryServices.Protocols that already work and are the only cross-platform alternative. Or LinqToLdap, which unfortunately does not seem to be maintained anymore, (but is recommend by OWASP)

Expected behavior

Support that wrapper around LDAP just for searching on Linux/macOS, too.

Actual behavior

When importing it, I get error CA1416.

The doc also confirms this it "applies to" Windows Desktop (only), compared with System.DirectoryServices.Protocols.DirectoryRequest.SearchRequest, which applies to all .NET versions.

Regression?

No response

Known Workarounds

Use wrapper linked above.

Configuration

No response

Other information

#25121 is also about this issue.

[steveharter]

System.DirectoryServices.Protocols.DirectoryRequest.SearchRequest, which applies to all .NET versions.

Yes that assembly is cross-platform.

Can you use that cross-plaform SearchRequest class from there instead of the Windows-only DirectorySearcher for your LDAP scenarios? What functionality is missing?

[rklec]

Well... there is a reason DirectorySearcher as a wrapper exists for SearchRequest, is not it?

E.g. I then found LinqToLdap, which also wraps around SearchRequest, but e.g. amends it with features like:

• paginated queries (AFAIK DirectorySearcher supports paging this is kinda sad.) without needing to (re-)implement all that cookie stuff/handling - this is, personally, most important for me
• also, as the docs says for it it supports much more like integrated caching,

Also, it supports more features than DirectorySearcher, like:

• preventing LDAP injection through proper filter escape
• mapping results directly to models

[steveharter]

Pinging consultants @BRDPM @grubioe @jay98014. What is the feasibility of making this cross-plat?

[buyaa-n]

Also ping @joperezr for input

[joperezr]

It's been a while since I looked at it so this is very outdated, but IIRC the assembly (as I didn't just look at this type specifically) had a lot of windows-specific concepts which would make it hard/impossible or maybe just misleading to have it be cross platform. For instance, some of the APIs were leaking COM objects. We picked System.DirectoryServices.Protocols as the one to make cross platform as that one, on the other hand, had basically no windows-specific concepts and instead is essentially just a managed layer on top of the ldap protocol itself. For the request here, I agree with Steve and I would expect the existing API should be sufficient for most if not all use cases, as after all it is just a layer lower in the stack. In the framework we have a lot of cases where you can achieve the same thing via multiple ways, and in terms of ActiveDirectory management that's the same, were one is lower in the stack and more down to the protocol, whereas DirectorySearcher is just a higher level abstraction that makes it more user friendly

[khellang]

Well... there is a reason DirectorySearcher as a wrapper exists for SearchRequest, is not it?

DirectorySearcher is not a wrapper for SearchRequest. System.DirectoryServices.Protocols is an entirely different thing that operates on the protocol level and share very little code with System.DirectoryServices and System.DirectoryServices.AccountManagement (which are both based on COM and ADSI). Here's an old image floating around the internets showing the layering:

Of course, it might (or might not) be possible to re-implement DirectorySearcher on top of SearchRequest, but it's probably Very Hard™ and would probably break a lot of Windows-isms.

[steveharter]

Closing; not planned \ feasible.

[rklec]

Then what about adding support for paging and possibly other features I currently miss (which are not platform-dependent) or so in SearchRequest or a new API using this? Or should I open a new issue for that?

[khellang]

Then what about adding support for paging and possibly other features I currently miss (which are not platform-dependent) or so in SearchRequest or a new API using this?

Sounds like a nice opportunity for an open-source project 😄

[rklec]

an open-source project 😄

...like .NET runtime 😉