@vibronet

Is there any update on this?

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?

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

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.

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.

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

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

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.

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.

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

Integrating at least a basic functionality of searching Active Directory users and mapping them with custom roles with ASP.NET 5 will ease the implementation of Windows Authentication into ASP.NET web applications. We need this functionality at our intranet site.

This is a blocker for us as well. We need to be able to auth, query users and groups, create new user and groups etc against a ldap server.

It is also a blocker for me - I require quering and authenticating users.

I came up with a solution for authenticating against Active Directory in a .NET Core rc1 web application. You just have to override the CheckPasswordAsync method in the UserManager class. Let me know what you think.

First you need make a custom register page that allows the user to input an AD username instead of an email address and password. That username goes in the UserName property of the ApplicationUser class that is generated by the ASP.NET 5 template when you chose Individual User Accounts authentication. Also, you'll have to default the Password property to something that passes the internal validation in the IdentityUser class.

My register page controller calls a Web API 2 method that finds the username in AD and returns JSON that holds the AD information for that user. I've added some custom properties to the ApplicationUser class to hold the AD information. I will post the code from my project next week.

Then add a class file in the Services folder. I named mine ApplicationUserManager.cs. Add the code below to that class file.

using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Microsoft.AspNet.Http;
using Microsoft.AspNet.Identity;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.OptionsModel;
using [YourApp].Models;

namespace [YourApp].Services
{
    public class ApplicationUserManager : UserManager<ApplicationUser>
    {
        public ApplicationUserManager(IUserStore<ApplicationUser> store, IOptions<IdentityOptions> optionsAccessor, IPasswordHasher<ApplicationUser> passwordHasher,
                                      IEnumerable<IUserValidator<ApplicationUser>> userValidators, IEnumerable<IPasswordValidator<ApplicationUser>> passwordValidators,
                                      ILookupNormalizer keyNormalizer, IdentityErrorDescriber errors, IServiceProvider services, ILogger<UserManager<ApplicationUser>> logger,
                                      IHttpContextAccessor contextAccessor)
        : base(store, optionsAccessor, passwordHasher, userValidators, passwordValidators, keyNormalizer, errors, services, logger, contextAccessor)
        {

        }

        public override async Task<bool> CheckPasswordAsync(ApplicationUser user, string password)
        {
            //Pass user.UserName and password to an ASP.NET Web API 2 method that 
            //does the Active Directory authentication and returns a bool.
        }
    }
}

Then open the Startup.cs file. Add .AddUserManager() to the AddIdentity call in the ConfigureServices method as shown below.

services.AddIdentity<ApplicationUser, IdentityRole>()
       .AddEntityFrameworkStores<ApplicationDbContext>()
       .AddUserManager<ApplicationUserManager>()
       .AddDefaultTokenProviders();

This at least allows me to setup policy/claims based authorization while waiting for DirectoryServices support.

I rely on this library. It's a shame I can't port now.

@ClintBailiff I have to chime in here - because relaying the user's password across the wire again to another application in plaintext is a _really_ bad idea. Please, don't use this approach. It's a security hole.

@terrajobst this will be the blocker in porting my larger applications like Opserver over - can we please get this prioritized?

@NickCraver I never suggested passing the credentials as plaintext. As a rule I use SSL for all my web applications/services because they typically return data that only authorized users should see. I didn't think to specify that probably because it's so obvious that you would not want to send credentials in plaintext.

I would be i support of at least providing a port of System.DirectoryServices.Protocols. We recently switched our LDAP-related code to this to support a larger range of LDAP servers, as the System.DirectoryServices.ActiveDirectory namespace only likes to talk to AD servers.

I suppose, it would be possible for a 3rd party library to spin up this kind of support, but since it already exists in the framework I would imagine that a port would be simpler.

