Support System.DirectoryServices.Protocols on Linux/Mac

[karelz]

Port System.DirectoryServices.Protocols to Linux & Mac -- we need to decide on x-plat LDAP library to use first

Note: Offshoot from larger topic dotnet/runtime#14734

[karelz]

Currently we do not have immediate plans to implement the library on Linux/Mac. You can use top post upvoting to add your vote.

The issue is marked as up-for-grabs for anyone who knows the space and wants to pick it up.

[carlowahlstedt]

While I don’t know the space, I’d love to work on the Mac portion. If an x-plat library is decided then at some point after that’s I can start hacking on it.

[pasikarkkainen]

It's a bit surprising that .NET Core doesn't have an integrated/official LDAP library available out of the box.. shouldn't there be one? It could be then used for System.DirectoryServices.Protocols aswell.

[euclid47]

@pasikarkkainen the closest thing to support is Novell.directory.ldap.netstandard on github. It took a while to get it working. It is adequate for basic use but it is not as comprehensive as the classic dot net implementation. The hardest part is working with userAccountControlattribute and creating objects. I had to create UAC enum flags which was something I had not done before. Be careful about creating users, groups, OUs and the like because you have to explicitly create all required attributes which is a game of trial and error. I have this working against Active Directory but have not tried it against OpenLdap or the like.

[euclid47]

@karelz Any movement on the issue?

[karelz]

@euclid47 no update. If/when we decide to invest, we will update this issue.

[j3vans]

While the work Microsoft and community have done with asp.net core is amazing, it is disappointing that it is being sold as cross platform and mature at 2.0 yet lacks a robust cross platform ldap library. All the other languages/frameworks we use have this, and ldap servers are still ubiquitous in heterogeneous enterprise networks (in my humble experience). This is the one thing preventing us from adopting asp.net core as our go to cross platform framework, since we need to be able to deploy on Linux web servers. Hope that this becomes a priority soon because we'd love to work with asp.net core more.

[jchannon]

