Support for System.DirectoryServices for Windows

[syeshchenko]

Execution plan:

• [x] 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.).
• [x] 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.
  • [x] 2.1. System.DirectoryServices.Protocol (on top of wldpap32.dll)
  • [x] 2.2. System.DirectoryServices (on top of adsi.dll)
  • [x] 2.3. System.DirectoryServices.AccountManagement (on top of System.DirectoryServices and SystemDirectoryServices.Protocols)
  • [x] 2.4. System.DirectoryServices.ActiveDirectory (on top of Win32 APIs - see https://github.com/dotnet/corefx/issues/2089#issuecomment-261063131)
• [x] 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]
• [x] 6. Publish DirectoryServices package
  • [x] 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

[h3smith]

+1 for @jchannon Novell LDAP. It got us moving forward and took virtually no changes to our LDAP implementation. I mean you are abstracting correctly right ;)

[johnkwaters]

Yes, I ended up using @jchannon Novell LDAP too, it has worked well.

[jchannon]

If I've not said so before, here's the branch its all on https://github.com/VQComms/CsharpLDAP/commits/coreclrPort

Works well for our requirements at the moment...

@h3smith @johnkwaters any issues feel free to raise an issue 😄

[PoppyPham]

I decided to try with Novell, the samples look good enough but I don't know how to kick (remove) user member out of a group with Novell LDAP.
I cannot change my password on MSAD LDAP due to I can't see userPassword and It didn't set on LDAP Server.

[CalebMacdonaldBlack]

Really need this!

[rock-meister]

@joshfree or anyone else in the know... We are looking to start a new project which needs access to ActiveDirectoryServices.AccountManagement Question, Is the port targeted for either 1.1 or 1.2?

[karelz]

It is not part of 1.1 (which is about to be finalized). @tquerec, can you please comment on your plans here?

cc: @danmosemsft

[nevcoBpalacio]

SO, if not part of 1.1 any one have a plan? Seems like a major issue to not have this support. Clearly, Microsoft of all would want this integration.

[h3smith]

Just another vote for. Hard to make the investment to build enterprise class systems on .NET Core when it lacks fundamental enterprise functionality. The Novel project works, but isn't up to snuff.

[tmccleve]

Yet another vote. I will echo the same statement that this is integral to creating any enterprise application.

[CalebMacdonaldBlack]

@nevcoBpalacio I think they are trying to push us to use azure active directory

[tmccleve]

That will never work for those of use with corporate agreements requiring services to remain in house.

[nevcoBpalacio]

I have been working for Government agencies, both Federal and now Local County and either way you would still need some interface or abilities to integrate to some Directory Service, either cloud based or on premise. I have co-developed applications managing billions in dollars and always some need for directory services arises. I think this is more than another vote, but rather a statement of what are you waiting for? I agree with an earlier post that this was originally an out of the box solution in prior .NET releases. I understand that the more open structure of CORE should gain the momentum of the community and if this is what Microsoft chooses to wait for, maybe they have said this and I missed it, they should say it so someone might take the initiative to invest time to get it done.

[pasikarkkainen]

Yes, please add System.DirectoryServices to .NET Core!

[tquerec]

We have plans to port System.DirectoryServices.Protocols within the next year. At this point I can't provide a firmer date. We don't yet have plans to port System.DirectoryServices or System.DirectoryServices.AccountManagement but I’m interested in gauging interest. Are there features of those namespaces people are using which can’t be solved with Protocols?

[rock-meister]

@tquerec I am not familiar with Protocols. We have a project to do Active Directory self service to do Account Unlock and Account password reset. We use UserPrincipal in the project and invoke the methods like FindByIdentity, UnlockAccount, SetPassword,, ExpirePasswordNow,. I am not sure if these can be done on Protocols but looks like Protocols is a lower level implementation versus AccountManagement is a better abstraction for working with ActiveDirectory. Thanks Rockmeister

[CalebMacdonaldBlack]

@nevcoBpalacio definitely should be more than a vote I agree. I think this really needs more priority.

[karelz]

@CalebMacdonaldBlack it would be helpful if you can answer @tquerec question about usage patterns and why is what needed. More upvotes or "I agree/ it is important" without scenarios won't help raise the priority at this moment ... Thanks!

[h3smith]

Our usage is scanning/searching LDAP, doing BIND to verify credentials, adding/removing LDAP objects (users, groups), modifying membership in groups, etc.

