Runtime: Support System.DirectoryServices.Protocols on Linux/Mac

321

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 picture karelz  ·  24 Oct 2017

Most helpful comment

40

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.

pasikarkkainen picture pasikarkkainen  ·  25 Oct 2017

All comments

0

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.

karelz picture karelz  ·  24 Oct 2017
0

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.

carlowahlstedt picture carlowahlstedt  ·  25 Oct 2017
40

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.

pasikarkkainen picture pasikarkkainen  ·  25 Oct 2017
0

@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 picture euclid47  ·  11 Nov 2017
0

@karelz Any movement on the issue?

euclid47 picture euclid47  ·  17 Nov 2017
0

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

karelz picture karelz  ·  17 Nov 2017
31

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.

j3vans picture j3vans  ·  20 Nov 2017
4

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.

jchannon picture jchannon  ·  22 Nov 2017
0

@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?

carlowahlstedt picture carlowahlstedt  ·  22 Nov 2017
0

@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.

karelz picture karelz  ·  22 Nov 2017
0

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

jchannon picture jchannon  ·  22 Nov 2017
0

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.

pasikarkkainen picture pasikarkkainen  ·  22 Nov 2017
0

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
.

jchannon picture jchannon  ·  22 Nov 2017
0

@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.

karelz picture karelz  ·  22 Nov 2017
0

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.

pasikarkkainen picture pasikarkkainen  ·  3 Dec 2017
0

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

karelz picture karelz  ·  4 Dec 2017
0

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

iSazonov picture iSazonov  ·  5 Dec 2017
0

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.

mikeh688 picture mikeh688  ·  5 Dec 2017
4

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?

evil-shrike picture evil-shrike  ·  25 Jan 2018
3

No. It works. Nothing to maintain

jchannon picture jchannon  ·  15 Mar 2018
0

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

pasikarkkainen picture pasikarkkainen  ·  15 Mar 2018
0

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
.

jchannon picture jchannon  ·  15 Mar 2018
0

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

liquidboy picture liquidboy  ·  15 Mar 2018
4

I will take this on for the macOS port.

McShauno picture McShauno  ·  6 Jun 2018
1

@karelz who can mentor this on our side?

danmosemsft picture danmosemsft  ·  6 Jun 2018
0

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?

Nr18 picture Nr18  ·  13 Jun 2018
0

@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?

McShauno picture McShauno  ·  15 Jun 2018
0

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

karelz picture karelz  ·  15 Jun 2018
1

\the license.\ :smile:

bartonjs picture bartonjs  ·  15 Jun 2018
5

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)

dogguts picture dogguts  ·  2 Jul 2018
4

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.

McShauno picture McShauno  ·  25 Jul 2018
1

@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.

bartonjs picture bartonjs  ·  25 Jul 2018
0

@bartonjs ok, great. I am on it.

McShauno picture McShauno  ·  3 Aug 2018
1

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:

danmosemsft picture danmosemsft  ·  3 Aug 2018
3

@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.

zivillian picture zivillian  ·  1 Oct 2018
0

@McShauno Any news?

pasikarkkainen picture pasikarkkainen  ·  27 Nov 2018
3

@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.

McShauno picture McShauno  ·  27 Nov 2018
3

@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.

zivillian picture zivillian  ·  27 Nov 2018
0

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

pasikarkkainen picture pasikarkkainen  ·  21 Jan 2019
0

@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?

pasikarkkainen picture pasikarkkainen  ·  13 Feb 2019
0

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

karelz picture karelz  ·  14 Feb 2019
0

@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?

pasikarkkainen picture pasikarkkainen  ·  2 Mar 2019
0

@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.

dogguts picture dogguts  ·  21 Mar 2019
2

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

itsvinayjha picture itsvinayjha  ·  8 Apr 2019
2

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.

schmitch picture schmitch  ·  8 May 2019
0

Upvoting this feature request

ygini picture ygini  ·  31 May 2019
0

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?

joeandaverde picture joeandaverde  ·  28 Jun 2019
0

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

iSazonov picture iSazonov  ·  29 Jun 2019
0

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.

ebekker picture ebekker  ·  1 Jul 2019
0

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?

GRdevOps picture GRdevOps  ·  3 Jul 2019
0

As a side note, VQ's library was updated in the last couple of days with
minor updates