In terms of LDAP we are using this successfully on Linux. (https://github.com/VQComms/CsharpLDAP/tree/coreclrPort) This is used for searching and authenticating LDAP users. It's not on nuget but on an internal nuget repo but if people want to help out on the project we could look to move it to Nuget for public consumption. We have been using this for over a year.

[carlowahlstedt]

@karelz sounds like what @jchannon has is a solid beginning to solve this issue. Is there an outline of what it would take to get this going? You mentioned deciding on an x-plat library, could the decision be to use this port? If not, what’s missing from there to make it “official” enough to use?

[karelz]

@carlowahlstedt taking in existing project means we have to involve lawyers, check license, etc.

The decision about x-plat library needs someone to recommend a solution - ideally with some comparison of alternative options, how popular the library is, etc. And ideally with a prototype / proof of concept. It can be done as well by community members. Internally we do not have deep knowledge of LDAP libraries on Linux/Mac.

[jchannon]

Our lib takes the old Novell LDAP code so its pretty solid

[pasikarkkainen]

The other option as LDAP library is: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard Are there other options out there?

But really .NET Core should have an official LDAP library built-in, which is opensource, and thus could be used on all the supported platforms.

[jchannon]

That uses the same Novell code underneath too

On 22 November 2017 at 17:12, pasikarkkainen notifications@github.com wrote:

The other option as LDAP library is: https://github.com/dsbenghe/ Novell.Directory.Ldap.NETStandard Are there other options out there?

But really .NET Core should have an official LDAP library built-in, which is opensource, and thus could be used on all the supported platforms.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/corefx/issues/24843#issuecomment-346415702, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGapi_B07pT0K4fP80-serYKlTtj3Ksks5s5FYSgaJpZM4QE9rj .

[karelz]

@jchannon I am not familiar with Novell LDAP. Is that the only option out there? Is that the best option? Why? What about perf? (you commented on reliability) What about availability on various Linux distros and on Mac? Is it actively maintained?

Those are the questions I would go after if I was trying to give a recommendation.

[pasikarkkainen]

I don't think those ports of the Novell LDAP c# .NET library are included in the Linux distros or macOS.

So the library would have to be added/included to .NET Core, so that it can be then utilized for Linux/macOS port of System.DirectoryServices.Protocols. Is that possible?

To answer the "Is that the only option out there? Is that the best option? Why?" -part.. the better alternative would be if there was a LDAP library included as a default in .NET Core. I find it very weird .NET Core doesn't already have a LDAP library out-of-the-box.

[karelz]

@pasikarkkainen we could make it external pre-req the same way we depend on OpenSsl and libcurl today.

[iSazonov]

In PowerShell repo we see that the method (make it external pre-req the same way we depend on OpenSsl and libcurl today) is very sensitive. https://github.com/PowerShell/PowerShell/issues/5590 https://github.com/PowerShell/PowerShell/pull/5624

[mikeh688]

following up on what @jchannon has said, our port at https://github.com/VQComms/CsharpLDAP/tree/coreclrPort is based on the Novell original. We ported it to .Net Core and the .Net Core version has been in use for approx 18 months on over 100 systems. It works well against MS AD, OpenLDAP and even Oracle (on Windows, Mac and Linux). We have expertise within the team and actively maintain it.

[evil-shrike]

We ported it to .Net Core and the .Net Core version has been in use for approx 18 months on over 100 systems. It works well against MS AD, OpenLDAP and even Oracle (on Windows, Mac and Linux). We have expertise within the team and actively maintain it.

@mikeh688 you said that you actively maintain it but "Latest commit b4c309f on Jan 10, 2017". Is it something I missed?

[jchannon]

No. It works. Nothing to maintain

[pasikarkkainen]

So did anyone try porting System.DirectoryServices.Protocols to work using ldap library from https://github.com/VQComms/CsharpLDAP/tree/coreclrPort ?

[jchannon]

We haven't as we didn't need it however open to pull requests. We can then publish to nuget. Currently packaged in an internal nuget feed.

On Thu, 15 Mar 2018 at 20:09, pasikarkkainen notifications@github.com wrote:

So did anyone try porting System.DirectoryServices.Protocols to work using ldap library from https://github.com/VQComms/CsharpLDAP/tree/coreclrPort ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/corefx/issues/24843#issuecomment-373506635, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGapjeTmBPatAUgpIbqDwO85T1Hv1Ksks5tespqgaJpZM4QE9rj .

[liquidboy]

we, like @jchannon , have successfully forked novell's LDAP library and are using it in an ASP.NETCore "Standard" application .. https://github.com/Aconex/Novell.Directory.Ldap.NETStandard/commits/master

The LDAP server we are using is OpenDJ https://en.wikipedia.org/wiki/OpenDJ

We have 3 servers running OpenDJ replicated …

Been working great for over 2 yrs

[McShauno]

I will take this on for the macOS port.

[danmoseley]

@karelz who can mentor this on our side?

[Nr18]

So i ran into this issue while doing my first dotnet AWS Lambda function, is this issue the same reason why it will not to run on AWS Lambda?

Like i said i never done dotnet before but i did find this: https://github.com/dotnet/corefx/blob/16b7210b25ac666ebffc8180f0f0c5b03b8b3eb6/src/System.DirectoryServices/src/Configurations.props#L6

Guessing the Windows_NT part is responsible for the System.DirectoryServices is not supported on this platform.: PlatformNotSupportedException message?

[McShauno]

@karelz @danmosemsft

I have found no decent x-plat library for ldap in the .NET universe so I have been writing my own using RFC4511.

I am wondering if it is appropriate for me to make use of the AsnReader and AsnWriter located within the System.Security.Cryptography namespace even though they are currently marked as internal?

[karelz]

Yes, I expect that using the internal classes is fine - cc @bartonjs who will productize them to public APIs eventually.

[bartonjs]

\<NotALawyerBut>Subject to the rules of the license.\</NotALawyerBut> :smile:

[dogguts]

Porting (at least the basics for) System.DirectoryServices.Protocols to linux (and AFAICT mac as well) is not as complicated as is might seem. "wldap32.dll" (used by S.DS.P) on Windows follows the (draft) specification of the "c-ldap-api" (https://tools.ietf.org/html/draft-ietf-ldapext-ldap-c-api-05). But so does the "libldap.so" on Linux (and Mac). Basicly porting to linux (and mac?) (only) requires:

• interop calls like Wldap32UnsafeMethods for openldap (again these are almost 100% the same as on windows, safe for CharSet.Unicode)
• adjustments for text-encoding (Marshal.) in LdapConnection for UTF16 vs. UTF8; PtrToStringUni (win) vs. PtrToStringUTF8 (lnx & mac(?)) and StringToHGlobalUni vs StringToHGlobalUTF8 (https://gist.github.com/dogguts/66cd6b119a4d0a444cd34997fe4ce2d6)

I lifted S.DS.P (& UT's & UT-code-depencies) out of corefx (since not familiar with development/build on the complete corefx repo) and did a POC-(stand-alone-console-project-)port; https://github.com/dogguts/System.DirectoryServices.Protocol_linux Some edge-case unit tests fail (segfault) since openLdap-liblber is a bit more picky about some input than wldap32 is, but that doesn't seem to problematic for any 'real world use' (for now I only tested basic search functionality)

[McShauno]

The port I am currently working on attempts to move totally away from dependencies on LDAP OS libraries and uses the OpenLDAP protocol specifications (https://tools.ietf.org/html/rfc4511). To me, this is the purest way to get to a true x-plat library.

Any guidance from @karelz or @danmosemsft is appreciated.

[bartonjs]

@McShauno Our normal approach is that if we already have an implementation on Windows that calls into Win32 API, we leave that alone. Then on non-Windows systems something else can be used.

If the non-Windows implementation is purely managed code then after a release or two we might delete the Windows-specific version, if there's no loss of functionality, and use the AnyOS binary everywhere.

[McShauno]

@bartonjs ok, great. I am on it.

[danmoseley]

Right, I can't look at this in detail right now but I agree with @bartonjs I would leave the windows implementation basically as is for now and graduate your new implementation to replace it later. The reason being we know the windows one is stable and we don't have much in house expertise to chase newly created bugs in it. :smile:

[zivillian]

@McShauno I wasn't able to find your WIP - maybe we should join our effort to prevent duplicates.

I also started to work on a managed LDAP implementation based on System.IO.Pipelines and the new ASN.1 reader/writer API at zivillian/ldap.net.

The client API is heavily inspired by the c-ldap-api but tries to use all available features of .NET. Currently my goal is to implement a basic LDAP server, so the client and proxy were more or less implemented by accident.

It's far from complete, but before anyone else is starting another library, I just wanted to reference what I got so far.

If anyone is interested in contributing, I'm open to any help.

[pasikarkkainen]

@McShauno Any news?

[McShauno]

@zivillian @pasikarkkainen Sorry for my lack of response lately. My 9-5 has kept me really busy the past couple of months so I am obviously behind schedule on this. I believe in another 3-4 weeks I will have something everyone can start contributing to if that works.

@zivillian Perhaps combining efforts is a good idea at this point; however, I think we went 2 different directions. I was attempting to move away from anything OS dependent like the various C libraries and so I was in the process of just creating an x-plat lib from scratch. I'll checkin what I have and come back for more discussion.

[zivillian]

@McShauno That's exactly what I've done - c#/.net only LDAP implementation based on RFC4511. The client API was inspired by the c-ldap-api recommendation.

[pasikarkkainen]

@McShauno Yep. Hopefully you can share your work soon!

[pasikarkkainen]

@karelz Clearly dotnet needs to have an opensource ldap (client) library, which then could be used to implement system.directoryservices.protocols aswell.. should we create a separate github issue about getting ldap library integrated/merged?

[karelz]

@pasikarkkainen do you mean a brand-new from-scratch LDAP library? Why cannot we depend on external existing library like we do on OpenSSL?

[pasikarkkainen]

@karelz yeah, well, wrapping libldap.so is an option aswell. Pretty much what @dogguts did.

@dogguts how has your POC been working? What's currently missing?

[dogguts]

@karelz I ported a big chunk of it (still mainly as a POC) to the point it suited my needs/usecase; the ability to develop (and use a directory server) on linux/vscode (at home) and on windows/vs (at work). I'm not using the port on any production environments since they all get hosted on windows. What is ported seems to work fine (tested with RH-389DS and Active Directory). Though a lot is missing as well (see github README.md).
Wldap32 and libldap (on linux) both seem to be based on the ldap c api (rfc/draft), but were probably based on a different version of the draft rfc (and both have extended it somewhat). So porting it isn't (always) as straight forward as it may seem, at least while keeping as much shared code between windows and linux as possible. Subsequently I have no idea what macos defaults to for ldap functionality. A lot of the original unit tests fail as well since wldap32 allows a much more liberal BER encoding/decoding, but those that fail (especially those related to BER aren't all to serious)

I've got the code on github and a nuget package (built on azure devops). Unfortunately I won't have the opportunity in foreseeable future (coming months) to work on it since I'm caught up in a few, rather big, projects at work ATM.

[itsvinayjha]

@McShauno : any expected version or date for System.DirectoryServices.Protocols in which we can have support for Linux?

[schmitch]

I would've prefered this over https://github.com/aspnet/AspNetCore/issues/4662#issuecomment-490648845 I guess it's more important to have an ldap library to build a kind of "repository" that save's users and caches passwords from ldap instead of external managed users.

[ygini]

Upvoting this feature request

[dynajoe]

Upvote. What's the best work-around for this? There's a Novell and a VQComms library mentioned in this thread. Anyone had luck with either?

[iSazonov]

It is huge work. Perhaps dotnet network team could start in corefxlab and then get community support.

[ebekker]

I've been able to use Novell library successfully from Linux boxes using ASP.NET Core 2.1 (from AWS Lambda actually), but my use case might be limited. I'm able to create user and machine accounts, manage groups and groups memberships, and manage credentials.

[GRdevOps]

Upvote

Two weeks ago I started a new ASP .Net Core project that interacts with our Linux LDAP servers to make it easier to manage interconnected services. After two weeks of developing and testing on my local machine (windows), I ported the code over to our Apache web server and it died...

I am pretty shocked this morning and makes me question using .Net Core for future projects. Obviously I could and should have taken steps earlier on to ensure that I wasn't wasting my time, but this is still pretty rough and now I am stuck as I have already committed to finishing this project.

So now I can hope for a community solution? I can use an alternative library which would require significant code re-write and likely a loss of functionality? Or do I just re-write the project in a language native to Linux?