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 #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 ***@***.***> 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.
PowerShell/PowerShell#5590
PowerShell/PowerShell#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 ***@***.***> 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> 😄

[joperezr]

Just as FYI for all people interested in this, I've put up a PR #35380 that is adding Linux support for S.DS.P. It is currently under review and only adding support for Linux, but once that is in I will take a look at what it would take to also add support for Mac.

[joperezr]

Most of the support for Linux has been merged now. I'm reopening the issue to track two more things I want to finish before we call this issue done:

• Add OSX support
• Add Default credentials support (meaning you can create an LdapConnection object without requiring credentials when you have ran a successful kinit command on the server/machine)(PR for this support is out: Adding the support of reusing machine-wide credentials in the case where the machine is already domain-joined to the LDAP Server. #36405)

I'm planning on addressing both of them in subsequent PRs

[iSazonov]

Will it be in 5.0 Preview4?

[MarkusAmshove]

Does this issue also include the namespace System.DirectoryServices.AccountManagement? I'm having trouble finding informations about it :-)

[flamencist]

Does this issue also include the namespace System.DirectoryServices.AccountManagement? I'm having trouble finding informations about it :-)

No. Its another big task.

[joperezr]

Will it be in 5.0 Preview4?

No, preview 4 has already been forked so this would go into preview 5. Alternatively you can add our nightly feed to your project and could take a dependency on the nightly builds which will soon have this change (nightly builds have been broken for a little while but I believe our team is close on fixing that.)

Does this issue also include the namespace System.DirectoryServices.AccountManagement? I'm having trouble finding informations about it :-)

As @flamencist points out, this only includes System.DirectoryServices.Protocols library. We decided to support this one on Linux/Mac as opposed to the other DirectoryServices ones as the API for this one was strictly down to the protocol. The other DirectoryServices namespaces have some of Windows-specific types and COM types leaked into the surface area, so it would be hard to support that API on Linux/MAC.

[iSazonov]

The other DirectoryServices namespaces have some of Windows-specific types and COM types leaked into the surface area, so it would be hard to support that API on Linux/MAC.

It seems AccountManagement is implemented based on "providers" and I hope it is possible to add Linux PAM too. It is very desirable for PowerShell (I already ported LocalAccounts module to AccountManagement API).

[FWest98]

Does this issue also include the namespace System.DirectoryServices.AccountManagement? I'm having trouble finding informations about it :-)

As @flamencist points out, this only includes System.DirectoryServices.Protocols library. We decided to support this one on Linux/Mac as opposed to the other DirectoryServices ones as the API for this one was strictly down to the protocol. The other DirectoryServices namespaces have some of Windows-specific types and COM types leaked into the surface area, so it would be hard to support that API on Linux/MAC.

So do I understand correctly that namespaces like S.DS.AM will not be supported for .NET 5 on Linux? Do you think it could be a potential future addition, or do you rule it out completely at this point?

[joperezr]

It is not in the plans to support S.DS.AM for .NET 5 in Linux as our solution for communicating and controlling LDAP servers in Linux is via System.DirectoryServices.Protocols for now. Is there a specific scenario you have in mind that you can do with AccountManagement but not with Protocols?

[iSazonov]

Is there a specific scenario you have in mind that you can do with AccountManagement but not with Protocols?

Currently Windows PowerShell has LocalAccounts module based on non-public Windows API. I port the module on AccountManagement API with expectation the API will be ported on Unix with (perhaps) PAM support. If we get this, PowerShell 7 users get possibilities to manage local and domain/ldap accounts from any platform.

[FWest98]

I'm working on an application that does a lot of user and group management through S.DS.AM, which I am planning on running in Kubernetes. Currently, it works with Windows hosts and pods within Kubernetes, but that is tricky to manage and some of our toolkit does not work with Windows in K8s (for example, secret injection from HashiCorp Vault). Add to that the extra licensing costs and computing resources...

Reworking the application to S.DS.P is probably possible, but very inconvenient and would require significant work, as well as being more cumbersome to work with native LDAP objects instead of full-featured Principal objects from AM.

[joperezr]

I see. It does sound that S.DS.P supports pretty much all you want to do but I understand the pain that porting from one library to another would mean to apps that already work on Windows. The reasons why we decided to focus first on S.DS.P were because a) S.DS.P supports pretty much all operations you would want to do against an LDAP server, b) supports any type of LDAP server (as opposed to AccountManagement which is focused on ActiveDirectory mostly) and c) S.DS.P API is really mostly platform-agnostic as it is just the implementation of the LDAP protocol, whereas other namespaces like Account management and S.DS expose some WinRT object APIs and other things that are very Windows-specific.

My suggestion for your scenario would be to log a new issue for adding Linux support for S.DS.AccountManagement along with your scenarios, so that we have the one place tracking the need and upvotes for that feature to be added, so we can make a decision of how to go forward, similar to what happened in this issue.

[MarkusAmshove]

We use AccountManagement to read all users from specific groups in Active Directory (in netfx console apps), so no „management“ per se :) is there a replacement for those use cases on either Core or .NET5? Just from searching it, it also seems like an unresolved issue for ASP Core identities, aside from Azure AD somehow :)

[joperezr]

is there a replacement for those use cases on either Core or .NET5?

Yup with System.DirectoryServices.Protocols you can do that as well. The way to do it would be to create a LdapConnection object, and use it to send a SearchRequest where you can filter out for objects of type user which have the group id on their memberOf property. Granted doing this is a bit more complicated than using AccountManagement, given that with S.DS.P you are working with the Protocol itself, but it is possible and will be there for .NET5

[FWest98]

My suggestion for your scenario would be to log a new issue for adding Linux support for S.DS.AccountManagement along with your scenarios, so that we have the one place tracking the need and upvotes for that feature to be added, so we can make a decision of how to go forward, similar to what happened in this issue.

I added a tracking issue for this: #37100

[rafis]

Do I undestand properly that implementing cross-platform System.DirectoryServices.AccountManagement is more difficult than System.DirectoryServices.Protocols and you will firstly implement System.DirectoryServices.Protocols and after maybe 2-3 years System.DirectoryServices.AccountManagement?

[rafis]

And if you don't want to wait 2-3 years you can refactor project to use some cross-platform library like https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard?

[joperezr]

Do I undestand properly that implementing cross-platform System.DirectoryServices.AccountManagement is more difficult than System.DirectoryServices.Protocols and you will firstly implement System.DirectoryServices.Protocols and after maybe 2-3 years System.DirectoryServices.AccountManagement?

Not really. The reason why we decided to go with Protocols for cross-plat support was because a) the API was meant to support any LDAP server as opposed to AccountManagement which was more ActiveDirectory only, and b) the API in Protocols would give you most of the functionality without really exposing much of things that are Windows-only. If people want AccountManagement to get ported to Unix as well, then I would suggest to comment on the issue #37100 that was created in order to start the discussion.