On Wed, 3 Jul 2019 at 13:37, GRdevOps notifications@github.com wrote:

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?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/24843?email_source=notifications&email_token=AAAZVJULW4MMKONNP66SWKDP5SMQ5A5CNFSM4EAT3LR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZEJUOI#issuecomment-508074553,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAZVJV5KA3QITIBWIHMAADP5SMQ5ANCNFSM4EAT3LRQ
.

jchannon picture jchannon  ·  3 Jul 2019
3

I really appreciate the work you guys are doing and will look into the various community libraries (after some coffee). I am just really disappointed that Microsoft would advertise .Net Core 2.0 as this very mature reliable cross platform solution, and then as a cliff note exclude something as fundamental as an LDAP library.

GRdevOps picture GRdevOps  ·  3 Jul 2019
0

@jchannon would it be possible to publish your library so I can pull it in with NuGet?

GRdevOps picture GRdevOps  ·  8 Jul 2019
2

I don't see why not, will speak to @mikeh688 about it

jchannon picture jchannon  ·  8 Jul 2019
0

That would be awesome and greatly appreciated

GRdevOps picture GRdevOps  ·  8 Jul 2019
0

sure. we've just found and fixed an issue with extended characters we introduced during a brief flirtation with mono.

mikeh688 picture mikeh688  ·  8 Jul 2019
4

We've published our version now updated to netstandard2 https://www.nuget.org/packages/Novell.Directory.LDAP.VQ/

jchannon picture jchannon  ·  15 Jul 2019
0

Pulled the library and was able to connect to my lab server and pull a search result. Code is very intuitive and the examples are very helpful, thank you guys!

I posted the code I'm using below (I am fully qualifying namespaces since I have multiple LDAP libraries currently)

Novell.Directory.LDAP.VQ.LdapConnection con = new Novell.Directory.LDAP.VQ.LdapConnection();

            con.SecureSocketLayer = true;

            con.UserDefinedServerCertValidationDelegate += (certificate, certificateErrors) => true;

            con.Connect("host", 636);

            con.Bind(bindUser.UserName, bindUser.Password);

            Novell.Directory.LDAP.VQ.LdapSearchResults lsc =
                con.Search(
                    searchBaseDN,
                    Novell.Directory.LDAP.VQ.LdapConnection.SCOPE_SUB,
                    searchFilter,
                    attributesReturned,
                    false
                    );

            while (lsc.Count > 0)
            {
                Novell.Directory.LDAP.VQ.LdapEntry nextEntry = lsc.next();
                // TODO: Add function to map user and add to search results
            }
GRdevOps picture GRdevOps  ·  15 Jul 2019
0

Glad it worked for you!

jchannon picture jchannon  ·  15 Jul 2019
0

Hi,

I've a rather strange scenario. I've been able to use Novell library from AWS - Fargate (ECS) using Net Core 2.1. My LDAP server is also on AWS within the same region.

But the ldap connection session setup - takes exactly 100 seconds every single time.

code snippet -
_connection = new LdapConnection() {SecureSocketLayer = true };
_connection.UserDefinedServerCertValidationDelegate += (certificate, error) => true;
_connection.Connect(_config.Url, 636);

But if i disable ssl and connect to port 389, then ldap connection is established within a second.

Above code (SSL - 636) also works seamlessly on an EC2 instance both (linux/ windows), but strangely it takes 100 secs while within AWS ECS.

I know I'm leaning towards AWS, but still want to confirm if there's anything in Novell that would cause such observation?

wrohit100 picture wrohit100  ·  19 Jul 2019
0

It might be timeout while trying to fetch certificate revocation lists, or such...

markusschaber picture markusschaber  ·  19 Jul 2019
0

That's the thing. It doesn't time out.

After 100 seconds, the connection is actually successfully setup, and I can bind, query, authenticate , do the usual stuff.

wrohit100 picture wrohit100  ·  19 Jul 2019
1

It might be a timeout for some non-critical background operation - like reverse DNS resolution (resolve IP to host name) for server access logs - if it fails, the IP instead of the host name is logged. Most probably on the server side.
Or the timeout for an IPv4/IPv6 fallback to the other protocol, if the network host name resolves both kinds of addresses, but the host is not reachable using V6, and some infrastructure just drops V6 packets (like some firewalls do), instead of rejecting them.

markusschaber picture markusschaber  ·  22 Jul 2019
0

So.. System.DirectoryServices.Protocols still isn't available on Linux/macOS. Does someone have time to continue the work @dogguts started in https://github.com/dotnet/corefx/issues/24843#issuecomment-475187057 ?