WTF asp team is not provide this basic functionality
This is a really blocker issue :(

Any update on LDAP support in CoreCLR ?

I would also like an update on this. I will be developing an enterprise application with ASP.NET Core that needs to authenticate users against an AD-server.

I'll be looking into porting System.DirectoryServices to .NET Core for v1.1.0 (https://github.com/dotnet/corefx/milestones)

@joshfree
I also have to authenticate users from ADLDS please also consider System.DirectoryServices.AccountManagement

A couple of years ago the company I worked for took the Novell (Mono) LDAP library source code so our application could talk to Active Directory, OpenLDAP and Oracle systems, and we added support for paged controls and updated some TLS fixes. We did this as we wanted to run on Linux. A PR with our changes was sent to the owners. As we now want to get onto CoreCLR that library needed converting to RC2. The work has begun here https://github.com/VQComms/CsharpLDAP/pull/1, there are 17 compiler errors left that need addressing. They are mainly Thread.Abort, ThreadInterruptedException, replacing TLS streams from Mono to the CoreCLR SslStream If anyone is interested and needs LDAP support for CoreCLR feel free to help out.

I have confirmed that an ASP.NET Core Web Application (.NET Framework) RC2 project can reference a class library that uses System.DirectoryServices.AccountManagement. I could only get it to work when both the web application and the class library are created with VS 2015 Update 2 and both use .NET Framework 4.6.1.

Just to echo sentiments of others, we are dead in the water porting without being able to query LDAP and the like.

@h3smith
See my previous post. With the release of RC2 you can now reference a class library that uses System.DirectoryServices.AccountManagement.

Not on Netstandard.

However as I say we are working on getting this working. Hopefully have
something in around 2-3 weeks

On Friday, 17 June 2016, Clinton Bailiff [email protected] wrote:

@h3smith https://github.com/h3smith
See my previous post. With the release of RC2 you can now reference a
class library that uses _System.DirectoryServices.AccountManagement_.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment-226837679, or mute
the thread
https://github.com/notifications/unsubscribe/AAGapiY8HNzdakVdStwCFqvReT6kfSTcks5qMt_wgaJpZM4FF2fx
.

Any updates on this? I need to authenticate the calling user, when the user is using an angular web app on the LAN, logged in to AD, calling a WebAPI controller method (without the user entering password into web browser) in aspnet core RC2. Possible? Soon possible?

To do this you just need to use withCredentials in your http requests from the client. Then you can get user informations and claims in your controllers using User.Identity.
This works in ie and chrome but with Firefox a popup will be automatically shown to Le the user type in their windows user and password

We hit the same issue (e.g. trying to use a LDAP server as user store) around two months ago. We could not find any solution besides porting the Novell LDAP library (https://www.novell.com/developer/ndk/ldap_libraries_for_c_sharp.html) to .net core (see here https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard). There is a nuget package published. We are using the library with OpenDJ LDAP server (should work with any LDAP server) - no issues in 1.5 months of usage.

@dsbenghe we've just got our Novell LDAP lib compiling on netstandard, ours contains paging too. This was done by @igorshmukler . Would you like to compare and collaborate? Ours is WIP here https://github.com/VQComms/CsharpLDAP/tree/coreclrPort

@dsbenghe Thanks for your work on the .NET Core implementation of it.
After getting the nuget package I have created the following code to test if the user's ActiveDirectory password is correct

using Novell.Directory.Ldap;

private async Task<JsonResult> LoginActiveDirectory(LoginModel model)
{
    var user = await _userManager.FindByNameAsync(model.Username);
    if (user != null)
    {
        var result = AuthenticateWithActiveDirectory(model.Username, model.Password);
        if(result == string.Empty)
        {
            await _signInManager.SignInAsync(user, false);
            return Json(new LoginResult {Success = true});
        }
        return Json(new LoginResult { Success = false, Message = result });
    }

    return Json(new LoginResult { Success = false, Message = "User not found in local database" });
}

It calls AuthenticateWithActiveDirectory:

private string AuthenticateActiveDirectory(string username, string password)
{
    const int ldapVersion = LdapConnection.Ldap_V3;
    var conn = new LdapConnection();

    try
    {
        conn.Connect(_loginSettings.LdapHost, _loginSettings.LdapPort);
        conn.Bind(ldapVersion, $"{_loginSettings.LdapDomain}\\{username}", password);
        conn.Disconnect();
    }
    catch (LdapException e)
    {
        return e.Message;
    }
    catch (System.IO.IOException e)
    {
        return e.Message;
    }

    return string.Empty;
}

And uses a simple helper class to let the angular application know what is going on

public class LoginResult
{
    public bool Success { get; set; }
    public string Message { get; set; }
}

For UWP, there is a request for this feature on our UserVoice: https://wpdev.uservoice.com/forums/110705/suggestions/12556779

cc @tquerec @jimuphaus who will be working on System.DirectoryServices support for .NET Core.

Can't wait! ETA? Design specs?

When it is finally ported over, will we have access to:

using(var context = new PrincipalContext(ContextType.Domain, "Domain"))
     return context.ValidateCredentials("user", "password");

I know there are some minor defects within that namespace, but is still pretty helpful.

@GArrigotti in testing, using LdapDirectoryIdentifier is usually faster than PrincipalContext.

using System.DirectoryServices.Protocols;
/////////
try
{
    using (LdapConnection conn = new LdapConnection(new LdapDirectoryIdentifier(domain)))
    {
        conn.Bind(new System.Net.NetworkCredential(username, password, domain));
        return true;
    }
}
catch (LdapException e)
{
    return false;  
}

Is there an ETA? I could use this in a system due to be completed at the end of this month...

@johnkwaters is there are reason why you can't put the AD code in a class library? Some people (including me) have had problems referencing legacy class libraries in an ASP.NET Core application. But there are no issues if you create the web app and class library in VS 2015 Update 3 and target .NET Framework 4.61 in the web app and class library.

is there are reason why you can't put the AD code in a class library?

Do you mean PCL followed by "imports": "portable-net45+win8" in project.json for .NET Core TxM? That will require Mono PCL Reference Assemblies to be present on Unix and not a "pure donet-core" solution, which grantees self-sufficiency on Unix. It is a good hack to silent the compiler, but only work through and through if the CoreFX BCL have the corresponding implementation. As a rule, the project.json with no "imports" for netcoreapp/netstandard1.x is always better. e.g. https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/blob/ace2706/Novell.Directory.Ldap.NETStandard/project.json#L11

Any update on an ETA? Where can I go to self service that recurring question?

_Really_ looking forward to this feature!

Really looking forward to this feature too !!

Really looking forward to this feature too !!

I am also in desperate need for this feature!

Guys, could you all just add reactions to the main post?

Or use the libraries that have been put on nuget by 2 separate people. Its
all OSS. If you dont like the package, send a PR

On 8 September 2016 at 12:19, Mikhail Orlov [email protected]
wrote:

Guys, could you all just add reactions to the main post?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/2089#issuecomment-245567328, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGappY2sfk1GWkY7w1IcuAJSa_uKFHwks5qn-8qgaJpZM4FF2fx
.

+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 ;)

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

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 😄

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.

Really need this!

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

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

cc: @danmosemsft

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.

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.

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

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

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

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.

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

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?

@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

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

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

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

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

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

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

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

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

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

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.

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

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?

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)

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.

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.

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.

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.

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

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!

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

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

