System.DirectoryServices.Protocols - Linux support

[brunobritodev]

I'm trying to make a LDAP Connection under aspnet:3.1-buster-slim container. It returns the error:

System.DirectoryServices.Protocols is not supported on this platform

I found a PR #35380 which says that support Linux now. My nuget package is 5.0.0-preview.4.20251.6 from may 18.

Am I missing something?

Configuration

• Which version of .NET is the code running on?
  .NET Core 3.1

• What OS and version, and what distro if applicable?
  Debian 10

[vcsjones]

I don't think preview4 contains the PR. The preview4 branch was last committed to on May 1st: https://github.com/dotnet/runtime/commits/release/5.0-preview4

And the Linux support was merged on May 7th: 55d3260

So the cut for preview4 was taken before this change was merged.

It does appear in the preview5 branch.

[brunobritodev]

Great! So I suppose the next preview version will be available.

[danmoseley]

@brunohbrito when you do get the bits to try could you please let us know your feedback - even if you do not encounter any problems? This is the kind of feature that can have configuration specific issues and the more validation we get thru release the better. Cc @joperezr

[joperezr]

@brunohbrito just wondering, would you be willing to try our nightly builds so you get a chance to try this now? If you’d rather wait for next preview that’s fine too. Preview 5 will have Linux support but won’t have default credentials working yet (meaning you don’t need to pass in credentials to ldapconnection if your Linux machine is domain joined) but preview 6 will have that plus OSX support. Nightly builds have all 3.

[brunobritodev]

@joperezr I'm getting into night build right now, I'll try it and them I give you some feedbacks

[brunobritodev]

Hi @joperezr / @danmosemsft ,

To do theses tests I'm using an Active Directory under Windows Server 2019 Datacenter.

Scenario 1 - Authenticating user

I'm running the following code snippet both for Windows and Linux Environment.

var credential = new NetworkCredential("<username>", "<password>");

var connection = new LdapConnection(new LdapDirectoryIdentifier("<ip(13.0.0.0)>", 389, false, false), credential)
{
    AuthType = AuthType.Ntlm
};

connection.Bind();

Windows Environment - Running in .NET Core 3.1 and .NET 5.0

The code runs fine.

Linux - Running in a container. runtime:5.0-buster-slim

At first run I got an error:

Unable to load shared library 'libldap-2.4.so.2' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibldap-2.4.so.2: cannot open shared object file: No such file or directory

To fix that, I've changed the Dockerfile adding apt-get:

FROM mcr.microsoft.com/dotnet/core/runtime:5.0-buster-slim AS base
RUN apt-get update && apt-get install -y libldap-2.4-2
WORKDIR /app

Then I got a 2nd error: The supplied credential is invalid.. (Running on Windows (wldap.dll), everything was ok)

So, to fix that I'd to concat the domain name with username. <domain-name>\<username>:

// FROM
// var credential = new NetworkCredential("<username>", "<password>");
// TO:
var credential = new NetworkCredential(@"<domain>\<username>", "<password>");

And the connection was successfull. Even when added domain at NetworkCredential Ctor didn't work

Linux - Using runtime:3.1-buster-slim

Everything was fine, except by the needs to concat the <domain>.

libldap suggestions

I was looking at libldap docs. bind_s and simple_bind_s actually are the same and just support LDAP_AUTH_SIMPLE.

So, why we don't concat domain name in every case (when it's available) for Linux?

My suggestions is, at BindHelper() on LdapConnection.cs line 1099, remove this if and put it into Linux / Windows specific logic.

I've made a PR, in case you agree to theses changes.

Scenario 2 - Searching

I was trying to search a user specific metadata by following code snippet:

var searchFilter = $"(|(mail=joao.silva@brunobrito.net)(sAMAccountName={username}))";
var searchRequest = new SearchRequest("DC=brunobrito,DC=net", searchFilter, SearchScope.Subtree, "displayName", "cn", "mail" );

var response = (SearchResponse)connection.SendRequest(searchRequest);

tl;dr: I've tried in many ways to perform a Search in Linux scenarios. I just can't.

Windows Environment - Running in .NET Core 3.1 and .NET 5.0

The code runs fine. It search users in many ways. Returns all metadata.

Linux environment

The Search doesn't work. Always some kind of error.

I tried to change the search filter, parameters even the user credentials. But always get the same error: An unspecified operation error occurred.

Bug - search_ext_s wrong signature

When I changed the Timeout parameter:

searchRequest.TimeLimit = TimeSpan.FromMinutes(2);

Some crash occurs, bipassing even the trycatch. I got that the parameters timeLimit and sizeLimit of method search_ext_s at libldap was in wrong position. In fact there is a difference between Microsoft docs and libldap about timelimit. Maybe that was the reason.

Summary - Final discussion

I understand that under the hood we are at top of different drivers. While in Windows is wldap32.dll, Linux is libldap. But I think theses differences will make a huge difference for developers. They aren't used to deal with this kind of low level diffs.