@karelz Is there any chance for someone from corefx team to work on this?

Thanks!

pasikarkkainen picture pasikarkkainen  ·  29 Sep 2019
0

I saw an announce that now Core team has a networking team. I hope we will see a progress in the area.

iSazonov picture iSazonov  ·  29 Sep 2019
2

@iSazonov CoreFX has Networking team for years. It never included DirectoryServices though, that is separate area with different and unique challenges.

@pasikarkkainen ... Is there any chance for someone from corefx team to work on this?

There is always chance and hope. Sadly, we do not have any ETA or commitment yet. It is lots of work and requires new expertise we do not passes at this moment. It is something we are considering though. (I know, not the answer you wanted to hear, but at least it reflects reality)

karelz picture karelz  ·  30 Sep 2019
0

@karelz Thanks! (The difficulty for single developer (like me) is that developing a network code requires a complex environment - several dev systems with different operating systems (Windows, MacOS, Linux) on the same network. Perhaps Core team would come up with some kind of sandbox (based on WSL2?) to make it easier.)

iSazonov picture iSazonov  ·  30 Sep 2019
11

Perhaps Core team would come up with some kind of sandbox (based on WSL2?) to make it easier.)

The .NET Core networking team (mostly me right now) is working on a plan to support an enterprise testing environment which would include things like Windows Active Directory, Linux Kerberos and multiple clients etc. I already have set up a prototype environment that consists of 5 or so VMs (Windows and Linux) that I have used to validate fixes in .NET Core 3.0 for HTTP, NegotiateStream scenarios that use Negotiate (SPNEGO protocol), Kerberos and NTLM. I've been thinking about ways that this could be enhanced to support general LDAP things that would be useful for DirectoryServices.

davidsh picture davidsh  ·  30 Sep 2019
0

I'm very interested on this topic, I'm looking into it right now, but kinda have no idea on this subject, can you help me find out the parts which doesn't work on linux/mac?

cyberhck picture cyberhck  ·  22 Oct 2019
0

we use it extensively on Linux with hundreds of deployments and it works a treat.

mikeh688 picture mikeh688  ·  22 Oct 2019
0

@mikeh688 how? I'm using on linux it simply says platform not supported? Are you sure you're using DirectoryServices?

cyberhck picture cyberhck  ·  24 Oct 2019
0

sorry, i might have misunderstood your question and was referring to our use of the Novell library (https://github.com/VQComms/CsharpLDAP/tree/coreclrPort).

mikeh688 picture mikeh688  ·  24 Oct 2019
0

I was talking about System.DirectoryServices which is the topic for this issue :)

cyberhck picture cyberhck  ·  24 Oct 2019
0

I believe DirectoryServices makes calls out to specific win dll's that do not exist on linux or .Net Core. Been awhile, but off the top of my head I believe when they made .Net Core and wanted to add LDAP functionality they simply wrapped the .Net Core functionality around the old calls, or something like that....

GRdevOps picture GRdevOps  ·  28 Oct 2019
0

@GRdevOps See https://github.com/dotnet/corefx/issues/24843#issuecomment-475187057 . @dogguts did the initial port of System.DirectoryServices.Protocols to Linux, wrapping openldap library on Linux. ie. similar wrapper implementation as it is on Windows currently. Someone needs to finish the initial port..

pasikarkkainen picture pasikarkkainen  ·  28 Oct 2019
0

I'm using Novell library, it works both on Linux and window.
But without SSL it could not create/update the entry with unicodePwd field.
So I'm looking for the support of System.DirectoryServices. library on .net core. Do we have plan for this supporting ?

phihnp picture phihnp  ·  30 Oct 2019
0

Why not enable SSL/TLS? I've used the Novell Library successfully to do account (user and machine) creates and password changes. Those require a secure connection, so you just need to enable LDAPS support on your AD controllers (or at least one of them).

ebekker picture ebekker  ·  30 Oct 2019
0

I use the Novell Library for a .Net Core application that is running on
Linux and all traffic is over 636.

On Wed, Oct 30, 2019 at 12:22 PM Eugene Bekker notifications@github.com
wrote:

Why not enable SSL/TLS? I've used the Novell Library successfully to do
account (user and machine) creates and password changes. Those require a
secure connection, so you just need to enable LDAPS support on your AD
controllers (or at least one of them).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/24843?email_source=notifications&email_token=AFCJJTUE32ZU77BQGDLCCQTQRGYFDA5CNFSM4EAT3LR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECU2ESY#issuecomment-547988043,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFCJJTQAAFCMAENBIYR5AZLQRGYFDANCNFSM4EAT3LRQ
.