@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"
      }
    }
  },

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

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.

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.

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

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

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.

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 🦃

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!

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.

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.

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.

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.

We're discussing the funding on our side (expect update in ~2 weeks), this is currently top priority from APIs which are not yet part of .NET Standard 2.0.

Are there people around who would be willing to help/contribute with the Windows implementation and/or Linux implementation? (we could drop in the code from Desktop and it would require further massaging to build + some testing)

@karelz I'd love to contribute for the Linux side of things. We need this support for both Windows and non-Windows Authentication (on-prem). This is a blocker for us, and we're targeting .NET core for our cross platform project (previously was Mono on the Linux side and .NET on the Windows side).

Would like to help out where we can, without a doubt.

I would love to help out but im sure you guys are way more experienced than myself and i dont i would be of any use.

@karelz @tquerec I'd be happy to help with testing on Windows and, in the future, Linux. I subscribed to the thread, so just reply here or mention me to get in touch when you need me to get involved. Thanks for your work on this. It's been long awaited and, even if incremental, it'll be a good step to further adoption of .NET Core.

I think that "extended Windows" is a good target initially, "extended" meaning that it works on NanoServer and in Containers (i.e. non-domain joined machines that can't run the full .NET CLR). This will give you a quick win, and a starting point for working backwards to implement it on other servers.

We worked with @tquerec and our management chains to find out the best way to unblock this work ASAP. Unfortunately we don't have anyone free before end of January, so we will try to do our best in the meantime to unblock community contributions with just limited resources and some volunteer work from our side (@ianhays @tquerec and @karelz).

Here's what we plan to do:
@ianhays will help us kick start the project in CoreFX repo (add some source code, showing examples how to do it, advise with setting up build, packaging, prepare the project for future Linux/Mac ports, etc.).
We will start with Windows-only implementation (contributions are welcome). We will not take any functional changes to the implementation or API surface at this point unless they are necessary for the port to .NET Core.
The next (potentially parallel) step will be adding tests. We should kick off discussion with @tquerec on existing (closed-source .NET Framework) test design if there is anything we can leverage, or if we have to start from scratch.
Later on, we can focus on Linux/Mac ports.

@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte, and anybody else interested, we will be happy to take your contributions once @ianhays kick starts the effort (ETA: mid next week I think). If you have any questions, or suggestions, please let us know.

Does this work also allow libraries such as SqlClient to perform Windows Authentication when running on Linux but connecting to a SQL Server that requires Windows Authentication?

That is one of my road-blocks to being able to port things to .NET Core running on Linux. All of our enterprise Microsoft SQL servers only allow connection via a Service ID (non-interactive) which is in AD.

blgmboy. Your problem is a prime example on why things need to be "vetted" out to ensure true cross-platform compatibility with the new suggested models. If you have more scenarios I think your environment is a good example of how things need to cross and you should list any other problems you are having with the AD portion of Core.

Yes, I will definitely keep this thread in mind and share anything that I find. Just wanted to let everyone know that this is a pretty big show stopper for Enterprises with SQL farms that have strict security as described.

It is also a show stopper to using something like EF Core which ultimately would have the same problem.

System.DirectoryServices is now merged into CoreFX. The next step is to get it building for .NET Core - Windows and add tests.

Thanks Ian. It is good to see some traction on this issue!

Thanks Ian!

Updated execution plan: EDIT: Moved to the top-most post in this issue for better discoverability

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

TheSystem.DirectoryServices namespaces contain such important functionality for on-premises enterprise Windows apps so great to see some progress on this issue. Keep up the good work.

I have fixed up the sources and System.DirectoryServices is now building. I should be sending out a PR soon.

Thanks @tquerec for contributing the second round!
Are there any volunteers to help with the remaining 2 namespaces or tests? (@gortok @h3smith @CalebMacdonaldBlack @SOM-fermonte)

@jay98014 has a PR up here https://github.com/dotnet/corefx/pull/15324 to add further support and get Protocols/AccountManagement building.

For what it's worth, I've been experimenting with System.DirectoryServices.Protocols recently and found that many simple System.DirectoryServices scenarios are not hard to mimic with System.DirecotryServices.Protocols. Based on that, I think getting S.DS and S.DS.AM working cross-platform can be a lower priority since a cross-platform System.DirectoryServices.Protocols could be a serviceable work-around for many users.

Of course, that means that getting System.DirectoryServices.Protocols working as a cross-platform LDAP solution remains a high priority.

Am I reading the pull request right? Looks like this was accepted a few days ago so if we build from source we should be able to try it out?

Yes, I think we have all of DirectoryServices building, however we do not have any tests - which prevents us from shipping the package as stable and from improvements to the code base (bug fixes, enhancements, etc.).
If you can give it a try on build from source, that would be great. If you (or anyone else) wants to help us add tests, or start Linux port, that would be even better :)

