Support for System.DirectoryServices for Windows

[syeshchenko]

Execution plan:

• 1. @ianhays to kick start the project in CoreFX repo - add source code, showing examples how to do it, advise with setting up build, packaging, prepare the project for future Linux/Mac ports, etc.).
• 2. Make the code build on Windows.
  • CC @tquerec @ianhays @karelz on PRs
  • Note: We will not take any functional changes to the implementation, architecture, or API surface at this point unless they are necessary to make the code compile on .NET Core. Please give heads up on this issue as soon as you discover case like that.
  • 2.1. System.DirectoryServices.Protocol (on top of wldpap32.dll)
  • 2.2. System.DirectoryServices (on top of adsi.dll)
  • 2.3. System.DirectoryServices.AccountManagement (on top of System.DirectoryServices and SystemDirectoryServices.Protocols)
  • 2.4. System.DirectoryServices.ActiveDirectory (on top of Win32 APIs - see https://github.com/dotnet/corefx/issues/2089#issuecomment-261063131)
• 3. Add tests - progress tracked in dotnet/corefx#20669
• .4. Linux/Mac ports.
  • 4.1. System.DirectoryServices.Protocol (we need to decide on x-plat LDAP library to use first) - tracked in dotnet/corefx#24843
  • 4.2. Other libraries (will be difficult as most implementation is mostly part of Windows) - to be tracked by separate issue(s) when the need arises
• .5. Further improvements and bug fixes to DirectoryServices - to be tracked by separate issues (feel free to create them)
  • Potentially parallel with [4]
• 6. Publish DirectoryServices package
  • 6.1. Publish preview DirectoryServices package - tracked in dotnet/corefx#18090
  • 6.2. Publish final DirectoryServices package - tracked as part of dotnet/corefx#24909

If anyone is working on any step, please mention it & coordinate here to avoid duplicated effort. @karelz will co-assign the issue to you as well.

---

Original proposal

Hello there, I was wondering if there is a chance to add support for System.DirectoryServices in CoreCLR.

In one of our projects we are trying to implement GAL based authentication on Linux and tried to use Mono for this task, however it only works partially, check for IsUserInGroup fails. This is something similar to what we are trying to get working: http://stackoverflow.com/questions/2188954/see-if-user-is-part-of-active-directory-group-in-c-sharp-asp-net

So I was hoping that with the addition of this namespace to CoreCLR, it might solve our problem!

Thank you

[danroth27]

@vibronet

[NickCraver]

Is there any update on this?

[Eaglef90]

I too would like an update on this. My company is having me build a new app that requires the ability to query Active Directory via LDAP but it appears this is currently not possible. Is there planed support for it, is it being dropped in favor of something else, or is it already working just not documented anywhere?

[jozefizso]

A new, fresh look at implementing the LDAP and Active Directory support would be great to have in .NET CoreFX.

[coe-jeubanks]

We really need an Active Directory/LDAP solution we can leverage in .NET Core. Whether it's a clean sheet implementation or a port of System.DirectoryServices doesn't matter as much to me. There are a lot of business-focused Windows applications that absolutely need AD auth, and LDAP auth would be a great feature bullet point for cross-platform developers.

[NickCraver]

Agreed on the backwards compatible notes above - I don't feel a direct port is needed really, we just need a way to access auth (and perform other actions: search, unlock, delete, etc.) against Active Directory or any LDAP provider.

[terrajobst]

@NickCraver

I don't feel a direct port is needed really, we just need a way to access auth [...] against Active Directory

That's good to know. Don't read too much into my port-to-core label I just applied. It's just my way of tracking gaps in the .NET Core offering that prevents customers like you from porting their app to .NET Core.

[NickCraver]

@terrajobst Gotcha. I don't necessarily think this has to be a 1.0 item because of its modularity (and it sounds like it's slated for post-RTM anyway), but I do look forward to it. It'll be a blocker on porting Opserver for me, so happy to participate in API discussions if we can be of use. We have a wide range of use cases on the sysadmin side of things that may be helpful, ping if I can help out.

[sqmgh]

Just to throw another hat into the ring. At the moment this is the biggest blocker left for me as well. Simply being able to auth would be a huge help for now.

[Eaglef90]

Can we get an official response from someone on the dev team on the plans for this, if there are even any plans at all to support this?

I don't feel a direct port is needed really

Why? Sorry I am confused. Wouldn't that be the most easiest solution for everyone and in accord with DRY principle?
Nevertheless, if there is a reason to write the entire API from scratch, some consistency with old API (same method signatures) would be less confusing for consumer.

[NickCraver]

@jasonwilliams200OK let me clarify, I really meant DirectoryServices.ActiveDirectory specifically. I think authentication, and the stuff around it: e.g. group membership is the 95-99% use case of the namespace. I think a direct port of signatures of that is pretty useful. If the rest warrants change for some reason then I'd be pretty okay with that, and okay if it came later...the auth would be good to get out the door ASAP since that's a blocker to many.