[CalebMacdonaldBlack]

@tquerec I really need System.DirectoryServices.AccountManagement so I can authenticate our users against active directory and authorise them on groups they have access to.

[liquidboy]

definetely agree with h3smith .. we needed this for v1 and instead are forced to go the Novel path , which we have hobelled together (especially the replication bits) and is causing us grief with the overhead of maintenance etc.. This is making .NETCore look bad as a side effect ..

[karelz]

@liquidboy

we needed this for v1

Do you mean .NET Core v1? -- that is done and shipped. We are working on 1.2 now. Or did you mean something else?

instead are forced to go the Novel path

What does it mean? (Sorry I have zero context on DirectoryServices, but I would love to understand what we are missing on from scenarios point of view)

[liquidboy]

@karelz just do a search in this thread for the word "novel" and you'll see what i mean. Another dev (dsbenge) on my team commented about (along with others) on the gap that led to us using novel. [heres the link to the comment above https://github.com/dotnet/corefx/issues/2089#issuecomment-228043297]

And yep i did mean .NET Core v1 which has already shipped, we've been working on our solution for over a year and we needed a good DirectoryServices solution back then .. We hit a wall and thus had no option but to use novel.

[karelz]

@liquidboy thanks for the link -- if it is in Mono, we should be able to reuse the source code in .NET Core AFAIK. @tquerec given the interest, is it something your team would consider?

[pasikarkkainen]

@tquerec: We need the following: System.DirectoryServices, System.DirectoryServices.AccountManagement, System.DirectoryServices.ActiveDirectory, and System.DirectoryServices.Protocols.

Those are needed to connect to and manage Active Directory (and other LDAP servers) users, groups, attributes just like described in above replies aswell. It is important to have these features in .Net Core !

[NickCraver]

I agree with others. I need this to port any of our apps that auth against ActiveDirectory to .NET Core. This is pretty fundamental, it should definitely be in the soonest release possible. It's the blocker to porting so many things.

[pasikarkkainen]

.NET Core roadmap page (https://github.com/dotnet/core/blob/master/roadmap.md) has this plan for .NET Core 1.2: "bringing .NET Core to parity with .NET Framework and Mono for a large collection of base types."

I think porting System.DirectoryServices fits that plan very well, and should indeed be part of 1.2 release. Just my 5 (euro) cents :)

[karelz]

Just to clarify: The APIs ported in 1.2 were picked based on usage data (and rarely complexity) - @weshaggard @danmosemsft can you chime in with details, why we didn't include System.DirectoryServices?

[danmoseley]

The list of assemblies we chose to match is here. @weshaggard will have to remind me how he chose that list. (Mono has S.DirectoryServices)

[Sjark]

I believe you will be able to do just about everything needed in regards to talking with ActiveDirectory (and other ldap servers) using System.DirectoryServices.Protocols, but a lot of people will have to rewrite their code to use S.DS.Protocols.

Personally I would prefere MS to port S.DS.Protocols and MS or the Community to create an easy to use library for user/group management on top of this.

[weshaggard]

The list of assemblies we chose to match is here. @weshaggard will have to remind me how he chose that list. (Mono has S.DirectoryServices)

The initial seeding was done from intersecting Xamarin profiles with .NET Framework. Xamarain profiles (which is a subset of mono) do not support DirectoryServices which is why this wasn't in the intersection.

[NickCraver]

What can we do to argue this should be in? The inability to use the most common authentication scheme in Microsoft applications is a bit of a blocker, no? Is the focus on Azure here and AAD instead? Or is the blocker that porting this across platfoms is a larger unknown of protocols?

Is there a way we can increase the priority here? 2.0 is a long way away, and that's really unfortunate if everything else works, but we can't authenticate users. This is the virtual front door for so many applications. IMO, in terms of priority it's a little different because it's not a partial blocker, but often a full blocker by nature.

[weshaggard]

I don't think there is any disagreement that we want to support this in .NET Core, which is different then being part of .NET Standard, it is just a matter of when. @tquerec owns the area and would be the one to speak to that.

[h3smith]

Someone from .NET Foundation asked, but the namespaces we are using specifically are: System.DirectoryServices, System.DirectoryServices.Protocols, System.DirectoryServices.AccountManagement

[pasikarkkainen]