Hi Everyone,

We are getting ready to start an enterprise project that requires Active Directory support as we are 100% internal to our domain. Can someone please provide status for this issue and expectations for the next core release? I apologize, but I am new to the GitHub community and do not understand yet all the various terminology and status information.

It would be great to use Active Directory for membership instead of an entirely separate identity model that would have to be managed separately and just cause data mismatch as well.

Thanks in advance!

@karelz for that question, but I think the answer is that this is not currently expected in the 2.0 release, as we don't have a developer scheduled for it. Community contributions are welcome. it doesn't need to ship _in_ the 2.0 release, it can go out on NuGet at any time it is ship ready.

Perfect! You answered my question.

Thanks.

@nevcoBpalacio any interest in taking a shot at a contribution?

I do have an interest, especially with this topic as I know it holds back many from going to core with enterprise solutions. However, we have a work around and I cannot seem to find the time in the day(evening with kids) for it. I will make an attempt to re-tool my system at home to work with GitHub. I appreciate you asking though! Thanks.

Nevcobpalacio, if you use vs17 and don't require cross plat you can get a bit closer to what you want by using the core web app template targeting the full .net framework and ref the system.directoryservices.accountmanagement dll the old fashioned way and roll your own middleware to do it in the meantime. From what I've seen the same code should carryover to targeting .net core once this is available except you'll use the nuget package and drop the ref. Hope this info helps get your project on track.