Why not go in the same directions of Novell.Directory.Ldap.NETStandard? It's isn't a SO dependent. Btw I'had succes in all tests using it.

I'll create separated Issues for better discussion.

[danmoseley]

@brunohbrito this is very useful thank you for opening the issues. We will take a look and fix as needed.

[joperezr]

Thank you so much for trying out our bits and we really appreciate the feedback 😄
Few comments regarding that:

At first run I got an error: apt-get...

Yes in order to run in Linux or OSX we do require libldap to be installed, which is the case for most Linux distros out there as well as OSX. That said, I do believe that minimal OS versions like the ones used in docker might stripped these dependencies out, so it makes sense you were hitting that. I think it may be a good idea to either add a note on the package to say that we have that as a dependency or perhaps in the code we could catch the dllnotfoundexception and wrap it in a more friendly message saying you are lacking that dependency, would that sound like a good plan?

So, why we don't concat domain name in every case (when it's available) for Linux?

I'm not sure if this is possible, in Windows if you are domain-joined you can probably get away with it because Windows carries a bit extra info on the domain realm you are joined in, but for Linux this is a bit different given that Linux has a separation between local accounts and LDAP accounts. All that said I would like to understand more about your scenario, is your Linux machine domain joined? If so, have you ran a kinit in order to get a valid Kerberos ticket? That would be the equivalent of being signed in on Windows.

I've made a PR, in case you agree to theses changes.

I'll take a look at it, thanks so much for your contribution.

The Search doesn't work. Always some kind of error.

For your search issue, have you ever tried passing in null as attributeList? What may be happening here is that one of the attributes you are passing in is not present on all entities found which could lead to an error. My suggestion would be to try something like:

var searchFilter = $"(|(mail=joao.silva@brunobrito.net)(sAMAccountName={username}))";
var searchRequest = new SearchRequest("DC=brunobrito,DC=net", searchFilter, SearchScope.Subtree, null ); // Passing null as attributelist basically means return all attributes

var response = (SearchResponse)connection.SendRequest(searchRequest);

Bug - search_ext_s wrong signature

Good catch, yeah that sounds like a problem, we should probably log a separate bug for that and fix it.

I understand that under the hood we are at top of different drivers. While in Windows is wldap32.dll, Linux is libldap. But I think theses differences will make a huge difference for developers. They aren't used to deal with this kind of low level diffs.

You are correct that our managed implementations are pretty much the same between Windows and Linux, and we are basically just using different native libraries (or drivers) underneath with just a few places where we handle calls differently between Windows and Linux. That said, we only made this decision because both underlying drivers (wldap32 and libldap) are simply just the implementation of a protocol (LDAP Protocol) to the point where they even have about 95% same signatures between them and they also have the same behavior. Because of this, the only main differences are not in the calls themselves, but just in the way that OSes handle Active directory authentication and domain joined management (which are the issues you found in your first scenario). Windows does have some shortcuts available so that for example, you don't always need to pass in domain/REALM, or it is easier to find the right LDAP server without developers needing to do much configuration, but those differences are mostly just ways how OSes differ on authentication handling. If you have your code not rely on these Windows shortcuts (meaning you pass in the user@REALM as credential) then I would expect this to work both in Windows and Linux.

Again thank you so much for your feedback, it is very valuable in making sure that we have a great solution for managing LDAP on Linux/OSX 😄

[brunobritodev]

Yes in order to run in Linux or OSX we do require libldap to be installed, which is the case for most Linux distros out there as well as OSX. That said, I do believe that minimal OS versions like the ones used in docker might stripped these dependencies out, so it makes sense you were hitting that. I think it may be a good idea to either add a note on the package to say that we have that as a dependency or perhaps in the code we could catch the dllnotfoundexception and wrap it in a more friendly message saying you are lacking that dependency, would that sound like a good plan?

Yes, It sounds good to me. Maybe a message redirecting user to some docs explaining how to solve it. There is a chance to Visual Studio identify which package is referenced during Add Docker Support from Solution Explorer and auto add apt-get some required packages?

, is your Linux machine domain joined? If so, have you ran a kinit in order to get a valid Kerberos ticket? That would be the equivalent of being signed in on Windows.

No, either my Linux and Windows wasn't joined at domain. I've created a Virtual Machine at Azure and made a simple Active directory config just for theses tests.

For your search issue, have you ever tried passing in null as attributeList?
Yes, I tried to send null, also to change Scope Level, distinguishedName, even AuthType from Ntlm to Basic.

Yes. I've tried in many ways to check if something was wrong with my payload. But when I changed for Windows or performs the same search with Novell.Ldap, I got results.

That said, we only made this decision because both underlying drivers (wldap32 and libldap) are simply just the implementation of a protocol (LDAP Protocol) to the point where they even have about 95% same signatures between them and they also have the same behavior

Great! I'm very excited to use it! One of my projects rely on that!

Again thank you so much for your feedback, it is very valuable in making sure that we have a great solution for managing LDAP on Linux/OSX

A special thanks to @ralmsdeveloper who helped me in some scenarios, also to build and debug dotnet/runtime (was painful)