--
Keith LeValley
Identity Services Architect, Davenport University
phone: (616) 732-1102
[email protected]

GRdevOps picture GRdevOps  ·  30 Oct 2019
0

Likewise, most of my usage is from an AWS Lambda function (.NET Core apps on Amazon Linux AMI) and it interacts with both AWS managed MSAD controllers, as well as our own self-hosted controllers.

ebekker picture ebekker  ·  30 Oct 2019
2

I do wonder how does this story develop towards .NET 5, which supposedly should finally merge the gap between .NET Framework and .NET Core?

I do not think the Novell library supports the DirSync Control feature, which is something I need. There actually appears to be very few LDAP libs that do support it, regardless of platform.

lehtoj picture lehtoj  ·  21 Nov 2019
8

I wrote cross platform library ldap4net. Unlike Novell the library uses same way as DirectoryServices and supports integrated passwordless authentication.
Also expected support of ldap v3 controls.

flamencist picture flamencist  ·  12 Mar 2020
0

@flamencist cool! Are you planning to try to get ldap4net merged to dotnet core?

pasikarkkainen picture pasikarkkainen  ·  12 Mar 2020
0

@flamencist cool! Are you planning to try to get ldap4net merged to dotnet core?

Probably but now I am focusing on implementation compatibility with ldap v3 features.

flamencist picture flamencist  ·  13 Mar 2020
0

With .NET Framework and .NET Core merging in .NET 5 (now in Preview 1), it sounds like we'll get proper cross-platform support (i.e., at the level currently available in .NET Framework) 🤞

JasonPierce picture JasonPierce  ·  18 Mar 2020
2

uhhhh, "merging"? That's not what's happening.

yaakov-h picture yaakov-h  ·  19 Mar 2020
0

@yaakov-h at the risk of hijacking this thread, would you care to expound upon your comment?

JasonPierce picture JasonPierce  ·  19 Mar 2020
2

.NET 5 is basically just .NET Core 4.0 but since .NET Framework is already at version 4 and .NET Core is replacing (not merging with) .NET Framework with it's next release .NET Core 4 will be called .NET 5 instead (just imagine the confusion with .NET Framework 4.x and .NET 4.x). I simplified it a bit but that's the broad strokes from my understanding.

Totally unrelated but the number 4 is also considered bad luck in some Asian countries so for example the Garmin Fenix line-up went directly from Garmin Fenix 3 to Garmin Fenix 5. So hopefully .NET Core will have no bad luck with it's next release since they too are ditching the release number 4 :)

OskarKlintrot picture OskarKlintrot  ·  19 Mar 2020
1

What @OskarKlintrot says above is correct (well at least the first para..can't say about lucky numbers..)

danmosemsft picture danmosemsft  ·  19 Mar 2020
15

Just as FYI for all people interested in this, I've put up a PR https://github.com/dotnet/runtime/pull/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 picture joperezr  ·  28 Apr 2020
7

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
  • [x] 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: https://github.com/dotnet/runtime/pull/36405)

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

joperezr picture joperezr  ·  7 May 2020
0

Will it be in 5.0 Preview4?

iSazonov picture iSazonov  ·  8 May 2020
0

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

MarkusAmshove picture MarkusAmshove  ·  8 May 2020
0

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

No. Its another big task.

flamencist picture flamencist  ·  8 May 2020
2

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.

joperezr picture joperezr  ·  8 May 2020
0

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).

iSazonov picture iSazonov  ·  8 May 2020
0

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?

FWest98 picture FWest98  ·  26 May 2020
0

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?

joperezr picture joperezr  ·  26 May 2020
0

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.

iSazonov picture iSazonov  ·  27 May 2020
0

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.

FWest98 picture FWest98  ·  27 May 2020
0

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.

joperezr picture joperezr  ·  27 May 2020
0

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 :)

MarkusAmshove picture MarkusAmshove  ·  27 May 2020
0

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

joperezr picture joperezr  ·  27 May 2020
3

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: https://github.com/dotnet/runtime/issues/37100

FWest98 picture FWest98  ·  28 May 2020
0

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 picture rafis  ·  19 Jun 2020
0

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?

rafis picture rafis  ·  19 Jun 2020
1

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.

joperezr picture joperezr  ·  22 Jun 2020