@los93sol thanks for that suggestion. Our initial discussions are to build it similar to that suggestion and make it a middle ware module that we can "cut over" to whatever lands in Nuget later. Thanks a bunch!

I have to comment and commend you on this suggestion. I was skeptical at first about this change to core. However, with this community approach, discussions like this come into light and help us all work things out during these major changes.

Thanks.

Is anyone currently working on adding the missing tests, or on porting System.DirectoryServices.Protocols to Linux/Mac ?

@pasikarkkainen AFAIK there is no such active effort at the moment from Microsoft teams (which might, or might not change in near future). I haven't seen anyone from community starting to work on it either.
Are you interested in contributing, or just curious about the status?

@karelz It looks like they are targeting the DirectoryServices for the .NET Core 2.0 release this summer.

Quote from @shanselman

AD – Totally, this is a gap IF you want to call LDAP directly. You can certainly auth against Windows Auth NOW. We plan to have specifically the DirectoryServices namespace for Core 2.0 around summer timeframe

=> https://github.com/aspnet/Home/issues/2022#issuecomment-299536123

Yep, that's in line with hallway discussions I've heard. I just wasn't sure if it is public info and how much (and who) committed to it. I think it is safe to say, it is under very strong consideration and it is likely going to happen. I let @shanselman & DirectoryServices owners comment on the timelines.

@karelz : Thanks for the update! I was mostly curious about the status.. I can definitely help with testing at least, when this becomes available.

@pasikarkkainen if you're also willing to help write some test cases, that would be very appreciated.
If you "just" want to test the package on your app/code, it should be doable today. We just need to start publishing the package as preview on myget (I think the publishing is disabled today).

@karelz I wouldn't mind to help with the Mac implementation specifically. I have little knowledge, so I'm not sure how well I can contribute. I've done research around it and there's a novell library that people seem to suggest. Found someone else's implementation around that novell library here: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard

@carlowahlstedt Author of the package mentioned it here already.
https://github.com/dotnet/corefx/issues/2089#issuecomment-228043297

So is this something that will be in core 2.0? I'm a little confused as to the status of it.

No, it won't be part of .NET Core 2.0, however, at Build conference we promised availability of the package during Summer. The (Windows) package should be available on top of .NET Core 2.0, around the time .NET Core 2.0 ships.
We are currently working on making the packages available as preview in master branch (#18090) and working on test assets in parallel (#20669).

Will we get compilation errors when we target the shared runtime or a non-Windows runtime? Or will we end up with the PlatformNotSupported-trap?

It will be standalone package without any non-Windows assets. Compilation should break. @ericstj can confirm.

You will not get compilation errors they will be runtime "PlatformNotSupported" exceptions.

Yeah, it's the old - do we block people using it from .NET Standard libraries, or do we turn compile-time errors into PlatformNotSupported exceptions? ... Luckily there is a middle ground: ApiCompat tooling will tell you ahead of time you're using something which is not everywhere.

I am getting the following error when I try to System.DirectoryServices package in netstandard 1.6 project:

Install-Package : Package System.DirectoryServices 4.0.0 is not compatible with netstandard1.6 (.NETStandard,Version=v1.6). Package System.DirectoryServices 4.0.0 supports: net (.NETFramework,Version=v0.0)

Is there a work around or solution for this?
Regards,
Varun

@vrn11 this package is from another vendor and only supports full net framework

Anyway wanted to ask if there is an update on this. Maybe a preview package that we can grab from myget? Would be awesome to test this out

@StefanKert https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.DirectoryServices

As @MarcusKohnert mentioned you can grab them from https://dotnet.myget.org/F/dotnet-core/api/v3/index.json. There's System.DirectoryServices, System.DirectoryServices.AccountManagement, and System.DirectoryServices.Protocols.

Awesome! thanks to @MarcusKohnert and @ericstj for the links!

I'm trying the packages from myget:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" /> <PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />
While running on a MacOS 10.12.6, and when running:

using (var context = new PrincipalContext(ContextType.Domain, "DOMAIN"))

I'm getting:

System.PlatformNotSupportedException: Operation is not supported on this platform. at System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, String name)

Is PrincipalContext expected to work on a Mac?

@bruno-garcia there is no implementation in CoreFX right now for DirectoryServices except on Windows. @karelz would have to speak to plans/aspirations if any.

Only System.DirectoryServices.Protocol is potentially x-plat doable (not implemented yet) - see details in some of my answers above and in the top post.