So, @tquerec, how do we get System.DirectoryServices flagged for .NET Core 1.2 ? At least System.DirectoryServices.Protocols. Is that possible?

Thanks a lot!

[karelz]

[updated with more info from @tquerec] I met with @tquerec on Monday. I owe everyone a write up. In nutshell:

• System.DirectoryServices is doable on Windows-only (it calls into Windows DLL where all the implementation lives), totally unknown for Linux/Mac
• System.DirectoryServices.AccountManagement sits on top of it, so also doable Windows-only, and unknown for Linux/Mac
• System.DirectoryServices.ActiveDirectory is doable on Windows-only (it calls into lots of Windows specific APIs)
• System.DirectoryServices.Protocols should be reasonably simple for Windows and more work for Linux (we need to find LDAP library to use). We are trying to figure out with @tquerec how to fund the work - ideally for 1.2, but no promise yet. I expect the decision will take at least couple of weeks.

Questions to everyone:

• Is the above Windows-only scoping acceptable for the major use cases? (Sys.DirSer and Sys.DirSer.AccountManagement and Sys.DirSer.ActiveDirectory)
• If Sys.DirSer.Protocols Linux comes post-1.2 or relies on community contributions, would that be a major blocker?

[tquerec]

@karelz System.DirectoryServices.ActiveDirectory is based on a large number of Windows specific APIs so it falls into the same bucket as S.DS and S.DS.AM.

[rock-meister]

@karelz I am not sure what you mean by a windows only solution for 1.2. We already have a windows only solution that works.

"frameworks": {
    "net452": {
      "frameworkAssemblies": {
        "System.DirectoryServices": "4.0.0.0",
        "System.DirectoryServices.AccountManagement": "4.0.0.0"
      }
    }
  },

[karelz]

@rock-meister I mean .NET Core. The one you mentioned targets "full" .NET 4.5.2+.

[NickCraver]

Yes, Windows-only support is a huge unblocker for us. We can do all the work for .NET Core porting and expand platform supports "for free" later, when the underlying bits do. Right not the blocker to even starting to port is huge. That being gone is a big win.

[nevcoBpalacio]

Being a Windows shop this would be big win here also. So many big enterprises would consider this a huge win! Thanks for keeping up to date with your information. Keep us posted. Thanks.

[rock-meister]

@karelz Thanks for the clarification. Yes, Windows-only scoping for 1.2 works for us. Rockmeister

[liquidboy]

System.DirectoryServices.Protocols with Linux /LDAP support is the highest priority for the work we do ..

p.s. windows-only scoping seems counter to the goals of .netcore / .netstandard

[PleasantD]

We switched from using System.DirectoryServices to using System.DirectoryServices.Protocols a while back so that we could support non-AD LDAP servers. Having access to the Protocols namespace would be one step closer to allowing us to port our code to .NET core.

However, if this is going to be platform-specific then there is less use for us. One main point of wanting to move to .NET core is platform portability. We'll probably still need to wait for that.

[h3smith]

For us getting to .NET Core was the ability to leverage Docker and be totally platform agnostic. So being stuck with Windows only LDAP support wouldn't be beneficial.

Thanks for discussing internally.

My vote is going with platform independent route 🦃

[nevcoBpalacio]

I have to agree with the platform agnostic comment, as much as it hurts that I cannot use core until this gets accomplished. I do think this is something that has to be reviewed at a higher level. The thing I do not get is the complexity of the concept? There are several directory solutions, AD, Novell, etc... This calls for a cross platform (agnostic) interface solution... Happy Holidays!

[michaelpfister]

While personally I could live perfectly fine with a windows-only scope, in my opinion this breaks the idea of the .NET Core and its portability. A platform independent solution should be the route to focus on.

[pasikarkkainen]

Yes, agreed, .NET Core should be cross-platform and features/APIs should work on all supported platforms! So if System.DirectoryServices.Protocols is going to be ported/implemented first, it should work also on Linux.

[zuckerthoben]

I agree that ideally a platform independent solution should be the goal. Though still not having it on Windows is a blocker for a lot of developers that just want to experiment with the platform in a corporate (AD) Environment, like myself. That's why I would welcome a Windows only solution for the time being.

[jbuck79]

I'd just like to chime in and say that I'm fine with a Windows-only solution until something cross-platform can be put together.

I would imagine that 99.9% of developers who need to connect to Active Directory are doing so in an enterprise environment where they are developing on Windows boxes.