System.DirectoryServices.Protocols - Linux -> searching with only anonymous bind

[GrowSharp]

Description

I have anonymously bonded connection to AD. When I try to search (viz. code bellow)

var searchRequest = new SearchRequest(LdapConstants.SETTING_USER_BASE_DIRECTORY, searchFilter, SearchScope.Subtree, LdapConstants.SettingGroupSearchAttributeFilter.ToArray());

It throws: An operation error occurred.

Configuration

Domain joined CentOS 7.8.2003
.NET Core 3.1.301, commit: 7feb845744
.Protocols version 5.0.0-preview.5.20278.1

Regression?

When I try to do the same thing with connection bonded with credentials (auth type = negotiate) it works correctly. On the mentioned centos and even on Ubuntu 20.04.
On Windows it works correctly always.

Other information

Only stack trace I got: System.DirectoryServices.Protocols.DirectoryOperationException: An operation error occurred. at System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut) at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout) at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request)

[joperezr]

In order to properly search through a directory you do need to be bounded successfully to the server. In fact, I bet that if you go into the details of that exception you should see that the inner error is something like "A successful bind operation is required in order to search". The reason why this works on Windows is most likely because the machine you are running it from is fully domain joined to the LDAP server, in which case a successful bind won't be required.

[joperezr]

From the description above this does sound like is by-design and the only bit we need to make sure is that in @GrowSharp case the reason why it works on Windows is because the machine is domain joined. Once we validate that we only need to make sure that we have the same behavior on Linux when machine in Linux is domain joined as well. I'm marking this as "needs more info" in order to double check that and I'm also pushing this to future as this doesn't sound like something we can fix as it is by design.

[GrowSharp]

@joperezr
I'm not able to confirm or deny that. All the machines, vms and everything (except few linux machines) at work are domain joined.
Also, there is no more details for the exception I'm getting. If you think I should get a message like that, I'm afraid there is another bug, because it's not there.

[joperezr]

The easiest way to confirm that would be for you to try to run the tools ldapwhoami and klist from the Linux machine where you are trying to execute the application. If you are successfully domain joined, then you should see something like:

As you can see above, both commands execute successfully and return back the user that is authenticated against the domain. If you are not correctly domain joined, then you will see something like this instead:

You can see how in this case the check for authentication failed as there are no credentials cached and klist doesn't find a valid credentials cache file.

Our library will use exactly the same logic as the ldapwhoami tool in order to reuse authentication credentials, so if you can't run that tool, then our library won't be able to contact the LDAP server unless you provide credentials.

[GrowSharp]

I know I'm not domain joined.
So, we can close this one? As it's clear that it shouldn't even work in my scenario of not domain joined environments?
@joperezr

[joperezr]

Thanks a lot for checking @GrowSharp! Yeah, I think we should probably go ahead and close this one as by-design for now. Feel free to log a feature request if you think that this is not the right experience and we can see if we can do something different, but at least with the native library that we are using underneath it is unfortunately not possible to perform an anonymous search if you are not domain-joined. BTW, I want to thank you for not only logging all these important issues so we make sure the experience we want to provide in Linux is correct, but also for following up and helping us diagnose the issue by doing all these checks we request in your environment during the investigations 😄

[GrowSharp]

No problem @joperezr, I'm happy to help. I'm just kind of disappointed that I haven't been able to solve any of these issues myself. I thought it would be a great opportunity for me to become contributor. 😅 But at least I learned something about Interop and how you guys do this cross OS compatibilities.

[danmoseley]

@GrowSharp we would welcome you as a contributor if you want to look at a different issue. We have many opportunities;

https://github.com/dotnet/runtime/issues?q=is%3Aopen+is%3Aissue+label%3Aup-for-grabs
https://github.com/dotnet/runtime/issues?q=is%3Aopen+is%3Aissue+label%3Aeasy