Getting System.DirectoryServices.Protocols working cross platform (also on Linux/Mac) is important.. did I understand correctly the main issue currently is that the LDAP library used by System.DirectoryServices (on Windows) isn't opensource, and thus only works on Windows?

If I have understood it correctly, System.DirectoryServices will be hard to make xplat due to alot of dependecies on ADSI COM Interfaces, that is just available on windows.

System.DirectoryServices.Protocols should still be possible to make run xplat.

Running the same code I mentioned before:
```c#
using (var context = new PrincipalContext(ContextType.Domain, domain, $"OU=someou,DC=somedomain,DC=bla"))
````

On a Win7 x64 with .NET Core 2.0 yields:

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

Used the packages:

<PackageReference Include="System.DirectoryServices" Version="4.5.0-preview2-25701-02" />
<PackageReference Include="System.DirectoryServices.AccountManagement" Version="4.5.0-preview2-25701-02" />

[EDIT] Fixed callstack & xml/C# code syntax highlighting by @karelz

@bruno-garcia please file separate issue. This one is tracking the overall port effort, not particular bugs/differences. Thanks!

@bruno-garcia that is tracked by https://github.com/dotnet/corefx/issues/23605

Next step may be to debug through desktop and see where behavior diverges. I will try to free up a dev to look at it.

Same issue on windows server :( (Version="4.5.0-preview2-25701-02")

NullReferenceException: Object reference not set to an instance of an object.
System.DirectoryServices.Protocols.LdapConnection.ConstructEntry(IntPtr entryMessage)
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(int messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, bool exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
System.DirectoryServices.AccountManagement.PrincipalContext.ReadServerConfig(string serverName, ref ServerProperties properties)
System.DirectoryServices.AccountManagement.PrincipalContext.DoServerVerifyAndPropRetrieval()
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container, ContextOptions options, string userName, string password)
System.DirectoryServices.AccountManagement.PrincipalContext..ctor(ContextType contextType, string name, string container)

What do you think, when will it work?

have an issue when trying to install a package

Install-Package : Unable to find package System.IO.FileSystem.AccessControl with version (>= 4.5.0-preview2-25707-02)
  - Found 15 version(s) in nuget.org [ Nearest version: 4.4.0 ]
  - Found 0 version(s) in Microsoft Visual Studio Offline Packages
  - Found 0 version(s) in Package source
At line:1 char:2
+  Install-Package System.DirectoryServices -Version 4.4.0-preview2-257 ...
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Install-Package], Exception
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

===============================================
If anyone has same problem as me use .NET CLI instead

dotnet add package System.DirectoryServices --version 4.5.0-preview2-25707-02 --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

@papamamadoii that's because you're missing https://dotnet.myget.org/F/dotnet-core/api/v3/index.json as a source and aparently Install-Package didn't use your specified feed for finding dependencies. You might want to file a bug on http://github.com/nuget/home with specific repro steps.

@karelz If I am understanding the comments correctly this is not working on Linux based deployments?

@euclid47 System.DirectoryServices.* is not currently supported on Linux. As discussed above, parts of it could potentially be ported given sufficient community interest/participation.

@danmosemsft I don't get how you can't see this entire thread open since October of 2015 as sufficient community interest. If I possessed the skillset required to write something as complicated as an LDAP communication layer, I would have already been working on it, as the AD was one of the core authentication mechanisms in an enterprise environment. I will point out that for most large enterprises, the inability to perform these kinds of interactions on Linux literally defeats the purpose of Core and will cause them to stick to pre-core builds of dotnet, thus limiting your precious community interaction.

@danmosemsft Also, if you're literally not planning to work on this, just let the community know definitively so other developers can pick up the pieces.

@shairozan so far we have noted 7 votes out of 54 who consider DirectoryServices on Linux as higher priority than Windows -- see https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217
There are also other advantages developers get out of .NET Core than just x-platform (although I agree that x-plat is one of the top reasons).

I would recommend to first finish release of the Windows-only package, then we can open new issue to track the interest for Linux port more precisely.

We already told community we're looking for help and the issue is marked up-for-grabs -- see https://github.com/dotnet/corefx/issues/2089#issuecomment-261681168. And @hughbe helped with first round of tests for DirectoryServices - see history here, here and here.

@karelz Where is voting managed for these components? I can guarantee after SELF / POSSCON you'll see a pretty drastic increase in interest.

@karelz Where is the voting for this feature? I absolutely agree with @shairozan with the need. There is a comment in this issue that describes our development and production environment. It is quite shocking there has not been any movement on the implementation since .Net Core evangelists preach it is platform agnostic.

I created a new issue to track the Linux/Mac port dotnet/corefx#24843 for easier voting than on the comment in the middle of this issue (https://github.com/dotnet/corefx/issues/2089#issuecomment-261093217).

I added the link also into the top post of this issue.

@euclid47 the voting so far was in this issue - see the links above. That's what resulted in the 7 votes (+1 for original issue submitter).

Our team needs support LDAP on Linux.
Because most of our clients use auth via LDAP.

@balkarov If you can, upvote on the the issue @karelz had just created ( https://github.com/dotnet/corefx/issues/24843 )

@balkarov @shairozan @euclid47 If you are not aware already there is the Novell.Directory.Ldap.NETStandard Nuget package that you can use to integrate LDAP into your projects. We are not advanced LDAP users, we just use it to validate credentials and get user information, but it works fine for us, both on 1.0 as well as 2.0 running on the dotnet core runtime docker image. It's not an official way but it gets the job done until there is a cross platform port of System.DirectoryServices.

@OskarKlintrot thanks. But this library does not support login without domain.
I create issue https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard/issues/43
Can you help me resolve this problem?

I'm not part of that project or an advanced user but I'll take a look, see you there!

(We are not login in with a domain)

Given @karelz broke out an issue for Unix, I retitled this one for clarity.

@danmosemsft but issue has plan
Linux/Mac ports.

@balkarov I have updated the plan to link to other tracking issues and removed check boxes for items which are tracked separately (broken out work) or do not block Windows work.

Will System.DS port be compatible with RODC servers (Read-Only Domain Controllers)?

@PKGeorgiev you should get the same System.DirectoryServices support we have in the full framework.

The work on DirectoryServices for Windows is finished, closing the issue.
Note:

• Final package publishing is tracked by dotnet/corefx#24909
• Linux/Mac port is tracked separately by dotnet/corefx#24843

Hi, will this work in UWP?

Hi, will this work in UWP?

No, it is supported only for net core apps running on Windows and full framework. if you use it in UWP or on Linux, you'll get a PlatformNotSupported exception.

I am using this code in a lambda function in AWS which runs on Linux in the background and I am getting this error. "System.DirectoryServices.AccountManagement is not supported on this platform."
I am using core 2.0

 public static List<string> GetGroups(string userName, string domainString)
        {
            List<string> result = new List<string>();
            List<GroupPrincipal> gprList = new List<GroupPrincipal>();
            // establish domain context
            PrincipalContext yourDomain = new PrincipalContext(ContextType.Domain, null, domainString);

            // find your user
            UserPrincipal user = UserPrincipal.FindByIdentity(yourDomain, userName);

            // if found - grab its groups
            if (user != null)
            {
                PrincipalSearchResult<Principal> groups = user.GetAuthorizationGroups();

                // iterate over all groups
                foreach (Principal p in groups)
                {
                    // make sure to add only group principals
                    if (p is GroupPrincipal)
                    {
                        gprList.Add((GroupPrincipal)p);
                    }
                }
            }

            foreach (var gp in gprList)
            {
                result.Add(gp.Name);
            }

            return result;
        }

@sscoleman Yes, this is not supported on Linux yet. It is supported on Windows only.

@sscoleman there is an issue created on it, https://github.com/dotnet/corefx/issues/24843. It was said there was not enough community interest in it with the exception this question comes up all the time. So now you are in a crap spot. You spent time implementing directory services and then find out Linux is supported. Now you ask yourself why is this being touted as platform agnostic if there are Windows only features.

It's fairly obvious if you look at the greater Microsoft strategy. Microsoft are throwing ALL of their development resources into Azure, and that includes Active Directory. Check out "What's new in 2016", it's mostly AzureAD/Hybrid investments. https://docs.microsoft.com/en-us/windows-server/identity/whats-new-active-directory-domain-services.

Microsoft is not investing in this library for Linux because they want everyone to move to Azure AD instead. It makes sense, why would you invest in something that you're trying to get customers to move away from?

You're doing something relatively simple though. You can use the Novel LDAP libraries, they work with AD and on .NET Core for Linux. You need to do the protocol work yourself, but it's not overly complex, and there's a lot of samples out there. The downside is that you need to manage binding yourself, which requires a user DN and password.

System.DirectoryServices is currently a Windows-only API and it's part of the Windows Compatibility-Pack for .NET Core. In principle, we can make parts of System.DirectoryServices work on Linux but we haven't had the resources to do that yet. dotnet/corefx#24843 is tracking this work item.

Why are we allowing to install packages that will not work on Linux? The alternative would be to fork the API surface but that doesn't work well for all cases either and makes the overall system harder to code against. Of course, our choice isn't without problems either, as it can make it harder to predict whether code will work cross-platform or. We have a preview of a compatibility analyzer that gives you live feedback as you code.

See this video for more context on how we see the Windows Compatibility Pack and the cross-platform analyzer work hand-in-hand:

https://channel9.msdn.com/Events/Connect/2017/T123

@thedevopsmachine

Microsoft is not investing in this library for Linux because they want everyone to move to Azure AD instead.

That's not how I see it. As you pointed out, we intend to make money via Azure. And Azure is a cloud platform that offers a wide variety of technologies and operating systems. We have no business interest to promote Windows in the cloud over Linux in the cloud. But of course, .NET has had a strong presence on Windows for 15 years. Making things fully functional across all operating systems takes time, but I honestly think most people following our open source efforts can see that we're not hamstringing Linux on purpose. It just takes time.

i agree with the approach with having a consistent api x-plat and x-framework, but it is soul destroying whenever ive encountered that dreaded error .. i feel for @sscoleman ...

Can this DirectoryServices package work on CentOS 7?

Can this DirectoryServices package work on CentOS 7?

The package can be installed but will not work. when using it you'll get platform not supported exception. we are looking how we can support directory services in general on Linux. this is on our radar.

This really needs support linux

CC @joperezr

@niemyjski see dotnet/corefx#24843

This really needs support linux

.. plus be able to run in a docker container. Imho it is a pain in the ass that one needs to fall back to the old Novell directory implementation when one wants to use .NET Core 2+ on linux.
Thanks anyway for working on it!

Why close this issue? System.DirectoryServices.AccountManagement is still not in .NET Core outside Windows:

# dotnet --list-runtimes
Microsoft.AspNetCore.All 2.2.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.2.6 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

reopen 14734

@tarekgh still on the radar?

reopen 14734

@JustinGrote what is the exact functionality you want to for scenario? DirectoryServices is huge and I doubt the whole functionality can be supported in just one release. Having specific requests may help better than just requesting the whole DS libraries to be supported. In .NET 5.0 we have enabled a scenario https://github.com/dotnet/runtime/issues/23944.

CC @joperezr

@tarekgh
I wasn't aware System.DirectoryServices.Protocols had been ported but it looks like it still has a dependency on security.principal.windows, does it work in linux even with that (via basic auth etc.) or will it throw a missing assembly error?

Goal is to reimplement something like ActiveDirectory Powershell module to be xplat, I was considering either the novell ldap module or ldap4net for that purpose if there wasn't going to be at least basic interaction support available.

Implementing ActiveDirectory Powershell is likely a very big use case. Let me share my two use cases:

1) I am deriving from UserPrincipal as I need attributes that are not supported out of the box. I followed https://stackoverflow.com/questions/24798037/extend-userprincipal-class and I guess this is kind of a standard in the old .NET framework, and getting that approach to work will probably help more developers.

2) I also have code like the following:

`

        DirectoryEntry entry = new DirectoryEntry("LDAP://CN=some base address");
        String objectClass = "some object";
        String filter = "(objectClass=" + objectClass + ")";
        using (DirectorySearcher search = new DirectorySearcher(entry, filter,
             new string[] { "some attribute" },
             SearchScope.Subtree))
        {
            using (SearchResultCollection src = search.FindAll())
                foreach (SearchResult s in src)
                {
                    /* do something with */ s.Properties["some attribute"][0]);
                }
        }

`

No clue what is already supported today, last time I checked was in February.
Thanks, Joachim

@jol64 can't you achieve the same using the Protocols?

@jol64 can't you achieve the same using the Protocols?

Likely I can. I rewrote some stuff to use the Novell library. But it requires a rewrite and thus redundant code to my existing .NET framework code. I definitely prefer to avoid a code split of all code, and I am sure others dislike the idea as well.
I am also wondering how authentication works. With Novell (the old version I tried) I have to specify credentials, whereas with my existing code I don´t need to.
Thanks, Joachim